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