- Forum
- Lounge
- Game Server Design
- Page 2
Game Server Design
| im going to let the experts handle this, but i would assume its along the same reasons as having a file open in two streams |
If this "is" the case I go back to saying using UDP + a reliable UDP layer for certain events is better than UDP + TCP for fast paced games.
If using both doesn't cause any problems all of my arguments are invalid of course.
Last edited on
once again, no expert, but i feel like the reliability layer would cause UDP to lose its speed, at which point wouldnt TCP be better?
It depends on how much a TCP connection effects a parallel UDP connection, which no article I have read has really answered. So "perhaps".
I find it confusing why most people recommend pure UDP for FPS games then when I can think of many things that could be handled better with TCP (just not the movement).
I find it confusing why most people recommend pure UDP for FPS games then when I can think of many things that could be handled better with TCP (just not the movement).
I am a believer in mixing TCP and UDP, mainly because the libraries I use do it for me and I just choose which I want with a boolean and find out which was used on the other end with a boolean.
I have no idea why Minecraft is exclusively TCP, it may just be preference.
In some cases, UDP is not even supported by some platforms (e.g. Flash) so you have to have at least a minimal TCP interface for such cases (if you for some reason are obsessed with using UDP).
I have no idea why Minecraft is exclusively TCP, it may just be preference.
In some cases, UDP is not even supported by some platforms (e.g. Flash) so you have to have at least a minimal TCP interface for such cases (if you for some reason are obsessed with using UDP).
Last edited on
I understand that the libraries let you specify UDP/TCP very easily but that doesn't necessarily mean they want you to constantly use both of them.
I guess seeing as nothing I make will ever be that large scale (network wise) mixing them really shouldn't do any harm. I just wonder when you get very large scale.
Doesn't modern flash semi support UDP now?
I guess seeing as nothing I make will ever be that large scale (network wise) mixing them really shouldn't do any harm. I just wonder when you get very large scale.
Doesn't modern flash semi support UDP now?
I found this earlier when I was playing with some old networking code I had down a few years back after reading Beej's tutorials. Did some searches and this was the first link: http://gafferongames.com/networking-for-game-programmers/udp-vs-tcp/
Yeah I posted that link as it strongly disagrees with mixing UDP/TCP and people argue in the comments over how accurate that statement is.
Yep, that is the answer most people come to.
http://stackoverflow.com/questions/10000437/mixing-tcp-and-udp
But I would still like lower level answers if nothing else than just for curiosities sake.
| I'd recommend using a higher level api like raknet over implementing your own. |
Yep, that is the answer most people come to.
http://stackoverflow.com/questions/10000437/mixing-tcp-and-udp
But I would still like lower level answers if nothing else than just for curiosities sake.
Chat requires everything that TCP offers to be full-featured.
Just about everything else (in a game) doesn't.
There's nothing wrong with having chat be done in reliable UDP but it's tedious.
Just about everything else (in a game) doesn't.
There's nothing wrong with having chat be done in reliable UDP but it's tedious.
Last edited on
How would you do something like picking up items for example?
It can't be pure UDP.
It can't be pure UDP.
@James2250
Yeah, I had missed it the first time through. Great link.
Fredbill is going to use what he thinks is appropriate for him. If it works for him great, if not then failure is the best teacher. For him, it may just be the fun of learning or the idea of the challenge that he likes so no reason to take that away from him with facts.
Yeah, I had missed it the first time through. Great link.
Fredbill is going to use what he thinks is appropriate for him. If it works for him great, if not then failure is the best teacher. For him, it may just be the fun of learning or the idea of the challenge that he likes so no reason to take that away from him with facts.
Things that happen infrequently (less than 5 times per second) should always be left to TCP. Things that happen more frequently are possible candidates for UDP.
Movement should always default to UDP - using TCP for movement can really ruin the experience for players with poor ping.
Chat should always default to TCP - even with lots of players can you really expect to exceed 5 chat messages per second? And packet loss can be really annoying, even if dealt with, so UDP is to be avoided at all costs with chats. TCP guarantees order of messages, as well.
Inventory (including picking up items), level changing, attacks, picking up/dropping items (but not moving with items), etc. should all be TCP.
Exceptions of course are sending assets and level data - even though data packets need to be sent frequently (at max speed even), there's no harm in a long delay between send and receive, while there is harm in packet loss, so TCP should be used. The only concern is overall time, not ping. Players will be on a loading screen anyway and won't mind too much.
To counteract spamming scripts, you can easily kick clients that send more than 20 or so TCP packets per second - there's no reason TCP stuff should ever happen that often.
Movement should always default to UDP - using TCP for movement can really ruin the experience for players with poor ping.
Chat should always default to TCP - even with lots of players can you really expect to exceed 5 chat messages per second? And packet loss can be really annoying, even if dealt with, so UDP is to be avoided at all costs with chats. TCP guarantees order of messages, as well.
Inventory (including picking up items), level changing, attacks, picking up/dropping items (but not moving with items), etc. should all be TCP.
Exceptions of course are sending assets and level data - even though data packets need to be sent frequently (at max speed even), there's no harm in a long delay between send and receive, while there is harm in packet loss, so TCP should be used. The only concern is overall time, not ping. Players will be on a loading screen anyway and won't mind too much.
To counteract spamming scripts, you can easily kick clients that send more than 20 or so TCP packets per second - there's no reason TCP stuff should ever happen that often.
Last edited on
| but i feel like the reliability layer would cause UDP to lose its speed, at which point wouldnt TCP be better? |
What? The reliability is on TCP. Lots of UDP traffic can slow down concurrent TCP traffic, though. This is because TCP tries to be "nice", while UDP doesn't. TCP's congestion control is what kills its performance compared to UDP.
LB has nailed it here. Listen to him. There's nothing inherently wrong with mixing UDP and TCP in a single application.
@rb: that was my point. he said write a reliability layer for UDP, but i will bow out know, because this is going beyond my knowledge
| ResidentBiscuit wrote: |
|---|
| What? The reliability is on TCP. |
I think what Little Bobby Tables was asking is if you do write a reliability layer over the top of UDP (Creating your own custom protocol) if it would be slower then using a TCP socket instead.
Though I could be wrong but to answer your question (If indeed that was your question) it really all depends on the situation. Sometimes yes you will get about the same overhead and performance concerns as with a TCP socket.
Then again other times you will actually get less overhead and better performance if you do write your own reliable protocol over the top of UDP. It really all depends on what you are trying to do and what your requirements are for your problem.
There isn't really one socket protocol that fits all situations you need to choose wisely what one to use (Or whether to create your own protocol) depending on what you need and don't need.
Though I completely agree with LB on this one. Don't be afraid of TCP in real time systems just be aware of when to use them and when not to. For example never use them on movement like LB said. The reason behind this is partially because of the speed/bandwidth concerns and also because TCP's streams are just stupid for this type of replication.
In real time systems like game if you have movement on a TCP protocol when you miss one packet it will hold up all other packets until that packet gets resent (Maybe multiple times) and finally gets through. But by the time that happens the movement data contained in that packet is pretty much useless (We are running our game quite fast) so we held up all other packets (That now all have to get processed in a single frame) just so we could receive data that isn't relevant anymore.
This is why a unreliable protocol like UDP works better for movement. Because if a packet gets lost we just move on because there is nothing we can do to fix it, it really doesn't affect the movement and it isn't noticeable to the user. There is also other things that come into play like predictive movement but that is beyond this topic.
But ya just giving my 2 cents.
Last edited on
| LB has nailed it here. Listen to him. There's nothing inherently wrong with mixing UDP and TCP in a single application. |
Good to hear.
| Though I completely agree with LB on this one. Don't be afraid of TCP in real time systems just be aware of when to use them and when not to. For example never use them on movement like LB said. |
Of course, just because they can be mixed doesn't make them interchangeable, so all good points. Also I realize there are certain cases where mixing them isn't necessary and could cause performance issues.
Looks like in future I can just ignore people that swear UDP/TCP need to be independent (probably should of done that in the first place...).
codegrazer: that was kind of my question. it was more wouldn't it lose the speed it would theoretically have over a tcp socket, not neccesarily become slower than it. but i think i understand now. thanks for the info
closed account (N36fSL3A)
It'd be a lot more manageable for me to just use UDP. If the players complain about messages not being sent to the server, then I'll upgrade it as needed.
It'd be a lot more manageable for me to just use raw SQL queries. If the users complain about SQL Injection affecting the server, then I'll upgrade it as needed.