[HECnet] Next retro comms project?

[Steve Davidson]

Very true!


-----Original Message-----
From: owner-hecnet at Update.UU.SE on behalf of Johnny Billquist
Sent: Wed 10/21/2009 10:17
To: hecnet at Update.UU.SE
Subject: Re: [HECnet] Next retro comms project?

Sampsa Laine wrote:

On 21 Oct 2009, at 14:55, Bob Armstrong wrote:

Well, if we're going to go off into Wishful Thinking Land here :-)

* DECnet for BSD, especially 2.11 PDP-11 bsd.   Yes, a 16 bit version is
significantly harder than a 32 bit version, I know, but there are several
real PDP11s out there running BSD that could be on HECnet.   I know - I've
got one!   We could use the Linux DECnet as a starting point - the dn
userspace utility programs might not even be that hard to port - but we'd
need a kernel wizard to do the tricky bits :-)


Just an idea, and I'm not a network programming guru at all, but do we 
really need to have stuff in the kernel? Could we not just have a 
userland process that writes frames to the network interface* and then 
apps talk to the server process? I imagine this is easier to both write 
and debug...

Sampsa

* assuming we are able to write raw frames to the net interface of 
course...

Performance will be horrible, and it will also probably be very 
problematic. You also need some sort of a transition point between the 
kernel and user space to even start doing this. Any user process who 
would like to talk DECnet will either want to do system calls, or open a 
device to do the communication. That system call, or device will then 
access the memory area of the user process to read/write data from the 
user process. If your protocol implementation also were in user space, 
you then need to send it back from the kernel back into userspace again, 
for the protocol process. And you also need to keep track of the 
original user process, to keep a connection living, and you need to know 
if the user process goes away, so that you can tear down stuff when it 
happens. There are a lot of headaches in there, and having a user 
process doing it isn't really that helpful.

It's a common mistake to think that this will actually be easier just 
because the protocol is implemented as a user space process. It isn't. 
The only thing that becomes easier is that once the basic framework is 
in place, you can more easily install and remove the code that 
implements the protocols. But since buggy protocol implementations often 
corrupt more than can be fixed, you often end up needing to reboot anyway.

And we still have the horrible performance issues...

	Johnny