Online Amateur Radio Community Wiki

User Tools

Site Tools

Trace:
packet:digipeating

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
packet:digipeating [2024/04/08 20:21] – m0ltepacket:digipeating [2024/04/08 20:25] (current) – m0lte
Line 5: Line 5:
 APRS makes extensive use of digipeating- actually using it as a kind of multicast, unlike how it works in connected mode. APRS makes extensive use of digipeating- actually using it as a kind of multicast, unlike how it works in connected mode.
  
-In connected-mode packet, while it can occasionally be useful in specific situations, digipeating is generally discouraged. This is for two reasons:+In connected-mode packet, while it can occasionally be useful in specific situations, **digipeating is generally discouraged**. This is for three reasons:
  
   - it is less efficient in terms of airtime   - it is less efficient in terms of airtime
   - it is less reliable in terms of robustness   - it is less reliable in terms of robustness
-  - it is generally not needed - there are other means to achieve the same end result which are more efficient and reliable.+  - it is generally not even needed - there are other means to achieve the same end result which are more efficient and reliable.
  
 The reason for both the efficiency and reliability issues are related. It is less efficient because with digipeating, in an example with three stations in a chain, station X needs to orchestrate retries between station Y (which X can hear) and station Z (which station X cannot hear). It is less reliable because, with digipeating, if any part of the chain breaks down and causes retries, every station needs to be involved in recovering, which introduces far more opportunities for further failure and collapse of the session than if each individual link in the chain were modeled as its own independent connection. The reason for both the efficiency and reliability issues are related. It is less efficient because with digipeating, in an example with three stations in a chain, station X needs to orchestrate retries between station Y (which X can hear) and station Z (which station X cannot hear). It is less reliable because, with digipeating, if any part of the chain breaks down and causes retries, every station needs to be involved in recovering, which introduces far more opportunities for further failure and collapse of the session than if each individual link in the chain were modeled as its own independent connection.
Line 23: Line 23:
 More complex schemes exist, for example, NET/ROM. This glosses over the need to establish two connections explicitly, at the expense of an additional per-packet overhead of some bytes, plus the need to tolerate nodes broadcasts. It also provides an aliasing system, such that a distant system can advertise an alias for itself or its applications, and asking a NET/ROM-aware node within its "horizon" to connect to one of these aliases automatically establishes the underlying L2 sessions, if required, and joins them to each other. More complex schemes exist, for example, NET/ROM. This glosses over the need to establish two connections explicitly, at the expense of an additional per-packet overhead of some bytes, plus the need to tolerate nodes broadcasts. It also provides an aliasing system, such that a distant system can advertise an alias for itself or its applications, and asking a NET/ROM-aware node within its "horizon" to connect to one of these aliases automatically establishes the underlying L2 sessions, if required, and joins them to each other.
  
-Regardless of how X connects to Z, the result is a binary-transparent two way pipe through which you can shove bytes either way until the connection is closed. The pipe has exactly the same characteristics as a connection between two nodes which can hear itself directly - the origin and destination software at each end of the pipe is immaterial. +Regardless of how X connects to Z, the result is a binary-transparent two way pipe through which you can shove bytes either way until the connection is closed. The pipe has exactly the same characteristics as a connection between two nodes which can hear each other directly - the origin and destination software at each end of the pipe is immaterial. 
  
 None of this is a new concept- indeed this is primarily how multi-hop connected-mode traffic is passed in practice in 2024. None of this is a new concept- indeed this is primarily how multi-hop connected-mode traffic is passed in practice in 2024.
packet/digipeating.1712607695.txt.gz · Last modified: by m0lte