switch to tcp / add support for it?

switch to tcp / add support for it?

Discussion between Spring developers.
Post Reply
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

switch to tcp / add support for it?

Post by abma »

is something really preventing the usage of tcp for network connections?

benefit when switching to tcp:
- less/simpler c++ code
- its a lot more difficult to fake packets
- possible lower latency (tcp can merge multiple sends, when udp can't -> less data sent)

drawback:
- _possible_ higher latency (needs benchmarks/tests/...), maybe see http://stackoverflow.com/questions/4790 ... ster-is-it
- udp allows stuff like nat traversal (but this makes stuff a lot more complicate / fragile)

are there other important objetions?

afaik our current protocol is just a basic reimplementation of tcp: packets needs to be in order / no packet can be lost. lost packets must be retransmitted

i would guess that the tcp implementation is much better than our udp-tcp like implementation.
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: switch to tcp / add support for it?

Post by hokomoko »

A pretty good article on the subject:
http://gafferongames.com/networked-phys ... -lockstep/

(Disclaimer: I have no idea what our UDP implementation looks like)
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: switch to tcp / add support for it?

Post by abma »

this article only takes into account mouse/keyboard input with the goal of a very low latency.

we have widgets which send data to synced, also there is input from multiple players. imo this doesn't fit very well to the spring engine. also i miss the comparinson of udp vs tcp.


afaik spring sents commands and not player input, like:

select unit1, 2, 3, move selected units to pos xy, ...

this is why widgets like custom formations can produce a lot of commands in a single frame... pretty bad for the suggested design to resend all un-acked input (=commands at spring).
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: switch to tcp / add support for it?

Post by hokomoko »

Obviously the article is a simplification, but Spring still uses relatively low bandwidth so I'd say it's relevant.

There's a reason why 99% of the games use UDP, it's because if TCP encounters issues, things happily get stuck waiting for a resend etc.
pretty bad for the suggested design to resend all un-acked input
why?
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: switch to tcp / add support for it?

Post by abma »

hokomoko wrote:why?
it is good when you only send keyboard and mouse input. when you want/need to send more data, it doesn't work.
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: switch to tcp / add support for it?

Post by hokomoko »

it doesn't work.
What doesn't work?
You mean it will take too much bandwidth?

I think that to implement TCP without having the pitfalls will require as much wizardry as UDP does.
Also, we have a system that works...
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: switch to tcp / add support for it?

Post by abma »

What doesn't work?
You mean it will take too much bandwidth?
yeah. resending the same data will waste to many bandwith (thats what is suggested at the page you linked to).

- its a lot more difficult to fake packets
thats imo major which can't be easily solved with udp imo. basicly it would require to reimplement an other part of tcp with udp.
User avatar
jK
Spring Developer
Posts: 2299
Joined: 28 Jun 2007, 07:30

Re: switch to tcp / add support for it?

Post by jK »

first a fact: Spring really implements TCP on top of UDP, meaning it won't process packets out of order.
Only games that don't use a synced gamestate can do so. And so the main reason for UDP is not valid for Spring.

Still there are some pros & cons for both UDP & TCP:

UDP
pros:
* you have exact control when a packet is send -> when you send it, it really gets send by the NAT (zero ping overhead)

contra:
* we have our own packet order system (needed for the synced gamestate)
* we need to resend missing packets (in userspace code and cause network thread sleeps 10ms, this is added to the ping in such cases)
* no authentication at all



TCP
pros:
* keeps track of packet order
* resends missing packets itself (in kernelspace -> possibly at a much smaller delay)
* a little authentication

contra:
* we have little control on the moment packets get send, if at all you can ask the OS to send your packets earlier



Also something ppl might not know: we don't make use of the only pro of UDP. We have our own implementation of Nagle's algorithm, merge packets sent in close intervals and only flush the buffer regularly (-> see UDPConnection::Flush).
So in total with TCP we would reduce our code (massively) and there is no reason why Spring should use UDP, still a switch to TCP would depend on how well TCP_NODELAY works.
Last edited by jK on 14 Sep 2015, 00:23, edited 1 time in total.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: switch to tcp / add support for it?

Post by abma »

hmm, thanks for this info!

then only adding support for it makes sense and allow runtime switching udp/tcp and then possible, if it works well, remove udp support.
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: switch to tcp / add support for it?

Post by hokomoko »

I'm highly against using tcp, everything can be implemented on top of udp with some work and without tcp side effects.
You guys forget that the bottom line is that TCP is handled by the OS which opens us for many issues we won't even be able to debug by ourselves.
resends missing packets itself (in kernelspace -> possibly at a much smaller delay)
smaller delay?
yeah, right....


The UDP implementation may need improving, but TCP is the wrong way to go.
abma
Spring Developer
Posts: 3798
Joined: 01 Jun 2009, 00:08

Re: switch to tcp / add support for it?

Post by abma »

hokomoko wrote:The UDP implementation may need improving, but TCP is the wrong way to go.
why not both: TCP and UDP? UDP often is completely blocked in firewalls and can't be easily proxied.

the implementation should be quiet simple in comparison to the UDP implementation.
hokomoko
Spring Developer
Posts: 593
Joined: 02 Jun 2014, 00:46

Re: switch to tcp / add support for it?

Post by hokomoko »

abma wrote:UDP often is completely blocked in firewalls and can't be easily proxied.
Many applications use UDP (every VOIP for instance) and most firewalls block both inbound TCP and UDP.

Anyway, even if you don't believe anything I say or link to:
1) Using UDP is the standard for games (including RTS games), do you want to discover why before implementing a TCP alternative or after?
2) Rewriting spring's networking is a recipe for brand new bugs, and these can be as annoying to debug as desyncs. Not to mention some will only appear on specific networks/machines. If we don't do anything drastic there's less chance we mess stuff up.
3) Good luck, have fun, don't say I didn't warn you.
Kloot
Spring Developer
Posts: 1867
Joined: 08 Oct 2006, 16:58

Re: switch to tcp / add support for it?

Post by Kloot »

jK wrote:Only games that don't use a synced gamestate can [process packets out of order]...And so the main reason for UDP is not valid for Spring.
Wrong.

The main reason UDP gets used in practically every game engine is that resending a few dropped packets under typical network conditions (and performing reassembly "by hand") yields far better latency and throughput that is critical for real-time applications than delaying the entire stream, which TCP *must* do to satisfy ordering / reliability / integrity constraints. It is completely irrelevant that Spring happens to be built around a synced gamestate model.

Further, disabling Nagle's algorithm through TCP_NODELAY is 1) not even close to a magic fix for these problems (it only prevents buffering of small packets) and 2) imposes a gigantic traffic overhead.

Conclusion: thou shalt not switch, and thou shalt not add support. Consider this a veto, Spring's development stability is already at risk without making major decisions out of dangerous ignorance.
Post Reply

Return to “Dedicated Developer Discussion”