PoC or production ready?
Closed this issue · 3 comments
Is this project intended to become a production ready implementation? Or is it mainly designed to be a proof-of-concept to illustrate the ideas in the paper?
Reading the code, I can see a number of possible issues and omissions. I am not sure whether to report these and/or try to fix and whether that is something you are interested in?
The reason I ask is that I have been working on a TCP implementation myself in golang. Mine is not as complete as yours. It's structured quite differently too. I'm trying to decide whether to abandon my efforts and contribute you your stack, but before I decide I want to ensure our goals are aligned enough.
My goal is to have a TCP implementation, with simplicity and correctness being the priorities. performance is an important but secondary goal for me. As well as running TCP over ipv4 as you have, I also want it to be abstracted enough to be able to run over things other than ipv4 and ipv6.
One example goal for me is tunnelling TCP over UDP, to allow application level TCP like behaviour, but with easier NAT traversal, and without requiring authority on the system to managed tun/tap devices etc.
We originally made GoNet as a proof-of-concept while we were writing our paper. However, we do intend to continue development until it is production-ready.
Some things that we were planning on doing:
- Add IPv6 support
- Improve the stack's routing functionality
- Ensure the correctness of the protocol implementations
- Remove references to unneeded objects after use (allowing them to be freed by the garbage collector)
For a production implementation, we too are concerned about correctness. We do believe that the overall design of the network stack makes it both simple and fast.
If you think these goals align suitably with your own, feel free to contribute.
@hsheth2 thanks for this amazing work :)
Is there a plan to make it a complete user space network stack? bypass the kernel entirely.
Something like https://github.com/eunyoung14/mtcp?
We do not currently have plans to bypass the kernel entirely, although we may look into it in the future. As of now, we are focusing on making the existing implementation production ready.