Question

I’m currently making a client-server application which primarily is built to make procedure call to a server and wait for a packet response.

however i would like to make the server ‘push’ news out to the client (at a spontaneous time), but that seems to be a problem if the message arrives when the client listens for another packet response.

Is there a way to split a socket into 2 unique channel streams, through the same socket instance? Or would it be better to make a client thread which only listens for incoming connections and dispatches them to a queue?

What are some common patterns and practices when working with 2-way client-server connection? (Where streams occur spontaneous)

For reminders i’m using Java Socket, ObjectInputStream and ObjectOutputstream. i’m not using Java RMI.

Answer 1

So one of the things you’ll come up against when learning about networking is loss of synchronization. This happens when you ‘hard-code’ a certain set of client-server interactions, for example;

server sends 2 byte status code
client receives 2 byte status code
client responds with 4 byte operation code

If for some reason there is a bug that causes any part of this interaction to not happen precisely as it needs to, then the rest of the program fails because all network interaction is now out of sync. The client might read a set of bytes that it believes represents a string, when really the server is sending an int, and so on. Worst of all you might find that your main network threads deadlock because both client and server are waiting for input at the same time.

With a larger project, where there are certainly bugs, this will happen an awful lot if you code in this style. For this reason, we have something called middleware.

A very common and flexible middleware paradigm is the TLV Message Protocol. You would implement some simple classes (in semi-java-pseudocode);

TLVMessage
    int type;
    byte[] value;

TLVPusher implements Runnable
    OutputStream out;
    Queue<TLVMessage> messages;
    run() {
        while(true) {
            //poll and write front of queue to out (INCLUDING value.length!)
        }
    }

TLVReader implements Runnable
    InputStream in;
    Queue<TLVMessage> messages;
    run() {
        while(true) {
            //read message from in and add to queue
        }
    }

Now you have two threads running on the client, and two threads running on the server. Each end has its own Pusher and Reader. The important thing to note is that because you write the length field to the output stream, the reader always knows how many bytes it needs to read. So even if one message has been serialised incorrectly, its length is still correct and the next message will always be read correctly from the first byte to the last. This way your program can never go out of sync.

You simply add TLVMessage objects to the pusher.queue, and they will arrive at the reader.queue on the other end of the socket. You can then handle the messages (in another, third, thread which watches reader.messages.size()) by their type field.

You do not need to worry about what order things happen in, you have a robust mechanism for passing messages between client and server, in two directions. You have abstracted away the fiddly network stuff, and can just get on with coding.

There are, of course, libraries that do all this for you, but it’s always worth understanding the how and the why in my opinion.