🚀 go-pugleaf

> With regard to timing, the IP bridge could take quite a long time. 
There
> is nothing that would prevent the establishment of an IP bridge over
long
> distances, even via satellite.  AX.25 fixed length timers do not allow
this.

Possibly. But note that an IP bridge is never "established." The bridge
would not use any connection oriented transport protocol, such as TCP.

A 256 byte AX.25 frame takes about 2 seconds to transmit on a 1200 Baud
channel, including TXDELAY.
However, the time to transport such a frame over the Internet from, say,
Sweden to eastern USA would only be about 100 ms. It used to be as bad
as 500 ms, but that is still just a small multiple of the TXDELAY.

So the total transmission time of the frame should be dominated by the
time it takes to transmit it on the radio channels at both ends of the
connection.

So, adding one digipeater to the frame would get the transmission delay
of TNCs just right. It would also make it fairly convenient for the user
of the TNC to access the IP bridge. The user can have his packets
'digipeated' by the bridge just by typing the right callsign sequence at
his TNC command prompt.

Using no digipeaters (read: the NET/ROM model) the originating user
would have to make an AX.25 connection to the bridge and send connect
commands to its user interface. I think most users would find that to be
more impractical. It could also make it complicated (or impossible) to
have the bridge relay AX.25 UI frames.

I can also imagine a third scheme where you don't need to connect to the
bridge, and you don't need to use a digipeater to specify that you want
to use the bridge. The bridge would just "know" which callsigns it
should relay. Although this might sound neat, I think it could cause a
lot of problems. One would get the timing problems on TNCs for instance.
And particularily strange things would happen if two stations that
communicate through the bridge suddenly start to hear each other
directly. We all know how propagation conditions tend to vary...

Anders