Idea to reduce server latency
This only applies to remote protocols with horrible efficiency... like Minecraft or Teamspeak.
So we know that software sometimes doesn't design things like it should be, in the most obvious of ways. Like Minecraft using TCP which heavily increases bandwidth usage, latency, and removes seamless networking in general.
So, awhile back, I started implementing this idea. What if I made a fake-server that communicated with the real server locally? This server would use its own separate protocol that's more efficient to communicate with the client remotely.
The biggest downside to this is that the client must know about this protocol the fake server uses. So using it with Minecraft is a no go unless I re-implement the client networking.
But for something like a querying server that uses a horrible and innefficient ASCII-based grammar, I think it could come in handy since clients are generally made on the fly for such things. For an example, the Teamspeak 3 Query Server uses an ASCII-based commands that have bad patterns that aren't consistent and change often every update (although their aren't that many updates).
This has security advantages as well. Teamspeak uses Telnet. The fake server protocol isn't restricted to telnet, or rather, it can use any encryption that we choose.
Feedback?
So we know that software sometimes doesn't design things like it should be, in the most obvious of ways. Like Minecraft using TCP which heavily increases bandwidth usage, latency, and removes seamless networking in general.
So, awhile back, I started implementing this idea. What if I made a fake-server that communicated with the real server locally? This server would use its own separate protocol that's more efficient to communicate with the client remotely.
The biggest downside to this is that the client must know about this protocol the fake server uses. So using it with Minecraft is a no go unless I re-implement the client networking.
But for something like a querying server that uses a horrible and innefficient ASCII-based grammar, I think it could come in handy since clients are generally made on the fly for such things. For an example, the Teamspeak 3 Query Server uses an ASCII-based commands that have bad patterns that aren't consistent and change often every update (although their aren't that many updates).
This has security advantages as well. Teamspeak uses Telnet. The fake server protocol isn't restricted to telnet, or rather, it can use any encryption that we choose.
Feedback?
Last edited on
Well let's start with the obvious first question if you don't mind, what protocol do you plan on replacing TCP with? I can't imagine UDP being a valid option in any online game, what would you do about sanity checking? What if a client performs a dirty exit? You may be able to cut out a lot of the overhead but I'd imagine you need the call and response of TCP to make sure the client is still there and to track their information as close to real time as you care to.
Maybe constant heart-beat packets from the clients to the server could be one option, it would remove the need for the server to constantly pole the client and it might save on some of the processing overhead to translate the packets. But personally I would need to see the side-by side performance test in order to compare the two before saying which one is better.
I think the problem here is that while Memory and CPU cycles are cheap and becoming cheaper, bandwidth is becoming more expensive. This is hands down a market failure, and no one in their right mind could argue otherwise, but that I think is the obstacle that needs to worked around. If you could shrink all of the necessary data from the client down to a single packet and somehow ensure delivery without the need for a call and a response. Well then you'd probably be up for a Nobel prize so improving the performance of a video game wouldn't seem as important to you.
Maybe constant heart-beat packets from the clients to the server could be one option, it would remove the need for the server to constantly pole the client and it might save on some of the processing overhead to translate the packets. But personally I would need to see the side-by side performance test in order to compare the two before saying which one is better.
I think the problem here is that while Memory and CPU cycles are cheap and becoming cheaper, bandwidth is becoming more expensive. This is hands down a market failure, and no one in their right mind could argue otherwise, but that I think is the obstacle that needs to worked around. If you could shrink all of the necessary data from the client down to a single packet and somehow ensure delivery without the need for a call and a response. Well then you'd probably be up for a Nobel prize so improving the performance of a video game wouldn't seem as important to you.
closed account (N36fSL3A)
| Computergeek01 wrote: |
|---|
| I can't imagine UDP being a valid option in any online game |
| Maybe constant heart-beat packets from the clients to the server could be one option, it would remove the need for the server to constantly pole the client and it might save on some of the processing overhead to translate the packets. But personally I would need to see the side-by side performance test in order to compare the two before saying which one is better. |
Last edited on
OK, maybe it's a valid option but it certainly isn't a good one. No one likes lag-f**ing and it is a design flaw. I pay good money for the game, the system to play it on and a service from my ISP to run it across, why should some jerk with the equivalent connection speed of a dial-up modem actually have an edge on me?
I don't get your second part, the datagram from the host could easily contain what ever ID info is needed from the client. There is no need for a race condition here.
I don't get your second part, the datagram from the host could easily contain what ever ID info is needed from the client. There is no need for a race condition here.
UDP is used in almost all real-time games such as FPS, RTS, ARTS, and so on. I think you're confused...
Also, there may not be a need to replace TCP sockets, just reduce the overhead of the original protocol or to add security features.
Also, there may not be a need to replace TCP sockets, just reduce the overhead of the original protocol or to add security features.
closed account (N36fSL3A)
| I don't get your second part, the datagram from the host could easily contain what ever ID info is needed from the client. There is no need for a race condition here. |
I think changing TCP to UDP is a bad idea. If the game is using TCP, it probably assumes the protocol is reliable, data is received in the order it was sent, etc. UDP doesn't give you that, so you will basically have to implement your own version of TCP on top of UDP. Which will be just as slow in the best scenario.
On the other hand, changing game protocol from verbose text-based into succinct binary-based may be a good idea. But again - this way you can reduce the amount of data being sent, but there's no guarantee the server response times will be any better. It's possible that the game does not send that much data after all, and reducing it by 50% won't make any noticeable difference. It's the lag that causing problems, and the game is not prepared to handle it well.
On the other hand, changing game protocol from verbose text-based into succinct binary-based may be a good idea. But again - this way you can reduce the amount of data being sent, but there's no guarantee the server response times will be any better. It's possible that the game does not send that much data after all, and reducing it by 50% won't make any noticeable difference. It's the lag that causing problems, and the game is not prepared to handle it well.
| Which will be just as slow in the best scenario. |
That isn't true. Many games make use of UDP while implementing their own protocols on top of them to mimic TCP. They are much better suited for real time game networking then TCP could be.
In fact TCP in most cases is probably the worst possible choice you can make when developing a networked game. Sorry about going a bit off topic but I just wanted to point out why TCP is such a bad choice for most networked games.
The problem with using TCP for networked games is that unlike your web browser or email client networked multiplayer games have real time requirements on packet delivery. For a lot of parts in a game (There is still parts in a game where this is different) it really doesn't matter what happened a second ago we only care about the most recent data.
Whenever a TCP packet gets lost everything on the network comes to a standstill until the packet can be resent. Player input is no longer being processed by the server, updated positions aren't being sent to the clients, ect. So we are waiting and holding up all other packets for a packet that we probably no longer even care about because it is no longer relevant to our current game's state. To top it off all other packets are being queued up during that time and will be fired off instantly and we will have to process all them in one frame.
There is nothing you can really do to fix this behavior with TCP (Nor would you most likely want to) it is just how TCP works.
This is one of the main reasons you don't want a reliable ordered stream. You want your data as quickly as possible without having to wait for lost data to be resent. There is other reasons but I won't go into them in this thread because I am already going a bit off topic here.
In my opinion you should almost never use TCP for networking in games. Instead use UDP and implement a custom protocol on top of it which mimic certain features of TCP that you want and doesn't give you the ones you don't want.
Last edited on
Sorry but you seem to contradict yourself. If a reliable ordered stream is not what games usually need (and I agree with that statement), there's no point in trying to "mimic" TCP with some custom protocol built on top of UDP. If you just want to have the most recent data as quickly as possible, UDP is all you need.
What I was saying earlier is that if the game is using TCP, it may be very hard to change it to use UDP, because the game may assume it is using a reliable ordered stream. And it may be buggy if some data is lost or received in wrong order.
What I was saying earlier is that if the game is using TCP, it may be very hard to change it to use UDP, because the game may assume it is using a reliable ordered stream. And it may be buggy if some data is lost or received in wrong order.
closed account (N36fSL3A)
| Abramus wrote: |
|---|
| What I was saying earlier is that if the game is using TCP, it may be very hard to change it to use UDP, because the game may assume it is using a reliable ordered stream. |
| there's no point in trying to "mimic" TCP with some custom protocol built on top of UDP |
Games do not need streams. Have you ever worked on a networked game project?
Last edited on
| Well if the networking module was designed correctly it's only a matter of changing underlying code. |
| He means that they're cherry-picking some functionality of TCP. Not all of it. |
| Games do not need streams. |
| Have you ever worked on a networked game project? |
Last edited on
| Sorry but you seem to contradict yourself. If a reliable ordered stream is not what games usually need (and I agree with that statement), there's no point in trying to "mimic" TCP with some custom protocol built on top of UDP. |
I don't see where I contradicted myself, but I see where the confusion might lie. You don't want to mimic TCP exactly to the tee, instead you will mimic the features of TCP that you need (Either using the same implementations for the feature or coding a custom one that suits your needs better), and leave out those that you don't.
Basically what I mean is that you are creating your own custom protocol over UDP that has all (That are relevant) the benefits that TCP provides to games without the downfalls.
| If you just want to have the most recent data as quickly as possible, UDP is all you need. |
No UDP alone will be no where near functional for pretty much most games.
| Can you give an example of a TCP functionality that can be "cherry-picked" this way, without making the protocol as slow as TCP? |
1. Sure, you will definitely want the virtual connection functionality of TCP so that is one thing that you will code over UDP.
2. Trying mimic the reliability of TCP but doing it without a stream which causes the packet backups. This is one main aspect where we want some of the reliability features that TCP provides without the downfalls mentioned before.
There is many ways to code this and a lot of them depend on the project. Some thing included are packet ID's, arrival acknowledgements, handling lost packets, ect. Some will be coded basically the same as with TCP some will be drastically different.
3. We also want to implement flow control like TCP does so that we can dynamically scale the rate of data sent based on the connection.
| What I was saying earlier is that if the game is using TCP, it may be very hard to change it to use UDP, because the game may assume it is using a reliable ordered stream. And it may be buggy if some data is lost or received in wrong order. |
Ya that is true, sorry about going a bit off topic there just wanted to point out that custom protocols built on top of UDP will not be just as slow as the TCP protocol.
Last edited on
All this discussion about UDP and TCP makes me think of this library http://enet.bespin.org/ which according to what I have read, makes UDP reliable. Don't know much about it outside what I've read because I've not had a project to try it out yet.
The protocol that the fake server uses would obviously have to be suitable for the real server. For the case of Minecraft (even though I can't change the client networking), we could use TCP for chat messages and unordered UDP packets for movement, looking around, and various other things. Things like opening doors and so on can be reliable. All of these are treated differently in the real Minecraft server protocol so it would be quite easy for us, almost a 1 to 1 translation. Using UDP in this case allows us to discard useless packets, handle packet loss better (by allowing packets to be dropped instead of having to wait for them), and remove the various other features we don't use with TCP (ultimately reducing both bandwidth and latency). The only difference would be how strings are dealt with... the real Minecraft protocol deals with strings in a rather inconvenient manner.
In the case of the Teamspeak Query protocol, we would need a completely different protocol. For one, we would remove the ASCII-based commands with binary ones, which immediately uses less bandwidth. We change how parameters are dealt with to be more consistent and reliable. Even further, we could control how encryption is dealt with, especially since authentication is down over the protocol which is currently via plain text telnet. It will still be TCP based but still slightly more convenient and efficient.
In the end though, this wouldn't even be an idea if people designed their software correctly. It's more of just a solution on how to deal with proprietary software that sucks but everyone uses.
EDIT: Actually, we can tunnel via ssh to to the teamspeak query server but it's not convenient to do in software. Encryption isn't convenient in general though...
In the case of the Teamspeak Query protocol, we would need a completely different protocol. For one, we would remove the ASCII-based commands with binary ones, which immediately uses less bandwidth. We change how parameters are dealt with to be more consistent and reliable. Even further, we could control how encryption is dealt with, especially since authentication is down over the protocol which is currently via plain text telnet. It will still be TCP based but still slightly more convenient and efficient.
In the end though, this wouldn't even be an idea if people designed their software correctly. It's more of just a solution on how to deal with proprietary software that sucks but everyone uses.
EDIT: Actually, we can tunnel via ssh to to the teamspeak query server but it's not convenient to do in software. Encryption isn't convenient in general though...
Last edited on
Topic archived. No new replies allowed.