[HECnet] TCP based bridge / router, what's the status?

[Peter Lothberg]

On 2012-08-06 18:18, Jarratt RMA wrote:
Not sure I recall this particular conversation, but I am making (slow)
progress on a user mode DECnet router that runs on Windows and Linux and
which I intend to make friendly to those who do not have a fixed IP
address (like me). Not sure if that is what you were referring to.

I think there have been other discussions about tcp as a transport for 
traffic. I've personally not been very interested in this, since there 
are potential problems and issues with this. But it would in principle 
not be hard to convert the existing bridge program to use tcp instead if 
someone wanted to, but I won't be running that at my end...

Right now I have the Ethernet Initialization sublayer about done for
actual Ethernet connections. I still need to do an interface that will
interop with Johnny's bridge program, this should be easy when I get to
it,

Stupidly simple, in fact. You'll get full ethernet frames in UDP 
packets. Pass them in and parse them, just like any other ethernet 
packet. As for sending them out, once you have the full ethernet packet, 
send it over UDP instead of out on the ethernet interface.

when I do it I will add a periodic check that the IP address is
still valid by checking against DNS (you would need to be registered on
a dynamic DNS service like DynDNS). I believe Johnny does not do this in
the   bridge because of the temporary halt in packet processing this
entails. Personally, this is a price I am willing to pay. I could make
it asynch I suppose, but it is harder to do this in a portable manner.

Correct. DNS resolution can take ages, especially when things gets 
wrong. Timeout are into minutes sometimes.

You really do not want to block operation on that.
Potential other problems if you go with tcp - a changed address means 
tearing down and reestablishing connections. You will have to make sure 
that the received can receive and process packets faster than a producer 
is sending them, or else you need to implement packet discarding, or 
else you'll get really weird problems because packets will appear, but 
way after they are considered dead by the sender. A typical example is 
if the sender is sitting on a gigabit ethernet, but the receiver is a 
lowly PDP-11 on a 10 Mbit ethernet segment. TCP never drops the packets. 
Instead you'll get into TCP flow control, which will block your writes 
or return with partial success. Another thing is that TCP is just a byte 
stream, so you need to somehow block/deblock your transmissions so that 
you deal with full packets at the receiving side. And if you implement 
packet drop, you might need to be able to resynch or drop data in ways 
that don't get only partial packets across.
One problem here is that by the time the sender becomes aware of a 
problem, you are already very deep into the problem. In order to make it 
work smoothly, you need to detect and drop packets on the receiving 
side. But that's also tricky, since how do you know on the receiving 
side that there is more data coming before you have received it...
Else you try to implement some signalling protocol outside of the data 
stream to tell this kind of information.

Ah well, I could go on... Suffice to say that it's not because I'm 
opposed to the features that a TCP connection, or DNS resolution would 
give, but I prioritize something that I feel confident is working to 
features. And doing a proper solution with all these aspects is more 
work than I have cared to put into it. The bridge program is a hack.

As Paul mention, pthreads would probably be a good start if you want to 
do something more intelligent. You need to start thinking asynchronously.

	Johnny

Regards
Rob

On 6 August 2012 16:35, Sampsa Laine <sampsa at mac.com
<mailto:sampsa at mac.com>> wrote:

      I remember there being some discussion about a bridge that would
      work over TCP (only requiring the server to have a port forward /
      static IP)..

      What's the status on this? My ISP (a 3G network that's blazing fast
      but short on IPs, which means I'm NAT'd on the outside of my
      network, thus not portwards are possible).

      Ideally I would like to just point at the server without them
      knowing anything about my originating IP, perhaps with some form of
      authentication.

      Sampsa








DECnet over Ethernet, makes the assumption that unless there is a collition, the packet makes it to the
receiver.

DECnet over P-T-P links assumes there is underlaying reliable transport, eg, DDCMP.


Running a ether bridge serving multiple nodes over TCP will cause problems like what Jonny outlines, basically
it'sa head-of-line problem.

But if the Bridge makes a mesh of TCP connections (one per destination) it will work....

-P