dstaesse / ouroboros

Mirror of the Ouroboros packet network repository. Latest version and documentation is on the website.
https://ouroboros.rocks
BSD 3-Clause "New" or "Revised" License
41 stars 4 forks source link

Golang examples and benchmarks? #3

Open lonnietc opened 1 year ago

lonnietc commented 1 year ago

Hello,

I have been researching unique protocols for a high-density P2P project that has the need to scale to extremely large node-counts as well as to minimize latency.

As you might imagine, there are currently the standard options of TCP, UDP, and now QUIC for this work but I wanted to seek something entirely new and hopefully better suited for this purpose.

With this in mind, I am developing in Golang for the cross-platform compatibility and also to easily support man concurrent connections.

I am wondering if your new protocol has Go bindings and/or examples as well as if there are any benchmarks against other protocols as well?

Any information that you could share would be greatly appreciated. Thanks

dstaesse commented 1 year ago

Be aware that this an early-stage prototype coming out of research, so running many concurrent connections is going to stress some features such as reliable flows and congestion control way beyond their current implementation state.

We currently don't have golang bindings, but this is definitely something that is needed and that shouldn't be too hard to do using the ffi. I'm doing some work on configuration files at the moment, but after that, I can look into this.

The prototype is not mature enough for 'apples-to-apples' performance benchmarks against the TCP/IP stack. It currently writes its own packet format to raw (Ethernet) or datagram (UDP) sockets. The TCP/UDP stack offloads a lot of operations to the NIC, things that the prototype can't use to its own benefit. We tried some optimizations such as netmap and PF_RING, but they showed worse performance. PF_RING was so bad we removed it altogether. One of our former master students developed a prototype FPGA, but that also requires a lot more work to reach its full potential. We don't have the resources and expertise anymore to proceed along this path.

io_uring and DPDK are optimizations that we haven't evaluated/implemented yet.

That being said, I don't expect performance to be the real distinguishing factor. What we aim for is preventing ossification through (c)lean APIs, and making the configuration and management of packet networks a lot simpler through proper abstraction.

If you have a bit more information about what you'd like to try, I can see what is feasible from my side to move towards those objectives.

Hope this helps.