switch to tcp / add support for it?

[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]

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]

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]

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]

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]

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]

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.

[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.

[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]

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]

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]

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]

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.