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

[Coyo Stormcaller]

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!