Well guys, it only took me X hours, but I’ve finally reworked everything to revert back to using IO instead of NIO and to have a single thread to handle all incoming/outgoing UDP data instead of a thread-per-connection system for both the client and the server. Thanks for all of the help guys. Despite hours of work and a headache or two it’s all coming together. One day I’ll finally get to rendering…one day soon…
how would I determine where the packet came from, so as to send a packet to that client in response?
-> The ip is written in the header
I can’t find where I would have said TCP is faster than UDP
-> I don’t think TCP is faster than UDP as long as you don’t care about packet-loss
I don’t see why it’s not related to the question.
That isn’t me (OP). I have no idea what they were responding to, because I don’t recall ever mentioning packet speed. 
Oh, there’s some sort of general confusion around on the internets that “UDP is faster than TCP” which keeps on surfacing but if you close your eyes it goes away again 
Cas
The thing is that TCP isn’t slow. TCP is the result of years of research and adaptation to real world usage, and it’s pretty damn amazing at what it does. People think it’s just the acknowledgement of received packets and the resending of lost packets that are the main features, but that is far from true. TCP has a massive number of other features to tackle congestion, adapt itself to better handle packet loss, avoid sending more packets than the connection can handle, handle flakey connections like Wifi and 3G, etc. If you’re making the next Counter-Strike or other extremely twitch-based games, then sure, you want to use UDP but only if you know exactly what you’re doing. You have to be pretty arrogant to think you can beat TCP at its own game.
Only when
latency is extremely important
AND
packets get outdated almost instantly
AND
the order in which packets is not relevant
AND
you barely have any packets that need the guarantees of TCP
AND
you’re not sending a lot of data
AND
you know you can make a better system than UDP
should you use UDP. And even then, there are a lot of other pitfalls that you can fall in that add so much more delay than what TCP adds. The new Battlefield games (3, 4, Hardline) all use a tickrate of 10Hz, e.g. they artificially introduce a 100ms delay. I generally get 5-10 ms ping with servers in Sweden, meaning that even with a significant amount of packet loss (which I never get), the delay from the frigging game code is a magnitude higher than anything that TCP could cause, and any such packet loss may even be handled worse by a self-implemented protocol based on UDP.
Could you explain what the “Solution” to the confusion is then please if you would?
UDP and TCP packets of course traverse at the same speed, which I would assume obviously everyone is aware of.
Regardless,
UDP: Send 1 packet, takes 5 ms to get there… = 5ms
TCP: Send 1 packet, takes 5 ms to get there, send 1 packet back, takes 5 ms to get back… = 10ms.
The overall “process” of UDP is faster, not the send times, it’s the actual entirety of what’s happening is “faster”.
I am one caught in this general confusion you speak of, if you would explain to me how the process sending and receiving is just as “fast” as the process of ONLY sending.
Your logic is flawed. Why would the receiver have to wait for the ACK to arrive? Hell, how could it know that the ACK it sent ever arrives? As long as the packets arrive in order and in time, TCP and UDP are equally fast. Having to send an ACK packet to confirm the packet arrived does not the make the original packet arrive slower. If two packets arrive out of order (which is rare nowadays IRC), e.g. packet 2 arrives before packet 1, then TCP won’t be able to deliver packet 2 until packet 1 arrives. And obviously, if a packet is lost, the TCP stream will stall until the missing packet has been resent. Still, TCP has some pretty advanced logic for dealing with this, much better than anything you could code yourself.
TCP has had years and years of work on it, I’d hope it would be way better than anything I could code.
When did I say the receiver would wait for the ack to arrive…? The SENDER waits.
I send you one packet. You GET THAT PACKET, but before I send you anymore, you need to LET ME KNOW you got that packet.
How can you say that process is faster than just you getting the packet?
Because TCP has a thing called a sliding window and another thing called slow-start which you might want to look into, not to mention the accept/connect cycle when the socket is created in the first place, but briefly:
When the first few packets are sent over TCP, the server only sends a few packets before it’ll sit and wait for an acknowledgement that they’re actually being received. When it gets acknowledgement, it decides the connection’s good, and will thence send rather more packets before waiting for acknowledgement. If it doesn’t receive ack in a reasonable length of time it assumes that there’s some problem with the connection and resends the data, but a bit less of it.
The practical upshot of this is: the throughput of TCP is somewhat slower, to begin with, as it’ll sit and wait for acks before sending more data, but it rapidly increases to about the same rate you’d achieve with UDP less a little extra overhead from the slightly larger packet header sizes.
So for any normal reasonably lengthy sort of communication, such as for a game client/server, TCP and UDP are approximately going to have the same latency and throughput.
Things get more interesting when the intervening networks suffer congestion.
When there’s congestion, UDP packets frequently just vanish into thin air. So do TCP packets, except that after a very short while, the sender notices it hasn’t received an ack; at which point it’ll back up and start resending data, more slowly. And this is the bit that usually worries games designers. The thing about many realtime games is that if a bit of data gets lost, it’s already being superceded by updated information sent just a few packets later - so there’s just no point in receiving the old data again. So technically you can make a more efficient protocol on top of UDP and prevent all sorts of perceived lag issues caused by resending pointless data… it’s just that it’s rather hard to get right.
Cas
Network Congestion is a very real thing and can for sure happen frequently.
I’ve wrote my own “reliability layer” ontop of UDP. Could it be improved? Of course, it’s by no means perfect. The point is, it does EXACTLY what it needs to FOR MY GAME. I know which packets are important and which aren’t. I only send about 3 or 4 important packets at the start of the game, the rest of my packets aren’t exactly MUST GET IMPORTANT, so to me, why would I use TCP when I’m pumping out basically all un-important data?
I feel as if a lot of games are like this as well, of course everything comes down to the game the networking is being implemented on. I do think if you’re sending 50% of important packets you should make TCP work. The reality is no one wants their games to have hiccups, and with UDP you can implement some prediction to make up for lost packets, where with TCP your just freezing, then catching back up real fast, which obviously again, depending on the game, is an undesired effect.
I’m not a UDP fanboy or think UDP shits on TCP by any means, I just do believe for any type of game that is semi-fast paced, UDP really is the better choice.
None of this is what I made this thread for, but I’m just going to sit back and watch the show.
tries to prevent the thread from de-railing, makes it worse
:
@Soul Foam
You kind of prove my point. The fact that people have misconceptions concerning TCP is exactly why rolling UDP is usually a bad idea. Like Cas explained further, TCP has a shitload of stuff going on under the hood, and none of your arguments are actually valid. Unless you can actually prove that UDP provides better latency both on stable and unstable connections, I am sadly going to assume that TCP is superior to your UDP implementation. I don’t mean to come off as hostile; your code might very well be equally good or even superior to TCP, or even simply good enough for your use case, and you should feel no pressure to change it. I am only saying that the burden of proof lies on your end to show that your implementation actually is superior. If you could, I would be extremely interested in seeing a benchmark/performance test comparing the two.
ANYWAY, I’ve been doing some reading on TCP, UDP, and mixing the two. In your guys’ opinion, for an MMO should I use TCP or UDP (it’s evident that the two should not be mixed from what I have read)? The MMO will be similar to Runescape. Runescape uses TCP, but games like WoW use TCP and UDP, and many FPS games use just UDP. I don’t know what to use…help me out?
I know some advantages and disadvantages of both, so I’m really just looking for what you guys think/would do here.
Having been a long time RuneScape player, I’d say there’s certainly no need for UDP, ever so minor performance concerns aside. The game plays at a slow pace compared to other real time games, moving at a few tiles a second, performing 1-2 actions a second, and mostly staying confined to a small area.
Since you click where you want to move, you presumably only need to ensure that the position of that click, and the players current position arrives to the other players, and the movement can be done on the client. The server will need to of course correct paths under certain conditions. The order and correctness that actions occur is important though. Other than most animations, the other players need to see what you’re doing, in order.
You generally won’t find more than a handful of players in any one area too, except for certain events, in which performance is killed by other factors anyway.
The use of UDP is complex and I’d suggest only using it when you’re doing realtime twitchy multiplayer stuff. Almost every other situation you’re better off going with TCP.
Cas
@shadowstryker OK, you can mix the two, it’s just that you should keep the data separate. For example game update code UDP, messaging code TCP.
Now I would just recommend TCP.
- Sometimes your game needs to send “must have” packets and rolling out both TCP and UDP takes more time that just implementing one or the other.
- If you go UDP and it fails you’re going to have a problem with something at some point.
- For an MMO you don’t need instant feedback like in say an RTS or FPS.
Don’t get me wrong I used UDP for an instant messaging program (easy to write + just learning about UDP) so you could go UDP, but refer to #2.
If you’re still unconvinced do some research on which types of games use which protocol. There will be some overlap I’m sure, but it will give you a good idea.