[fpc-pascal] Thoughts on Shell Approach to TCP Sockets

[Mark Morgan Lloyd]

Coyo Stormcaller wrote:
> On 03/19/2015 04:25 AM, Mark Morgan Lloyd wrote:
>> While it is possible to write a complete stack from scratch in any 
>> reasonably-complete programming language, and while this has been done 
>> for e.g. embedded systems (or by idiots such as myself for 
>> demonstration/testing purposes :-), in practice it's avoided on 
>> account of (a) the amount of well-tested code that it would attempt to 
>> supplant and (b) consideration of the difficulty of implementing all 
>> required services in a single program. 
> 
> My interest in Userspace TCP/IP stacks is mostly due to being able to 
> make dramatic modifications to the stack itself without modifying the 
> kernelmode stack, and the ability to route without touching system calls 
> to the socket system.
> 
> With a Userspace TCP/IP stack, I can send strange traffic with a raw UDP 
> port. I'm developing a version of TCP/IP that uses 512-bit DHT hashes as 
> addresses. When a packet is being routed to an unfamiliar destination 
> IP, it uses Kademlia routing to reach the destination. The host itself 
> has an internal router. All stacks in IPvCoyo have IP routing enabled. 
> Only the first connection is routed in this inefficient way.
> 
> Along the way, a bidirectional label-switching tunnel is constructed. 
> Subsequent packets are switched rapidly. This is efficient enough that 
> no hardware acceleration is needed. This system is based on CJDNS, but 
> rather than stopping at an IPv6 address, it goes further, altering 
> TCP/IP itself to have full 512-bit DHT hashes as endpoint identifiers. 
> Obviously, applications need to support the socket system.
> 
> That's where a userspace TCP/IP stack comes in. Applications can use 
> pipes to send and receive traffic to another userspace application (the 
> stack), or preferably, link to it as a dynamically-linked library and 
> send and receive calls to that library.
> 
> Maybe, if people like the system enough, it can be ported to 
> hardware-accelerated kernelmode code. But for now, modifying a userspace 
> TCP/IP stack seems like the most reasonable approach. If you're 
> wondering why I want to re-design TCP/IP it's because of a dare. I won't 
> lose!

Interesting. I've seen at least one complete stack written in Pascal, 
although I can't remember what it was using as the low-level device: 
back in the DOS days when such things were common they'd usually have 
used Packet Driver. My partial implementations (embedded in test 
routines in a comms program) were on top of SLIP and PPP, my suggestion 
would be to start off with a simple conventional stack on top of SLIP 
and to test it against slirp running on Linux.

IP etc. are basically fairly simple protocols. The complexity comes from 
all the options that can be applied at the IP level, and the RFCs that 
are piled on top of it.

The real risk here, even for a research project, is the number of 
potential buffer overflows that you have to watch out for. It's tempting 
and comparatively simple to handle incoming messages using either 
pattern matching or overlaid records, but I think a more robust approach 
is to use state machines (Pascal doesn't, unfortunately, support 
coroutines). Things like unix kernels typically pass around messages as 
pointers, I'd avoid that and use bounds-checked arrays even if that 
meant that CPU time was wasted copying data around.

-- 
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]