🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
what should i use?
Author
i''m creating a racing simulation, but don''t know what protocol to use. i''d think TCP would be too slow, so i was thinking of using UDP. i''m wondering, what do online racing simulations use? TCP/UDP? perr2peer, client/server? thanks.
a2k
The reason TCP is slower than UDP is because TCP makes sure that the packets it sends have reached their destination sucessfully. If you want to make sure the game data makes it to the receiver without a drop in the packet, then use TCP. If you think a few dropped packets won''t make much of a diference, then UDP is fine. I can''t help you on the server-client, peer-to-peer decisions cause I haven''t had much experience with them yet. Peace.
******************************
"I do not fear computers, I fear the lack of them"
- Isaac Asimov
Drew Sikora
Napali Networks, Inc.
******************************
"I do not fear computers, I fear the lack of them"
- Isaac Asimov
Drew Sikora
Napali Networks, Inc.
It''s not quite that simple. TCP additionally guarantees that the "packets" arrive in the order that you sent them, meaning if you send 10 unrelated packets, and the first one gets dropped, you won''t "see" (at the application level) the next 9 until the first one gets successfully retransmitted, even though they''re sitting there on your computer (in a driver somewhere...)
This ordering that TCP gives you is almost NEVER useful for a game (why would you want to withhold state??). That''s why you should pretty much ALWAYS use UDP for anything even remotely real-time...even if you want it to be reliable data. If you find yourself needing a RELIABLE, ORDERED protocol, then go for TCP... ie downloading large file-like things. Not when you''re transmitting state. Of course you will probably need some form of reliable transmission, but you can create your own protocol on top of UDP. There are a lot of other things built into TCP that you might not want (slow start, etc).
This ordering that TCP gives you is almost NEVER useful for a game (why would you want to withhold state??). That''s why you should pretty much ALWAYS use UDP for anything even remotely real-time...even if you want it to be reliable data. If you find yourself needing a RELIABLE, ORDERED protocol, then go for TCP... ie downloading large file-like things. Not when you''re transmitting state. Of course you will probably need some form of reliable transmission, but you can create your own protocol on top of UDP. There are a lot of other things built into TCP that you might not want (slow start, etc).
Author
how much harder is UDP?
um, also, since it''s a simulation, do you think i should utilize TCP''s robustness? i mean, i would think that in a simulation, not only do you have to send over game state, but also the absolute positioning/rotation of each player. that would increase the packet size greatly. is TCP still a bad idea for racing sim?
a2k
um, also, since it''s a simulation, do you think i should utilize TCP''s robustness? i mean, i would think that in a simulation, not only do you have to send over game state, but also the absolute positioning/rotation of each player. that would increase the packet size greatly. is TCP still a bad idea for racing sim?
a2k
There''s nothing inherently difficult about UDP. In some cases it''s easier.
At anyrate, you''re asking the wrong question. The type of app you''re making is irrelevant, what''s important is what you need out of your communication channel.
Is getting every bit of data, in order, more important to you than just getting *some* data? Then TCP is the way to go. Think carefully about this question. Lets say you get a dropped packet, but then another one comes in one tenth of a second later that invalidates the dropped one anyway. Do you really need the data in the dropped packet? If not you might be better off with UDP. All this of course depends on how much redundency you have in the data you send. Even if some piece of data must get to the other side can you afford to just periodically resend it until you get back an ack?
A related question is how you react to high latency. If the net burps TCP might take a a long time sorting out the mess. If you are using UDP and app is robust you may be able to just ignore it and the worse that happens is some blipping from the lag.
What is your scaling needs? From my (admittedly limited) experience with looking at scaling UDP does much better.
etc.
-Mike
At anyrate, you''re asking the wrong question. The type of app you''re making is irrelevant, what''s important is what you need out of your communication channel.
Is getting every bit of data, in order, more important to you than just getting *some* data? Then TCP is the way to go. Think carefully about this question. Lets say you get a dropped packet, but then another one comes in one tenth of a second later that invalidates the dropped one anyway. Do you really need the data in the dropped packet? If not you might be better off with UDP. All this of course depends on how much redundency you have in the data you send. Even if some piece of data must get to the other side can you afford to just periodically resend it until you get back an ack?
A related question is how you react to high latency. If the net burps TCP might take a a long time sorting out the mess. If you are using UDP and app is robust you may be able to just ignore it and the worse that happens is some blipping from the lag.
What is your scaling needs? From my (admittedly limited) experience with looking at scaling UDP does much better.
etc.
-Mike
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
