Networking
Posted: Sun Oct 23, 2011 14:48
Hi,
The following assumes sandscape is browser-based and uses HTML/javscript and not flash.
Then, about the networking, here is some purely "practical" comment.
Let's assume also that we have a latency of 200 milliseconds to the server. (since it is likely we have a single server out there, this seems a reasonable average to me)
Based on classic request responses http calls, the latency for an action would be:
3*latency userA-server + polling latency + 3*latency userB-server = 600ms + 500ms + 600ms = 1700ms
This is an average when an update request is sent twice per second, it might well be higher depending on latency / polling time. In other words, it is very likely that a move / chat message / game action might take nearly 2 seconds to be visible to the other player.
By using websockets, we would reduce this latency to:
latency userA-server + latency server-userB = 200ms + 200ms
Which results in a latency approximately 4 times smaller than with the http requests. In this case, around half a second.
I know this is very technical and seems far away, but the decision to use http requests or websockets is kind of fundamental since it would impact all the networking and the technologies used.
Moreover, the bandwidth would also be impacted: with http requests, every player is constantly polling all the time, and http headers take up many bytes. With websockets, no polling is necessary since the server can push the change to the other users only when necessary.
Lastly, the server does not have to maintain an internal queue of the latest changes of a player in order to be polled, which may simplify it.
Of course, websockets also have their drawbacks, in the sense that it is an emerging standard and not yet 100% finalized, and that most implementations are not yet very mature.
..the other question is of course: is such responsiveness necessary or don't we care about a 2 seconds delay?
The following assumes sandscape is browser-based and uses HTML/javscript and not flash.
Then, about the networking, here is some purely "practical" comment.
Let's assume also that we have a latency of 200 milliseconds to the server. (since it is likely we have a single server out there, this seems a reasonable average to me)
Based on classic request responses http calls, the latency for an action would be:
3*latency userA-server + polling latency + 3*latency userB-server = 600ms + 500ms + 600ms = 1700ms
This is an average when an update request is sent twice per second, it might well be higher depending on latency / polling time. In other words, it is very likely that a move / chat message / game action might take nearly 2 seconds to be visible to the other player.
By using websockets, we would reduce this latency to:
latency userA-server + latency server-userB = 200ms + 200ms
Which results in a latency approximately 4 times smaller than with the http requests. In this case, around half a second.
I know this is very technical and seems far away, but the decision to use http requests or websockets is kind of fundamental since it would impact all the networking and the technologies used.
Moreover, the bandwidth would also be impacted: with http requests, every player is constantly polling all the time, and http headers take up many bytes. With websockets, no polling is necessary since the server can push the change to the other users only when necessary.
Lastly, the server does not have to maintain an internal queue of the latest changes of a player in order to be polled, which may simplify it.
Of course, websockets also have their drawbacks, in the sense that it is an emerging standard and not yet 100% finalized, and that most implementations are not yet very mature.
..the other question is of course: is such responsiveness necessary or don't we care about a 2 seconds delay?