[HECnet] Next retro comms project?

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