【问题标题】:Best way to avoid Nagle algorithm effects using webSockets?使用 webSockets 避免 Nagle 算法影响的最佳方法?
【发布时间】:2014-10-15 12:23:00
【问题描述】:

我正在使用 webSockets 将 javascript webSocket 客户端连接到 java webSocketServer(来自 Android 应用程序),使用 Java-WebSocket 库。 Android 应用每隔几毫秒向 javascript 客户端发送一条小消息。

使用针对这种情况的基本(和直观)方法,在 javascript 客户端内部测量的接收消息之间的延迟显示(大致)以下模式: 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 毫秒, 0.1 毫秒, 0.1 毫秒, 0.1 毫秒 ...

这是默认设置的 Nagle 算法的效果,在发送之前将多条消息聚集在一起。

由于我还没有找到保证停用的方法,所以我按照this老问题中提出的方法,从客户端向服务器发送确认消息,系统运行正常,但是由于确认消息有没有真正的目的(它更像是一种黑客行为),应该避免。

问题是,这一直是这个问题的最佳解决方案吗?你知道有什么办法可以避免结块吗?

谢谢。

【问题讨论】:

  • 在.NET中socket对象中有一个设置禁用nagle算法,Java中可能有类似的东西。
  • 套接字上是否有.flush() 方法可以在写入后调用?
  • 您的图书馆中是否有 setTcpNoDelay() 可供您使用?
  • 库中没有 flush 或 setTcpNoDelay 方法。
  • 我做了一个孤立的实验:github.com/valsteen/socketio-nagle-experiment。关于 chrome for android 的结论:acks 没有效果。但是发送填充数据包会产生很好的效果。如果您需要本地基于 Web 的应用程序的低延迟,这可能是一种选择。

标签: javascript android tcp websocket


【解决方案1】:

由于使用的库上似乎不存在刷新或 setTCPNoDelay 机制,并且没有提出其他解决方案,因此确认消息解决方案似乎仍然有效,作为该问题的最佳解决方案。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-03-28
    • 2018-02-11
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2011-01-12
    相关资源
    最近更新 更多