Websocket synchronisation

[pecksta...@gmail.com]

Currently I am playing around with Vertx and Websockets for a new project  I will be starting soon.  A matching server, game server of sorts.  Now this question might not be a very specific Vertx question but I figured I might as well ask it here too.

I have already set up my websocket server and all is going well. What I am researching now is Websocket synchronisation.  More specifically make sure that when, if there are 4 clients for example, client A sends a message to the server, the server then dispatches the messages to all 4 clients at the same time.  Goal is that the clients also receive it at same time so there is synchronisation, making sure that client C is not 10 messages behind still.  Of course this would create client side lag if one of the clients is way behind and has slow connection.

Now yesterday I found an interesting article on how to Sync Multiple Clients here. What it basically does is before the server dispatches the message to all clients, the server first does a ping/pong with all the clients and then sends the message.  Now to me this sounds like a good way to do it for a single message, while the clients are basically idle.  However when you are in the midst of a game and the client is already sending messages all over the place (streamed player position updates etc), I do not think this has any effect. Of course I could be wrong.

What I cant wrap my head around is if I actually need something like this in the first place.  When the client A message arrives on the server and I hit the websocket handler, I can send the same message to all connected clients.  At that time the server sends the messages at the same time.  Obviously ignoring client connection speed.

websocket.handler(input -> {

  for(ServerWebSocket client: m_clients.values())
  {
    client.writeFinalTextFrame(input.toString());
 }
});

There is very little information out there on this topic so it makes me wonder if it even is a problem I should be worrying about.  Pure theory wise I could do something like stop all sending of stream messages (put in buffer/queue) when a synchronized message has arrived from a client, let the server do a ping/pong to all clients to check if they have processed all messages, send the message and continue with whatever messages are now stored in the buffer. But it sounds for lag waiting to happen.  Also after the ping/pong, if for example client C has a slow connection again, the client will receive this synchronized message too late again... defeating all the purpose.

Anyone has some experience with this or some feedback.

It would be gladly appreciated.

My apologies if this doesn't belong here 100%.

[mathias]

I think that you want to prevent the players to jump and pop around. Every real time app is some kind of chaotic system which means almost everything can happen at any time. For example the ping can increase or the connection could be lost during the game. So in my eyes the synchronisation problem is not related to webosckets but to the design of your game engine. You should handle all position updates of clients as good as possible, respecting the order of messages, timings, physical integrity, game status, player status and for missing messages you could calculate predictions of moving again respecting the physical aspects and so on. I think that the synchronisation issue in game design is not simple at all.

You could make a difference between messages that are guaranteed to be delivered (TCP) and messages that are not that important (UDP). Additionaly you could mix both types of messages during the game regularly. I would also suggest to have both a heartbeat (ping/pong) as well as a timer that drops old messages.

[mathias]

Maybe you could manage more than one buffer which are processed differently in different scenarios. And the design should be as event-driven as possible. So instead of asking the clients to have reached a certain status your clients would send reliable messages to the server at the point they have reached a new status.

[pecksta...@gmail.com]

Thanks a lot for your feedback Mathias.

By now I have done a lot more reading on this topic, searching with the right keywords can make a world of difference, and it now also seems to me that this is something I need to handle in the game engine. Not purely server side.  For example with deterministic lockstep etc  

We decided to go with websockets only for this project but after reading more and more about all these different techniques UDP is always being mentioned and being recommended. For example explained in this great article   Although nothing is stopping me from implementing a lockstep model with websocket only which I will be doing. 

[Jochen Mader]

Please be aware that Websockets (TCP) are the only way to do networking in JavaScript.

There is no UDP-support available in the browser. At least not to my knowledge.

--
You received this message because you are subscribed to the Google Groups "vert.x" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx.
To view this discussion on the web, visit https://groups.google.com/d/msgid/vertx/c5beb758-a16f-4401-a54e-429346d5be0f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jochen Mader | Lead IT Consultant

codecentric AG | Elsenheimerstr. 55a | 80687 München | Deutschland
tel: +49 89 215486633 | fax: +49 89 215486699 | mobil: +49 152 51862390
www.codecentric.de | blog.codecentric.de | www.meettheexperts.de | www.more4fi.de

Sitz der Gesellschaft: Düsseldorf | HRB 63043 | Amtsgericht Düsseldorf
Vorstand: Michael Hochgürtel . Mirko Novakovic . Rainer Vehns
Aufsichtsrat: Patric Fedlmeier (Vorsitzender) . Klaus Jäger . Jürgen Schütz