1

I'm currently writing a program that communicates with a server over TCP sockets. I originally planned for the communication to include a message confirming successful communication at the end of correspondence. Either the server and the client would wait for a response after each communication, depending on who initiated the message. However, I later read that a first step in optimizing socket communications is removing unnecessary correspondence, as each message sent has a small overhead while waiting for a response. So I decided to remove the confirmation messages.

However, those confirmation messages were my easiest way of inserting error messages. What is the best method of sending errors over such a Socket system? Am I trying to optimize prematurely?

The server would be on a remote device with a potentially high ping. The requests generally come in large groups, but each request is in reality individual and can be called out of context. It totally depends on user interaction. Therefore, I cannot know how many requests will be made. It's not easy for the client to figure out when the user is done requesting information as well. I had thought of sending a single confirmation method after a group of requests, but the previous sentence makes that impossible.

I am currently using Java for both ends of this program.

  • As a general comment, you're probably prematurely optimizing. To give a more detailed comment, we'd need to know your protocol details. Starting with: does the client expect a response? and how does the server know when it's at the end of a batch? – kdgregory Feb 22 '16 at 14:33
  • @kdgregory I tried to add the information. Is that enough? I think I used the word "batch" incorrectly. – DonyorM Feb 22 '16 at 14:46
  • This seems like premature optimization. Have you done some measuring to prove that the extra overhead is onerous? – Robert Harvey Feb 22 '16 at 16:14
  • You could try something simple, like saving up your replies based on some hysteresis some portion of the network latency. I wouldn't worry about it too much - TCP acks, which are necessary to the protocol, will piggyback on your application confirmations if you time them just right. – Rumbleweed Feb 22 '16 at 19:55
  • @RobertHarvey no I haven't, but my current method (a mysql database direct connection, terrible I know) had been excessively slow, and u think part of the problem is the constant call backs. But I could be wrong. Part of why I asked. I'm not far along in development to test it using production code, and I'm not sure if I'm experienced enough to design a good enough test. – DonyorM Feb 23 '16 at 1:17
3

There are four ways to approach client-server communications:

  1. Synchronous: every request receives a response of some form.
    In this approach, the client will wait for a response after every request, and it will expect every request to have a response. This introduces delays because the client (or server) could potentially be doing something else while waiting for a response. But if the client needs the response, it has no alternative. An example of this style is HTTP 1.x.

  2. Batched synchronous: multiple requests satisfied by a single response.
    If the client can buffer messages, either transparently in a network buffer or explicitly, it's more efficient to send them all at once and wait for a single response. A lot of high-performance messaging protocols work like this.

  3. Asynchronous: client sends without waiting for response; server responds as necessary.
    This is arguably the most efficient way to communicate, at least in a perfect world. It's how TCP works under the covers, how the X Window protocol works, and how many online games work. However, it works best if the request and response are completely independent: for example, SSH sends a character when you type it, and displays the characters that it receives. If you have to match responses to requests, then you run into a whole host of potential problems, ranging from out-of-order messages to running out of memory.

  4. One-way (aka publish-subscribe): client sends message, doesn't expect a response.
    Personally, I see this as a variant of asynchronous communication, but thought it deserved to be called out.

In your case, I think you're stuck with synchronous communication: you don't know how many messages you might send, so you really need to wait for each response.

You could change to a batched mode by sending a flag message at the end of the normal message stream. The server response to the flag message with an overall success or failure response.

The downside of the batched approach is that the client would attempt to send all messages before waiting for a response. Depending on how large the messages are, this could be wasteful. On the other hand, the server could choose to send the error response right away, and the client could devote a second thread to listening for it (which brings you closer to asynchronous).

But you'll probably find that you don't gain a lot of throughput by increasing complexity, and it's far better to be right than fast.

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.