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!
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
