Networking

Browser based open source cross platform solution for easily playing customizable card games online vs other players. Lead dev: knitter
Post Reply
User avatar
xarn
Posts:101
Joined:Thu Oct 13, 2011 11:50
Networking

Post by xarn » 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?
User avatar
Ravenchild
developer
Posts:131
Joined:Sat Sep 04, 2010 19:21
Location:Germany

Re: Networking

Post by Ravenchild » Sun Oct 23, 2011 15:49

xarn wrote:Hi,
..the other question is of course: is such responsiveness necessary or don't we care about a 2 seconds delay?
For now we certainly don't care for it. Playtesting is more important than anything else at the moment, so having a working client soon really matters, even if it uses plain HTTP.

Later on we can still write a proper tool for playing online. We aren't famous yet and therefore I think the latency in Sandscape is not a problem.

And keep in mind that Sandscape is mainly intented as a testing environment for new ideas.
Knitter
developer
Posts:87
Joined:Mon Jan 17, 2011 11:26
Location:Leiria, Portugal
Contact:

Re: Networking

Post by Knitter » Sun Oct 23, 2011 16:05

xarn wrote: 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.
It will take more, an update is, currently, only requested every 3 seconds, a request/sec is too much.
xarn wrote: By using websockets, we would reduce this latency to:
latency userA-server + latency server-userB = 200ms + 200ms
I'm always very skeptical about calculating these times on paper, things are never the same on a real implementation :).

To me, the two second delay would be a bonus since I'm thinking the delay will be bigger :). As for responsiveness, it's always important to have the software be as responsive as possible but I don't see how websockets would improve that since most of the delay from transmitting information is neglectable when compared to all the other delays involved. The time saved on websockets will probably be consumed by all the other actions.
xarn wrote: 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.
And for the time being that decision is already made, websockets are out of the question until this stage of the development process is over.
xarn wrote: 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.
The server has no queue of changes, it has only one game state.
xarn wrote: 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.
And come disabled in some browsers requiring extra work by the user to update, and are implemented in a different way in Firefox requiring extra work to develop. I feel the disadvantages outweigh the advantages.

Like the suggestion about using Canvas, the one about using websockets hits a wall when they come to the project at this state. It's already under full development and near a usable state. I can't just stop and restart, throwing away everything that has already been done. Naturally, when the time comes to evaluate the project we can change or modify any part of it, but for now I can't just do that or risk not getting anything done.

I would suggest that anyone interested in experimenting with other technologies create a mock up or prototype using those technologies, thus providing a demo and a way to test if it's better or worse, if there is gain or not.
Rejoice! For very bad things are about to happen.
User avatar
xarn
Posts:101
Joined:Thu Oct 13, 2011 11:50

Re: Networking

Post by xarn » Sun Oct 23, 2011 16:19

Sure.

(just a note for the browser compatibilities though: http://caniuse.com/#feat=websockets)

Of course, if your code base is already advanced, I agree that the priority is to leverage it in order to provide a practical demo.
User avatar
snowdrop
developer
Posts:798
Joined:Mon Feb 01, 2010 15:25
Location:Sweden
Contact:

Re: Networking

Post by snowdrop » Mon Oct 24, 2011 13:05

knitter wrote:Naturally, when the time comes to evaluate the project we can change or modify any part of it, but for now I can't just do that or risk not getting anything done.
I'll put that as a ticket on trac, so it actually gets done sometime in the later future when all basics are in place and we have something working. I don't picture the evaluation happening prior to 1.2 if one would use "normal versioning" though. Exactly when would depend on you guys and specifically
knitter wrote:I would suggest that anyone interested in experimenting with other technologies create a mock up or prototype using those technologies, thus providing a demo and a way to test if it's better or worse, if there is gain or not.
..the person willing to implement a working tech demo. Although not something that is in a rush I still think it, along with everything else that might benefit the project, should be dumped in trac as soon as possible.

Sockets, if and ever they do actually mature as a practically viable webstandard and reach a state where they work the same cross-broswers, not needing different "browser hacks" etc, are the way to go.

I'm sure the sockets will eventually reach such a point. Now is probably just not that time. Given that things happen quite rapid on that front though it wouldn't surprise me if they were within 1-2 years in a best case scenario. Meanwhile you guys must still use what is already around and standardized, else you won't ever get anywhere. At least by doing so you will still end up getting something that works on almost anything and that can be used to show of your efforts, making it easier to attract more devs, patches etc.
User avatar
xarn
Posts:101
Joined:Thu Oct 13, 2011 11:50

Re: Networking

Post by xarn » Mon Oct 24, 2011 13:31

I'll put that as a ticket on trac, so it actually gets done sometime in the later future when all basics are in place and we have something working.
I'm unsure you measure the impact of such a decision. ;) It is not merely a cosmetic change, it impacts how the software itself is structured and how the client/server interact.

With http requests "Knitter's style":

userA => server: move card X to Y
userA <= server: ok

userB => server: is there some news?
userB <= server: nope
...
userB => server: is there some news?
userB <= server: yeah! Here is the new game state!


With websockets "xarn style":

userA => server: move card X to Y
server => userA: ok
server => userB: move card X to Y


So, basically, how the software works is already completely different. With http, it is a infinite loop with poll server / update game state. With websockets, it's event driven. Then, to a lesser extend, Knitters prefers to communicate the whole game state while I would be inclined to just communicate the incremental changes.

Anyway, you can't swap these like it would be a couple of code lines, it impacts the very essence of how the software logic works.

Anyway, besides of this I agree that the main objective is to have something playable first and foremost. If Knitter's is close to have something playable, then of course it makes most sense to leverage it.

Nevertheless, in the meantime, I'm trying to toy around with a small prototype ...although i try to limit my time here ...i've some urgent matters in live which I should deal with.
Knitter
developer
Posts:87
Joined:Mon Jan 17, 2011 11:26
Location:Leiria, Portugal
Contact:

Re: Networking

Post by Knitter » Mon Oct 24, 2011 16:26

This will be a bit off-topic but I think it may be important if you try to create a prototype, please take into account that you need to consider that HTML in a browser is completely manipulatable, any user with a developer extension can change, on the fly, the HTML code and the JS code that is executed, therefor you need a way to control basic game settings and rules.

So, if you move a card, that card needs to exist and be known by some entity that controls the game and says the card is valid. Also, client's can't know the real database ID for a card, or in any other way be able uniquely identify a card or else you risk allowing a user to create a false deck and to know the cards you opponent may hold in hand. Naturally it will depend on how you think and solve the problem, but don't forget that it exists, at least for the very simple and basic rules since game rules are the sole responsibility of the users playing.
Rejoice! For very bad things are about to happen.
Post Reply