Single server for an online game with international access
Author
Is it a realistic plan to have a single server that is accessed by North America and Europe where all players (assumes the players have decent broadband) will have ping times less than 100ms?
I have a dedicated server with serverbeach in their VA datacenter right now and the ping times for 1k packets from sweden and denmark are in the 125-150ms range. All US traffic that I've tested is < 50ms... most is < 30ms.
Do I need to find a better server host that has better multi-carrier connections? OR am I chasing an impossible dream?
I'm wondering how the massive single-shard games like Eve Online are architected... do they spread their servers across multiple physical locations or are they just hosted in datacenters with direct single hops all around the world?
Quote:Original post by NateDog
I have a dedicated server with serverbeach in their VA datacenter right now and the ping times for 1k packets from sweden and denmark are in the 125-150ms range. All US traffic that I've tested is < 50ms... most is < 30ms.
Anything going over Atlantic will be 100ms+.
Which isn't all that bad, all things considered. ~6000km/c = 20ms, or 40ms perfect time. Inside US the max distance could be said to be anywhere in 3-5k range, depending on location, which is close to no theoretical limit.
Transatlantic connections add latency, but again only up to ~3x theoretical.
IMHO, it's pretty impressive.
Quote:I'm wondering how the massive single-shard games like Eve Online are architected... do they spread their servers across multiple physical locations or are they just hosted in datacenters with direct single hops all around the world?
I don't think 100ms latency matters in Eve.
Practical experiments also show that typical controller-LCD latency is ~5-7 frames, which at 60fps means 83-116ms. And apparently, nobody even notices. Excluding the 700fps on CRT CS:S freaks.
I think getting < 100 ms to most of Europe from the US is unlikely to happen, because of the speed of light as well as speed of routers. The distance from VA to Paris, one way, is over 20 milliseconds for light in vacuum (6187 km / 300000 km/s). Electricity in copper is about 30% slower IIRC (culd be wrong), so about 55 ms round-trip just for the best possible signal. Add a few hops of routing on each side, plus the latency of bulk multiplexing/packing and unpacking across the back-haul, and you're quite likely at >100 ms round-trip for most cases.
Massive games are generally architected to hide lag, rather than try to avoid it. Great games find gameplay mechanics to hide the lag. For example, in an RTS, you will select some units, and then give them a command. They unit will play a "yes sir!" animation/sound, and then start moving. The animation is long enough that the command has been sent to all other players, and everyone can execute the command in lock-step.
Massive games are generally architected to hide lag, rather than try to avoid it. Great games find gameplay mechanics to hide the lag. For example, in an RTS, you will select some units, and then give them a command. They unit will play a "yes sir!" animation/sound, and then start moving. The animation is long enough that the command has been sent to all other players, and everyone can execute the command in lock-step.
Author
Thanks. I'll look for some creative ways to try to handle 200-250ms latency.
Let's say I'm going to design for 250ms latency, does that directly impact the rate at which I send messages?
In my game I'm sending 3 updates/sec through a TCP/IP socket and each update is ~400 bytes. So, roughly 1.5kB/sec to each client. This data is sent constantly at this rate while the players are engaged in the game (let's say for 30 min intervals).
Does that seem like a reasonable rate for a client to receive data? I don't have the option of UDP because the game is played through flash and so only TCP/IP connections are available.
In terms of optimizing the packet delivery, are smaller or bigger packet sizes better?
In other words, would it be better (in terms of optimizing packet delivery rates) to send a 200 byte message every 200ms, or to send a 400 byte message every 400ms?
Let's say I'm going to design for 250ms latency, does that directly impact the rate at which I send messages?
In my game I'm sending 3 updates/sec through a TCP/IP socket and each update is ~400 bytes. So, roughly 1.5kB/sec to each client. This data is sent constantly at this rate while the players are engaged in the game (let's say for 30 min intervals).
Does that seem like a reasonable rate for a client to receive data? I don't have the option of UDP because the game is played through flash and so only TCP/IP connections are available.
In terms of optimizing the packet delivery, are smaller or bigger packet sizes better?
In other words, would it be better (in terms of optimizing packet delivery rates) to send a 200 byte message every 200ms, or to send a 400 byte message every 400ms?
Quote:Original post by NateDog...
In terms of optimizing the packet delivery, are smaller or bigger packet sizes better?
In other words, would it be better (in terms of optimizing packet delivery rates) to send a 200 byte message every 200ms, or to send a 400 byte message every 400ms?
If there is no packet loss on the wire and the transmission rate for one TCP packet is less than 200ms, than this will make no difference.
Every packet has a maximum size (MTU) and for ethernet this is 1500 bytes. So both of your messages (either 200 or 400 bytes) will fit in one TCP packet (MTU - size of TCP header - size of IP header).
If the transmission rate for one packet is less than 200ms, but there is a lot of packet loss, than TCP will initiate a retransmission of that lost packet. And in such a case, a retransmitted packet is more likely to not interfere with the next packet 400 ms later than with the one 200 ms later.
So if you can design your program around 400 ms (but stay below ca 1400 bytes for one message to fit in one packet), you will have less problems with bad connections (bad ping, lots of packet loss).
Eve Online have a single server cluster in London. I belive their architecture is similar to mine:
http://www.next-gen.cc/
I seen many post on the Internet complaining about lag in the game, however that seems related to their MS-SQL database backend.
They have a developers blog here where they discuss some technical matters but I found it to be hard getting a good overview of the architecture, there was a link in the developers blog/forum about this some time ago, I can not find it now.
http://www.next-gen.cc/
I seen many post on the Internet complaining about lag in the game, however that seems related to their MS-SQL database backend.
They have a developers blog here where they discuss some technical matters but I found it to be hard getting a good overview of the architecture, there was a link in the developers blog/forum about this some time ago, I can not find it now.
Quote:Let's say I'm going to design for 250ms latency, does that directly impact the rate at which I send messages?
Not really. You can pipeline messages, with multiple messages "in flight" if you want to use a high send rate.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
