Time-To-Live: Difference between revisions
m (1 revision) |
No edit summary |
||
| (3 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{ | {{Language}} | ||
{{UpdatedPage|2010-02-11|v2.5.2.0|}} | |||
{{StableContent}} | |||
== | == Time-To-Live == | ||
This term stems from the TCP/IP communication library used to send and receive transmissions over the Internet and other public and private networks. The Time-To-Live defines the number of [[ | This term stems from the TCP/IP communication library used to send and receive transmissions over the Internet and other public and private networks. The Time-To-Live defines the number of [[hops]] a packet may go through before it is discarded. This was an early means of traffic control to prevent a packet from getting stuck in a [[routing loop]] or traversing more nodes of the network than were necessary only to find that the destination was unreachable (this scheme makes the assumption that the destination will be reachable in a practical situation in under 255 hops). | ||
As a packet passes through routers on its way to a destination, the router deducts one value from its TTL and then sends it on to the next hop. If a router finds that the TTL value is 0 upon arrival, it will either forward the packet to the destination if it has reached the correct network, or discard it if the network will require more hops. In this way, packets are given specific lifespans, | As a packet passes through routers on its way to a destination, the router deducts one value from its TTL and then sends it on to the next hop. If a router finds that the TTL value is 0 upon arrival, it will either forward the packet to the destination if it has reached the correct network, or discard it if the network will require more hops. In this way, packets are given specific lifespans, also called "time to live". | ||
Original [[gnutella]] used a similar scheme to prevent gnutella transmissions from flooding too many nodes -- searches were originally defined by a TTL value which was between 0 and the maximum acceptable value of 15. Now, this system is primarily archaic as new, more efficient methods of routing have prevailed. The TTL, however, is still supported for backward compatibility and some other uses in Shareaza's network stack. For more information on where TTL is used in Shareaza, take a look at Shareaza's [[Advanced Setting]]s. | |||
Latest revision as of 17:21, 11 February 2010
 Languages: |
[[::Time-To-Live|English]] • [[::Time-To-Live/de|Deutsch]] • [[::Time-To-Live/es|Español]] • [[::Time-To-Live/fr|Français]] • [[::Time-To-Live/he|עברית]] • [[::Time-To-Live/it|Italiano]] • [[::Time-To-Live/nl|Nederlands]] • [[::Time-To-Live/pl|Polski]] • [[::Time-To-Live/pt|Português]] • [[::Time-To-Live/ru|Русский]] • [[::Time-To-Live/zh-hant|中文(繁體)]] | e |
 Updated: |
This page has been updated on 2010-02-11 for the release of Shareaza vv2.5.2.0. | e |
 Stable Content |
The information on this page should apply to all Shareaza versions provided there are no major changes. | e |
Time-To-Live
This term stems from the TCP/IP communication library used to send and receive transmissions over the Internet and other public and private networks. The Time-To-Live defines the number of hops a packet may go through before it is discarded. This was an early means of traffic control to prevent a packet from getting stuck in a routing loop or traversing more nodes of the network than were necessary only to find that the destination was unreachable (this scheme makes the assumption that the destination will be reachable in a practical situation in under 255 hops).
As a packet passes through routers on its way to a destination, the router deducts one value from its TTL and then sends it on to the next hop. If a router finds that the TTL value is 0 upon arrival, it will either forward the packet to the destination if it has reached the correct network, or discard it if the network will require more hops. In this way, packets are given specific lifespans, also called "time to live".
Original gnutella used a similar scheme to prevent gnutella transmissions from flooding too many nodes -- searches were originally defined by a TTL value which was between 0 and the maximum acceptable value of 15. Now, this system is primarily archaic as new, more efficient methods of routing have prevailed. The TTL, however, is still supported for backward compatibility and some other uses in Shareaza's network stack. For more information on where TTL is used in Shareaza, take a look at Shareaza's Advanced Settings.