RFC: The future of TCP within Laminar

[TimonPost]

Some discussion is taking place about whether TCP belongs in this crate. So I thought let's make an issue for it.

[TimonPost]

Maybe I agree for a part to not have TCP. If you look at the pure gaffer implementation like the site descibes and we are recreating it is all about building an reliable UDP implementation.

There are a few library's out there that have implemented this protocol in c/c++/go etc. Do they have TCP support? Not they don't!

So the big question would be than, with laminar is or goal to implement the gaffer-vision with building reliable-udp or is or goal with this library to implement some abstractions ontop of an socket system. Wich allows different protocols to be under the hood.

I think we want to provide the first option here, an reliable UDP implementation.

And if we want to add TCP we maybe even create an higher level crate implementing abstractions on top of TCP, laminar, serialisation like protobuf etc. This crate would be higher level and would have some general pupose for game networking and laminar would be one purpose rUDP implementation.

[CBenoit]

I think we want to provide the first option here, a reliable UDP implementation.

And if we want to add TCP we maybe even create an higher level crate implementing abstractions on top of TCP, laminar, serialisation like protobuf etc. This crate would be higher level and would have some general pupose for game networking and laminar would be one purpose rUDP implementation.

I agree with this!

[LucioFranco]

@TimonPost good thanks for this.

I believe that this library should only be for a semi-reliable UDP protocol. I do not think we should provide any sort of TCP interface. Mostly, I bring this up because currently, we provide no real benefit to TCP besides an opinionated way to thread it and that is going in the opposite direction I want this library to go into.

[fhaynes]

I think the core issue here is we need a more coherent design document for both laminar and amethyst-network. So far, we've been doing it very ad-hoc. I'm fine with putting TCP somewhere else, but it needs to be within a more holistic context. Why don't we just spend a bit of time and do a more formal design and figure out what goes where?

[LucioFranco]

@fhaynes are we looking to design all of amethyst_network and laminar right now? Or just laminar?

[fhaynes]

If we're talking about what should be in amethyst_network vs laminar, then it seems some design work on both would be needed. They're tightly coupled components in the context of Amethyst.

[LucioFranco]

@fhaynes sure, let's do it. I don't want to dive too deep into amethyst_network but I think we can design some of the low-level aspects of it. Like its TCP support etc. We can formalize a plan and then propose it via a RFC to the amethyst/amethyst repo.

[fhaynes]

I'm curious what you consider too deep?

[LucioFranco]

@fhaynes I don't want to fully spec out the higher level abstractions for specs and other entity sync type api's at the moment. There is still some work going into similar features that are not quite ready yet but that networking could use. I don't know if you've read through the code right now there but it is very basic. I wanted to work bottom up. Meaning, I wanted to start low level and create a UDP protocol that powers the message sending done by the amethyst_network crate. Then start moving up in abstractions as is the normal way. But I think there are a lot of things we could do higher up and I think amethyst_network will be a big crate. So really what I want to say is that I want to start low in a sense of what we provide as an MVP. The next one supporting semi-reliable packets.

[fhaynes]

Yes, we want to make sure it plays well with other parts. It's working backwards a bit, but we should be able to do a decent design doc.

[TimonPost]

But what do you think of even creating a higher level crate between laminar and amehtyst_network?

This (new) crate should provide things like default encoding, protobuf, flatbuf etc, some higher abstractions to make laminar easier and TCP stuff. This could be handy for non-amethyst users as well if they don't want to do anything with amethyst related code.

[OvermindDL1]

I'm also entirely for dropping TCP, optionally reliable UDP will be faster than it with far greater control on how quickly certain messages should be sent or not.

[TimonPost]

We are removing TCP from the lib see PR #56