[CONTROLLER-1229] TCP Options incorrect - optimized for throughput not latency Created: 30/Mar/15 Updated: 25/Jul/23 Resolved: 19/Jun/15 |
|
| Status: | Resolved |
| Project: | controller |
| Component/s: | netconf |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Anton Ivanov | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Operating System: All |
||
| External issue ID: | 2914 |
| Description |
|
TCP Basics - if you want to implement a command/reply protocol you have to set TCP_NODELAY. This is doubly so when using Netty and abstractions on top of it which form the full command (or response) in one write buffer to write out. In such double-buffering environments the additional buffering in the kernel which happens when not setting NO_DELAY makes no sense and can only do harm in terms of latency. References (I can probably start with TCP Illustrated here): or http://www.techrepublic.com/article/tcp-ip-options-for-high-performance-data-transmission/ and even the (reference) ssh implementation. Quoting from the source of openssh: if (setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &opt, sizeof opt) == -1) Patch to follow shortly. |
| Comments |
| Comment by Anton Ivanov [ 30/Mar/15 ] |
|
Gerrits: |
| Comment by Anton Ivanov [ 30/Mar/15 ] |
|
This is cosmetic for now, because Netty sets the option as it should (in a duble buffering design) to noDelay. However as netty behavior is guaranteed and it should be documented in case netty is replaced one day. So this at present is a cosmetic issue - the initializer should specify the desired behaviour explicitly so it is known and documented (despite NO_DELAY being the netty default at present). |
| Comment by Maros Marsalek [ 19/Jun/15 ] |
|
Commit has already been merged into protocol-framework some time ago, closing. |