The advantage of UDP over TCP in the context of a game is you want to be moving the gameplay forward at all times. With TCP if there is a problem in the delevery of a packet the TCP stack will hold things up and retry the missing packet which will cause your game to pause. With UDP packets are sent and there are no guarentees on the order they are received or even if they are received.

When writing a UDP protocol you need to take into account that you really don't know what came before or what will come after. So a packet to the effect of "move one unit to the left" is a bad idea because if the player moves to the left 5 times but only 3 packets make it then the other client will think the player is in a different spot than the local client. A more robust UDP protocol would be something like "at time 123 player 1 was at x=10 y=15 and was moving left at 1 unit per tick". This way you know when a packet was sent in case they arrive out of order, you know where the player is/was at the time so there is no confusion about location, and you have enough info to predict the future location if future packets get lost or maybe the current location if the packet was slow getting there.

I'll admit I'm not a protocol design expert so I hope I didn't miss anything.

Please abstract your network code as much as possible - I'm not just talking about actual byte access, but even some game-related logic. While TCP is a lot easier to use, net is full of extremly laggy projects which was tested on local net and then released into the wild without really checking if they work over the ocean.

So start with TCP (you will probably not be able to manage UDP at start) and then ask Japanese and Peruvian to test it on server running in Europe during peak hours. Then please readhttp://www.gamasutra.com/features/19990903/lincroft_01.htm"The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter"

I especially like the sentence"TCP is evil. Don&#8217;t use TCP for a game. You would rather spend the rest of your life watching Titanic over and over in a theater full of 13 year old girls."

TCP is certainly acceptable solution for small scale game project. If we are talking about 2-person boxing game, no ladders/competitions, no big money involved - TCP will cut your development time tremedously.

Read it - but don't blindly believe it! I've seen network coders in games business at work .... sometimes they had very strong opinions that not necessarily were backed up by a corresponding know-how! I don't say the XvT guys are of that kind, but be critical!!

what i'm working on right now (and this is hardly original) is a reliable layer on top of UDP. that way, when there messages i don't need to guarantee will arrive, i can have the advantages of UDP -- i can fire and forget. when i need to make sure things get there, it won't bog down the speedier traffic and i can count on it eventually getting where it needs to be. other developers have taken this path in the past and i don't think it's going to be terribly difficult to get up and running. to get the most out of the reliable messaging, some tweaking and performance tuning are definitely going to be in order, but there are plenty of examples out there (including TCP) that we can probably borrow from in order to maximize efficiency.

if this all comes together and is useful, the code will be open source so everyone will be free to use it, chuckle at it, etc.

Looking forward to see it! Esp. if it were transparently embedded into the NIO package

I definately need guaranteed transmission. IMHO thats the only way to be able NOT to send redundant data and thereby saving *very much* bandwidth. I could be able to give up the streaming characteristics and sometimes even to drop so far undelivered messages in case of new ones available.

I would be interested to know where TCP is wasting resources. Have they made a mistake those days? How can transmission be guaranteed without the things TCP does? What are the tradeoffs?

Looking forward to see it! Esp. if it were transparently embedded into the NIO package

I've written such a beast in C++ some time ago for a comercial game. I have a half finished reimplementation using java nio lying around. I'm currently trying to find the time to finish it.I definately need guaranteed transmission. IMHO thats the only way to be able NOT to send redundant data and thereby saving *very much* bandwidth. I could be able to give up the streaming characteristics and sometimes even to drop so far undelivered messages in case of new ones available.

What you need isn't guaranteed delivery but what i call "notified delivery". You need to know when a packet didn't reach its destination so you can resend it, or send new data if available. The Tribes2 networking guys came up with this idea first, I think. See:

Looking forward to see it! Esp. if it were transparently embedded into the NIO package

It will probably be a seperate API which actually simplifies the process of using non-blocking datagrams down to only what (I think) we need. So it'll be a bit different but pretty straightforward.

Quote

I could be able to give up the streaming characteristics and sometimes even to drop so far undelivered messages in case of new ones available.

