8

I am using webSockets to connect a javascript webSocket client to a java webSocketServer (from an Android application), using the Java-WebSocket library. The Android app sends a small message every few milliseconds to the javascript client.

Using the basic (and intuitive) approach for this situation, the delay between received messages, measured inside the javascript Client show (aproximately) the following pattern: 200 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms, 200 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms, 200 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms, 0.1 ms ...

This is the effect of the Nagle algorithm, that is set by default, clumping several messages before sending them.

Since I have not found a way to guarantee its deactivation, I follow the approach proposed in this old question, sending an acknowledge message from the client to the server, and the system behaves properly, but since the acknowledge message has no real purpose (it is more a hack), it should be avoided.

The question is, this keeps being the best solution to this problem? Do you know any way to avoid the clumping?

Thank you.

Community
  • 1
  • 1
Alex
  • 1,449
  • 4
  • 18
  • 28
  • In .NET there is a setting in the socket object to disable the nagle algorithm, probably there is something similar in Java. – vtortola Oct 15 '14 at 12:25
  • Is there a `.flush()` method on the socket you can call after writing to it? – jfriend00 Oct 15 '14 at 19:09
  • 1
    Do you have [`setTcpNoDelay()`](http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#setTcpNoDelay(boolean)) available to you in your library? – jfriend00 Oct 15 '14 at 19:31
  • No flush or setTcpNoDelay methods are present in the library. – Alex Oct 16 '14 at 09:30
  • There is a workaround if you limit your audience to firefox and chrome, you can use WebRTC datachannels instead. It's really fast but not easy to setup since it's mostly for browser-to-browser communication, you won't find many libraries to support it server-side. I use it for a html5 midi control surface and I can tell that if low latency is critical for your project, it's worth it – vincent Sep 20 '15 at 18:52
  • 1
    I did an isolated experiment: https://github.com/valsteen/socketio-nagle-experiment . Conclusion on chrome for android: acks have no effets. But sending filler packets give great result. It may be an option if you need low latency on a local web-based application. – vincent Oct 12 '15 at 12:46

1 Answers1

3

Since no flush or setTCPNoDelay mechanisms seem to be present on the used library, and no other solutions have been proposed, it seems that the acknowledge message solution remains valid as the best solution to this problem.

Alex
  • 1,449
  • 4
  • 18
  • 28