Vfrdtyky

I am implementing a small client that connects to a server for online rooms creation.

A client has an API for creating, joining rooms, etc on the server side. All these API invocations against the server wait for a response from the server, that is received in json format.

Now, on the other side, given one of these clients, I want to receive notifications of when another user joined the same room as me, asynchronously.

My guess is that this is not possible to do with a single socket and I will need at least 2 of them:

• one socket for API invocations (since this already uses read/write on the socket) for request and response


• one socket to receive notifications

My questions are:

1. is there a way to do this with a single socket in a reasonable way?
   or


2. it is mandatory to use at least 2 sockets in this setup?

Having the client allocate just one socket (and connect a single TCP connection) is sufficient, provided you have a well-defined messaging protocol between your client and server.

In particular, I suspect that you perceive a need for a second TCP socket connection primarily because you're unsure about how a single-socket solution would be able to handle multiple different kinds of operations (i.e. RPC calls and asynchronous notifications) properly, without one type of operations interfering with the functionality of the other.

In a purely message-passing design, handling everything via a single socket is straightforward -- when your client wants to send a message to the server, it calls your SendMessage() function (or whatever you call it), and your code queues up the bytes to be sent across the socket; conversely, when the server sends a message to your client, your I/O code receives the bytes, and if all of the bytes of the message have been received, it parses them and calls your appropriate callback function (MessageReceived() or whatever) to react to them appropriately. Since your client never blocks anywhere (other than perhaps in some WaitForNextEvent()-type-call such as select() or poll()), integrating multiple simultaneous tasks is not a problem.

In general, I recommend against RPC-style semantics (i.e. where your client code calls a function-call that hides a network operation and the function-call doesn't return until a reply has been received back from the server) because it leaves your client at the mercy of the server and the network's connectivity -- in particular it will cause your client thread to freeze up (blocked in an RPC-call) whenever there is a temporary network outage, which is not a very good user experience.

That said, if you must use RPC-style semantics, asynchronous-notifications are still possible with just one socket; you just have to include code inside your RPC-functions that gives them the ability to call an appropriate callback-function (i.e. SomeAsynchronousEventOccured() or whatever you like to call it) when they receive an asynchronous-event-occurred message from the socket. Note that that means that the asynchronous-callback function can get called before your RPC-function returns its network-provided result, which might be a bit surprising to some programmers, so be sure to document that it is a possibility. (At least it still gets called inside the same thread, so race conditions won't be an issue, though re-entrancy problems might be)

You need only one connection between the server and each client. That connection can transmit messages in both directions (API calls and notifications).

Most socket APIs work like that: You open a port on the server by creating a listening socket. Each client that connects becomes another socket. That socket represents the connection to that client. Likely, you need to maintain a list of all connected clients. There needs to be a single socket bound to an open port.