Streaming never really seemed that benificial for the stuff I've done with networking. Messages themselves as well as the underlying protocols all lend themselves to being thought of as packets/messages/whatever in gaming situations (unless you're talking about transferring over a map file or a client upgrade, and in that case opening up a TCP socket for the transfer isn't a bad idea).

Quote

I would be interested to know where TCP is wasting resources. Have they made a mistake those days? How can transmission be guaranteed without the things TCP does? What are the tradeoffs?

It's my understanding that when there are problems with transmission, TCP backs off a bit in order to help net congestion die down. The theory is that if the networks really are saturated with traffic, all connected users are going to experience some dropped packets, and so therefore if they're all running TCP and the protocol elects to back off for a second or two, the congestion will promptly start to clear. On the other hand, selfish game developers don't really care about net congestion, and if we need a message to get there we'd rather just send it 20 times and have it get there in 40ms rather than wait for congestion to die down and get it there in 80ms.

This all sounds good heheh... just hope I can make good on some of it.

I had to write some commercial code that connected Dreamcast consoles to a Java server running on the back end and while it never (to my knowledge) tried to communicate across the ocean, it went coast to coast across the United States with no issues whatsoever (Dreamcast side was C based before people start inquiring).

We tried TCP connections also inside of Germany, but from one crappy ISDN dialup as a server and some other DSL connect. Nothing bad to see. A ISDN connected server should easily be able to host a game of 4-6 bandwidth-wise. By exploiting the knowlegde that a message definately arrives, we come along with 1-2 messages/second.

Our message format is currently highly unoptimized and bloated so there still is much potential for improvement w/o changing the protocol.

Currently I just wouldn't dare to touch protocol - there have been enough sync/deadlock/threading issues with the well-behaved TCP.....

Ah the old UDP verses TCP debate. I don't currently work in the game biz, but did circa the early/mid 90's. It was the dawn of making online games and where I worked making games Internet enabled was our thing. We did a lot of research on using TCP verse UDP for games. The hardware infrastructure is much better now but the same problems exist.

The simplest way to sum it all up is UDP will beat TCP for raw throughput performance but TCP will usually beat UDP for reliability. In the old days the rules were fairly simple. You used TCP if game state was important (lockstep) and you used UDP if latency was a premium and the game was wiggly enough to have things maybe be inconsistant at times. The rules are significantly more complicated now, but the basic premise is still there.

The best stuff I've seen is some very interesting layers on top of UDP that essentially replicated some TCP functionality but effectivlely did 'read ahead' and 'gap filling' that normal TCP is not designed for - in those cases UDP was nearly as reliable as TCP but much better performing. I'm sure things are much more developed now.

I recently wrote a light cycle game in Java3D which is network playable. I originally based the whole thing on TCP. On my local machine there was no problem, across the LAN it was a little slow, across the internet is was really bad.

With a little investigation I found that the real problem with using TCP for anything performance related is the send/recieve buffers on the IP stacks. TCP won't send an IP datagram until the send buffer is full. So you'll get little blasts of data going across the net. Athough you can reconfigure this on the local machine, the further you go across the net the more stacks you go up and down. This seems to be referred to as latency.

I moved over to UDP and suddenly I could get decent pings between my client and server.

I've actuall written an API over the top of UDP that supports "Message" objects. These can be sent across UDP in a TCP like manner. The API uses the strategy pattern to support being able to plugin different type of UDP handle, e.g. GuaranteedDelivery, IgnoreLoss, ResequenceOnly

If anyones interested in the API drop me a mail.

Interesting thing was that even when I simulated TCP across UDP, i.e. GuaranteedDelivery using ACK messages, I got a far better performance. I guess what it comes down to is that using UDP you have a real control over when an IP packet is sent.

I recently wrote a light cycle game in Java3D which is network playable. I originally based the whole thing on TCP. On my local machine there was no problem, across the LAN it was a little slow, across the internet is was really bad.

How many messages per second did you typically send? How big are they?

This did give me some performance increase, but I got the feeling this was only on the local stack.

