Brainstorming a potential direction for updated networking technology for java client to lobby server communication (and also client->client for network games)
So far general consensus is roughly for some form of JSON over Java sockets. Currently we have a custom serialization technology over Java sockets. We would wish to solve the problem where we can't easily make backward compatible updates and would like to switch off this technology.
As a suggestion, I'm thinking we can convert the server to a drop wizard application. This would then give us an API that a client could call.
From there we have a selection of http clients. I'm currently leaning towards Feig (from Netflix)
@DanVanAtta I don't think using HTTP is the best option here, simply because we need the whole functionality of TCP to enable the server to communicate with the client at any given time and not using a dirty technique like long term polling.
I agree on the JSON part though. If we use json or a similar text based serialization and manually encode objects into a json string, we can easily create mappings to be compatible with old versions.
Thanks for feedback @RoiEXLab , could you give some more details or example scenarios where http would be a problem?
@DanVanAtta In all occasions where clients get notified of actions of other clients.
Examples: In the chat panel, during live online games, etc.
Long Polling would work, but it's really a hack and makes life more complicated because you have to manage resources to be cached for a short amount of time, so chat messages don't just disappear when too many chat messages are written at once and the client couldn't yet make a new request.
I did some research, and it seems that there are some third party extensions for drop wizard allowing to use websockets.
They are similar to normal TCP sockets (they build on top of TCP, just like HTTP) and are supported by all common Web browsers.
This would allow us to implement chat features etc. without problems.
We probably want to make use of HTTP/Websocket features like automatic compression to save some bandwidth.
Also we should try to use TLS to encrypt the connection securely (test servers of course don't need this, but it's useful for production, especially because we can use the let's encrypt certificates).
Open to ideas and completely overhauling this. Though even just making it so we can add new methods to interfaces that impact lobby compatibility without breaking it would be a huge step.
Since discussed we've looked into Tyrus as a websocket server that could replace the network technology.
Most helpful comment
Open to ideas and completely overhauling this. Though even just making it so we can add new methods to interfaces that impact lobby compatibility without breaking it would be a huge step.