[fpc-pascal] Thoughts on Shell Approach to TCP Sockets
coyo at darkdna.net
Fri Mar 20 00:18:55 CET 2015
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
More information about the fpc-pascal