Hi,
I’m trying to network two applets (embedded into applications, i know you can’t network applets), and i was wondering which would be the better option - UCP or TCP/IP?
I know UDP just keeps firing out packets, and doesn’t need any recognition of packet reception, the game is a boxing game - so it has to be as close to real time as possible.
any suggestions or tips would be greatly appreciated!
Very different opinions on that and no only true answer.
This problem also has some dimensions to consider.
If you can miss messages, UDP is fine. If you want to make sure that the remote player also hits when your local player hits, TCP is the easiest solution to have.
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.
thanks a million, i appreciate the information, and i was kinda coming to the conclusion that TCP would be the better option!
Very wise. I use TCP only.
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 read
I especially like the sentence
“TCP is evil. Don’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.
[quote]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.
[/quote]
But this holds very well for UDP things too!
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:
http://www.gdconf.com/archives/2000/frohnmayer.doc
You can implement this with a sliding window algorithm. I have done it, for said game, on top of UDP and it worked beautifully, but was later dropped (against my advice) in favor of DirectPlay.
Ole
[quote]Looking forward to see it! Esp. if it were transparently embedded into the NIO package
[/quote]
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.
[/quote]
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?
[/quote]
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).
? What’s the essence? Did you use TCPor what?
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…
What I observed earlier when using TCP via DirectPlay was, that overcommiting the line can lead to TREMENDOUS latencies. 10 sec, 15 sec.
So if the app is designed to pump out a message 10 times/sec, this may lead to real serious issues! This is a real ‘no go’.
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.
Wow! Something I can actually comment on!
Apologises in advance for the long post,
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.
Apologies again for the long message,
Kev
EDIT: Incidently, the API is based on NIO
could we borrow your input over at http://www.josrts.org/ in the “Design” forum? this very issue is up for debate and it sounds like your experience would be very pertinent ;D
[quote]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.
[/quote]
Socket.setNoDelay(true) to disable the Nagle’s algorithm didn’t help?
[quote]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.
[/quote]
How many messages per second did you typically send? How big are they?
Socket.setNoDelay(true) to disable the Nagle’s algorithm didn’t help?
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.
Kev