>>How many messages per second did you typically send? How big are they?

Light cycle updated the client dependant on their ping. For most people that ended up being 25 updates a second. The message's are in a fairly flagrant manner, so no clever encoding. Update messages were sorta 2 doubles + int + int(MessageID) + int(CycleID). The strategy for guaranteed delivery was also sending ACK messages on top of this.

Light cycle updated the client dependant on their ping. For most people that ended up being 25 updates a second. The message's are in a fairly flagrant manner, so no clever encoding. Update messages were sorta 2 doubles + int + int(MessageID) + int(CycleID). The strategy for guaranteed delivery was also sending ACK messages on top of this.

25 updates per second??? For Tron?? I have a flightsim that comes along with 1-2 updates per second! What do you send there? TCP transmission is guaranteed, so you only need to send when direction changes. Tron is very hard to do on the net I think for its highly synchronous gameplay. But flooding the line won't help to reducde latency.

I think Tron is extremely difficult in terms of a network game bc. motion is highly limited (always strictly straight in one direction, maybe even discreet on a grid) and is very fastpaced. If the 'remote' vehicle is wrong once, there's no way to interpolate towards the correct position. [more to come, must play Q3A NOW!]

However, the only reason I can really understand for using TCP is the simplicity of the related API. You could argue there was a bandwidth saving, and I'm not going to say its not without running some tests

I at least found with a little work on a wrapping API for UDP I can use UDP as a stream protocol simply without undue effort.

[I'll post the current state of API on the newdawn site, I'm afraid it may not be the most well documented of source]

I've seen this come up several times on various games-developer (pro and hobbyist) mailing lists. I've also talked about it with network-protocol researchers and people working in massive scale environments.

The person who warned "many don't really know what they are talking about" was giving very good advice. The X-wing-versus-tie-fighter article is really embarassing; the author shows how stupid and lazy they were not to bother learning about TCP and UDP before they started using them. Many of their mistakes are equivalent to never using the java.util.Vector class because you didn't realise it existed, and hand-hacking from scratch dynamic arrays every single time you need one!

