sustrik / libdill

Structured concurrency in C
MIT License
1.68k stars 155 forks source link

[Discussion] completely replace BSD sockets ? #132

Closed jzck closed 7 years ago

jzck commented 7 years ago

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 using SOCK_STREAM so all the heavy lifting is done in-kernel and you have no access to tcp headers whatsoever...

Is there something I'm missing here ?

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):

Is the "libdill ip" and further change of tcp.c something you'd be interested in for a pull request in the future ?

in essence these changes would be first step to make libdill independant of BSD sockets (and maybe a complete replacement) !

sustrik commented 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.

jzck commented 7 years ago

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.