Closed jzck closed 7 years ago
Hi, you are not missing anything. libdill is using BSD sockets underneath because writing my own TCP/IP stack would be too much work :)
But yes, it would be an interesting endeavour and I would gladly accept it!
Before starting though think a bit about the problem of multiple processes using the same network interface. With kernel-side implementation the collisions are prevented by the kernel by managing the port space. In user-space implementation the solution is not that obvious.
Indeed the problem is larger than I can probably grasp yet, It's probably even out of the scope of libdill. But could be great for a fresh network API in a custom kernel... maybe someday! I'm closing this for now then. thanks for the input.
ps: for the purpose of my network mapper problem i've just kept with libmill
and used fdwait
before send/recv which is fine.
Hi martin, I'm in the process of implementing the ipv4/6 protocol in the "libdill spirit" because i need to send custom tcp/udp headers and I want it to play nice with
coroutine
switching.The way I see it if you have this then it's not that hard to implement a "real" udp, tcp etc as an overlay to ip, but in the
tcp.c
I see tcp was implemented usingSOCK_STREAM
so all the heavy lifting is done in-kernel and you have no access to tcp headers whatsoever...I understand dsock/dill were made to make vertical & horizontal scaling trivial for microprotocols, my goal is in the other direction (playing with existing protocol headers):
in essence these changes would be first step to make libdill independant of BSD sockets (and maybe a complete replacement) !