3

this is my first post on here. I am wondering if there is any disadvantage to using websockets as a communication method for a non-web-based client application to connect to a server?

I am looking at designing a turn-based game, using a client-server approach. I would like to design the game server so that different types of clients can connect to it. Some might be web-based (in which case a websocket seems ideal); however, others might not be browser-based. If I could use websockets for all of them, I would think that might simplify the server-side implementation.

However, there must be some downsides to using websockets, otherwise every client-server application would be using them, right?

(btw, I am planning to implement the server in Java)

  • 1
    I have implemented a chat over websockets where clients were web (SPA) and smartphones (non-web?). The angular-cli IDE turns your eclipse into websocket server. To mention some examples. Ultimately, it's an IPC via sockets. As HTTP is and not all the HTTP clients are browsers. – Laiv Jan 31 '18 at 22:23
  • @Laiv ok, that's interesting. So, you didn't experience any downsides to using websockets with the non-web clients? – Time4Tea Jan 31 '18 at 23:00
  • The common ones when you are not totally familiar with the protocol. Somes issues in the client-side (web browsers) due to network configurations. Nothing especial. My advice is to make a proof test with different libraries. We had some issues with socket.io and shifted to stomp. Since you are working with Java, take a look to JHipster. Configuring a Spring boot Web app, stomp is implemented out-of-the-box. – Laiv Feb 1 '18 at 5:52
2

While websockets is a very convenient protocol to use for all kinds of internet-connected clients, there are potential disadvantages when non-web clients are involved, based on the availability of suitable communication libraries. At least when some clients will be based on web browsers, as for added web programming convenience, you may want to use a protocol such as Socket.IO on top of the websocket communication.

You state that you plan to implement the server in Java, but you do not mention on what platforms the non-web clients might be implemented. Before deciding on the protocol, you should try to define the most likely programming environments for the clients and check out the availability of client libraries that work with the intended server libraries.

For example, .NET has the Microsoft-maintained SignalR client libraries, but there is no SignalR server for Java. And while there are Socket.IO servers for Java, the clients that exist for .NET may or may not be stable enough. The currently most frequently NuGet-downloaded client library SocketIoClientDotNet has the disclaimer "This library works. There are reports of incidents where it crashes (though I was never able to reproduce them)." on its GitHub page. Other environments may have even more limited library availability.

Thus, the answer is that there may be disadvantages, but only for certain combinations of server and client platforms.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.