Main differences: TCP: Guaranteed delivery, in-order-arrival, connection-based, compressed automatically on slow connections (99% of 56k modems do significant TCP compression - but you don't notice if you download a ZIP file; you do when you download TXT files).

UDP: One-way-only (cannot respond down the same channel), connectionless (slight reduction in overhead), does IPv4 broadcast

Gotchas (PLEASE don't ignore these, they are the cause of the majority of TCP/UDP woes in games development!):

1. "Guaranteed delivery" is absolute hell to implement properly. I've seen dozens of "UDP with guaranteed delivery" schemes which didn't work properly (in fact, note: JDK 1.1.x RMI was at one point completely broken because it included a naive implementation of this - RMI couldn't be used in large production environments because it generated so many colliding packets that it brought down the LAN. Yuk. Unforgivably stupid by a company with such a strong heritage in networked computers).

2. Connection negotiation and maintenance is also not trivial.

The TCP standard implementations have a complex state-model (FSM). From memory (but it's been a looooong time since I looked) there are 22 unique states that a TCP system can be in. Most of those are to do with guaranteed delivery and connection handling (the two bits people most frequently try to add to UDP). Sun's implementation broke (we think) because they "forgot" to include the "random-delay backoff before re-transmit".

Compare this with the (again from memory) four states of UDP, and you can see there is a LOT of work if you want to achieve the benefits of both.

3. TCP is normally as fast or faster than UDP. Normally, UDP is very inefficient and wastes bandwidth (no, seriously), mainly because of small packet-sizes. For VERY small packets, UDP is more efficient, because it has a much smaller constant-overhead-per-packet. From memory, the numbers are something like 15 bytes overhead per-packet for UDP, compared to about 30 for TCP. But, TCP packets can be MUCH larger, so that 30 bytes CAN get sent much less often.

Even games sending lots of messages per second may find TCP is fundamentally faster (but then they get bitten by the next problem, sooner or later). If you experiment on your LAN, you can often get TCP running faster; but don't bother - the next problem will screw you if you deploy your game like this.

4. The vast majority of games developers only have one problem with TCP (but often mistakenly believe they need more!). They need to remove the "in-order arrival". Whenever you hear about "TCP is sloooow" or "TCP has high latencies", you are listening to someone who is 99% likely to have bitten by this problem but not understood it.

The problem is that if you send 30 packets, and the fifth one gets dropped, but packets 6-10 arrive OK, your network stack will NOT allow your application to see those last 5 packets UNTIL it has received a re-transmitted packet 5.

5. Lastly, there ARE alternatives to TCP and UDP. Not surprisingly, since almost every game finds that neither is really good enough (the games that just go TCP only suffer weird stuttering, the ones that are UDP only often get players freezing, or their guns not firing because of lost packets). The last time I looked, ENet seems to be the best widely/freely available implementation around, but people have suggested several others to me, including: RAKnet (sp?) RDP (covered by an official internet RFC)

There are a LOT of commercial implementations of "the best bits of UDP and TCP, implemented efficiently". Most are as cheap as they should be (tens of dollars) given that so many companies have written their own.

There are SO many implementations lying around that unless you already have one, you REALLY shouldn't implement your own - there's no excuse (unless you enjoy pain? ).

Main differences: TCP: Guaranteed delivery, in-order-arrival, connection-based, compressed automatically on slow connections (99% of 56k modems do significant TCP compression - but you don't notice if you download a ZIP file; you do when you download TXT files).

UDP: One-way-only (cannot respond down the same channel), connectionless (slight reduction in overhead), does IPv4 broadcast

When you say "one-way-only" you make it seem like a negative. There's just no concept of a channel to respond down. Just a nit-pick...

Quote

1. "Guaranteed delivery" is absolute hell to implement properly. I've seen dozens of "UDP with guaranteed delivery" schemes which didn't work properly (in fact, note: JDK 1.1.x RMI was at one point completely broken because it included a naive implementation of this - RMI couldn't be used in large production environments because it generated so many colliding packets that it brought down the LAN. Yuk. Unforgivably stupid by a company with such a strong heritage in networked computers).

yes and no. if you need a generalized solution that you can use in all kinds of situations, it's going to be difficult to beat TCP. on the other hand, the specialized conditions a particular game (or class/genre of games, perhaps) can be designed for, IMO.

Quote

2. Connection negotiation and maintenance is also not trivial.

The TCP standard implementations have a complex state-model (FSM). From memory (but it's been a looooong time since I looked) there are 22 unique states that a TCP system can be in. Most of those are to do with guaranteed delivery and connection handling (the two bits people most frequently try to add to UDP). Sun's implementation broke (we think) because they "forgot" to include the "random-delay backoff before re-transmit".

Compare this with the (again from memory) four states of UDP, and you can see there is a LOT of work if you want to achieve the benefits of both.

Just because TCP has 22 states does not mean that another go at guarantees needs it!

Quote

3. TCP s normally as fast or faster than UDP. Normally, UDP is very inefficient and wastes bandwidth (no, seriously), mainly because of small packet-sizes. For VERY small packets, UDP is more efficient, because it has a much smaller constant-overhead-per-packet. From memory, the numbers are something like 15 bytes overhead per-packet for UDP, compared to about 30 for TCP. But, TCP packets can be MUCH larger, so that 30 bytes CAN get sent much less often.

UDP and TCP both use the same type of packets. When TCP is *slower* (which is farily often), it's usually because of its various net congestion algorithms -- which aren't really a good thing for gaming. And UDP is no more or less efficient than TCP.

Quote

4. The vast majority of games developers only have one problem with TCP (but often mistakenly believe they need more!). They need to remove the "in-order arrival". Whenever you hear about "TCP is sloooow" or "TCP has high latencies", you are listening to someone who is 99% likely to have bitten by this problem but not understood it.

The problem is that if you send 30 packets, and the fifth one gets dropped, but packets 6-10 arrive OK, your network stack will NOT allow your application to see those last 5 packets UNTIL it has received a re-transmitted packet 5.

agreed..

Quote

5. Lastly, there ARE alternatives to TCP and UDP. Not surprisingly, since almost every game finds that neither is really good enough (the games that just go TCP only suffer weird stuttering, the ones that are UDP only often get players freezing, or their guns not firing because of lost packets). The last time I looked, ENet seems to be the best widely/freely available implementation around, but people have suggested several others to me, including: RAKnet (sp?) RDP (covered by an official internet RFC)

These protocols, unless they are running at the OS level, are not necessarily going to be running any better than something you roll yourself. And chances are, they probably aren't optimized for gaming.

Quote

There are a LOT of commercial implementations of "the best bits of UDP and TCP, implemented efficiently". Most are as cheap as they should be (tens of dollars) given that so many companies have written their own.

There are SO many implementations lying around that unless you already have one, you REALLY shouldn't implement your own - there's no excuse (unless you enjoy pain? ).

If you know of anything that is particularly well done for gaming (and is implemented in Java!) I'd love to hear about it.

When you say "one-way-only" you make it seem like a negative. There's just no concept of a channel to respond down. Just a nit-pick...

Sorry - I was trying to make it clear for people new to this one of the practical differences between "connection" and "connectionless" protocols. You're absolutely right it's not a negative - I didn't mean to imply that.

Quote

yes and no. if you need a generalized solution that you can use in all kinds of situations, it's going to be difficult to beat TCP. on the other hand, the specialized conditions a particular game (or class/genre of games, perhaps) can be designed for, IMO.

Just because TCP has 22 states does not mean that another go at guarantees needs it!

I didn't say it explicitly, and logically you're correct, but in fact - those 22 states are really only there because they are ABSOLUTELY necessary to get a decent, working implementation (perhaps a few can be omitted - I've tried but couldn't get it down to fewer than about 18 ). TCP is annoyingly complex to implement - it was obviously designed with the hope ofbeing as simple as possible, given that it has to be implemented in hardware all over the place, running at 10's of Gigahertz. There's very little unnecessary overhead. I would be very surprised to see people come up with a design that is significantly less complex and still does the job - anyone who is uncertain should have a look at the RFC's, and the block diagrams (don't have links to the block diagrams, only my own printouts, but they can be found in most good TCP/IP books), and see for themselves; once you fully understand it, you'll see that most states are necessary .

Quote

UDP and TCP both use the same type of packets. When TCP is *slower* (which is farily often), it's usually because of its various net congestion algorithms -- which aren't really a good thing for gaming.

UDP and TCP do NOT use the "same type of packets". The packets they do use are both embedded in the same lower-level-protocol packets (IP). UDP's major bandwidth efficiency savings come from having a packet with smaller header. If you have to send many packets per millisecond, then it can make a big difference (12 bytes saved per packet).

Yeah, the "standard" net congestion algorithms are indeed crap; but there are much better ones available. Tiny downloads for most OS's - e.g. TCP Vegas (extensively linked to on Google). But sadly these are of little use to games developers, unless you roll your own UDP + bits-of-TCP, and copy the Vegas implementation into your congestion-control part (instead of using the standard TCP congestion control).

Quote

And UDP is no more or less efficient than TCP.

Rubbish; I wouldn't mind - but I explicitly explained this above. I did make a stupid mistake in claiming that UDP payloads were limited at a smaller figure than TCP - putting me in the same category as all the others who spout ill-informed stupid mistakes when talking about this stuff . Whoops:

UDP and TCP are both only limited by the IP max packet size, which is (216 - 1) bytes. However, on most links between hosts/routers, there is an MTU (chosen by the physical devices) which is often much lower. Ethernet is typically 1500 bytes. TCP can automatically discover the MTU and be more efficient. UDP doesn't bother, and tends to waste bandwidth - either because you send small packets (very wasteful) or because the ones you do send are too big, and cause fragmentation (requires extra delay to negotiate, and extra packets).

If you are on a 1500 MTU link (i.e. typical ethernet), and you send ANY UDP packet of size less than 730 bytes (i.e almost 1kb per packet), then you are "wasting" bandwidth compared to TCP (which would automatically be using about 1460-byte payloads). But if the MTU changes, or the link is a modem (typical MTU's as low as 300), then if your UDP packets are larger than about 550 bytes, you again are wasting bandwidth compared to TCP (because each fragment incurs an overhead of an additional 20 bytes).

These protocols, unless they are running at the OS level, are not necessarily going to be running any better than something you roll yourself. And chances are, they probably aren't optimized for gaming.

However, they do WORK. Most UDP+bits implementations do not work - they kind of work, or work in 95% of situations, and then go titsup the first time a cable-modem user talks to an ADSL user, or they crash once every 10,000 packets, or etc. Or (as in SUN's RMI) they start chain-reactions leading to packet-storms, and can bring down a LAN segment! The problems are nearly all subtle, all special cases. It's really hard being sure you've taken account of every situation.

I'd just like games developers to think twice, then think again, and finally think twice more, before rolling their own...

That said, I agree with you in spirit: most games companies have so far just rolled their own, and not released them. I'd really like to see a common standard (RDP has already stolen the name "Reliable Datagram Protocol", AFAIAA). However, there are quite a few commercial offerings that include java versions (or claim to "very soon now").

I'll admit I'm not an expert on networking but I've observed the following things to be more or less true.

As I see it minds many times smarter than mine have spent many more hours figuring out how to make TCP faster/efficent/better than I can do in years. I don't have false hopes that I can somehow do better than the people who've tried before me.

I don't see why people don't just use one TCP connection for reliable packets and one UDP "connection" for packets that don't need to be reliable. With the exception of running out of file handles it seems like the best of both worlds. IMO anything else is reinventing the wheel.

As I recently learned at work not fully understanding the interface you are programming for can lead to horrible results. In my case it was a web application running out of file handes because I thought I'd be smarter than the lib I was using and cache connection objects.

Familar with the problem where cable modems can't download worth a damn when you're saturating the upstream? Backing off the upstream even 1% really improves downstream performance. Developers seem to expect 100% throughput and refuse to accept that 99% throughtput may actually perform many times better.

I think the point here is that we're talking about gaming. You can be as bandwidth concious as you like but in the end if the user presses a key (which needs to send a packet) the difference of a few milli-seconds can make the difference between playable and not playable.

From talking to a few more independant sources (read: work collegues) the real disadvantage of implementing a TCP like protocol over UDP is the likely bandwidth usage. TCP for the right use in other words is great, I'd just argue real-time gaming comms isn't it. If I read the above right, I'm just agreeing

As to implementations of guaranteed delivery by other developers not being any good, I'm slightly bias here. However, I really do get tired of hearing this same old story, "someone else wrote one so its bound to better than anything I can do". Generally the people who write these things are software engineers just like us? In the case of TCP, its had years and years of testing, but it was designed as a general purpose stream protocol. Thats not nessercarily (spelling?) the best thing for gaming circumstances.

As for the header size - one thing which makes it more complicated is that TCP/IP is often optimized for modem links. If enduser modem is weakest part of connection (and it often is), TCP/IP can be actually better per-packet (ignoring packet loss at the moment) - I think that optimized header is around 6 bytes then.

I do not think that 8 versus 20 bytes figure is fair. You need to take IP header into comparison - it takes 20 bytes itself. So it is at least 28 versus 40. You also get low level header, but it changes from network to network - but it will be again in 5-20 byte size.

Trick is, that 6-byte figure for TCP/IP over modem is total figure - so we are talking about 6 bytes for TCP/IP versus 28 bytes for UDP...

As for the debate itself - I think it is easiest to look at successful games. Unreal, Quake, Tribes - all these engines need close to real-time updates and all use UDP. At the moment I'm betatesting certain space game, which uses TCP/IP for connection. But this is no-arcade, third view, 1 position update per second, lag for 5 seconds and nobody cares kind of game.

Can you give me examples of really fast paced, sucessful game, which has used TCP/IP for network communication ?

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org