How does TCP’s sliding window affect TIBCO Rendezvous?
Article ID: KB0090106
Updated On:
| Products | Versions |
|---|---|
| TIBCO Rendezvous | - |
| Not Applicable | - |
Description
Resolution:
A TCP sliding window is the amount of outstanding (unacknowledged by the recipient) data a sender can send on a particular connection before it gets an acknowledgment back from the receiver.
The primary reason for the TCP sliding window is congestion control. If there is a possible congestion and if the bottleneck is at the transmitting host then there is no problem; if the bottleneck is not at the transmitting host, and if the transmission occurs too fast for the receivers, this will result in data being lost. When a data-loss is detected, the TCP window throttles the transmission speed down to a level where congestion and data-loss will not occur. All this is taken care of in the underlying TCP/IP Stack. The TCP window size can be tuned via the TCP parameters at the operating system level or at the application level.
From RV release 7.4.0 and onwards, the RV daemon connection will include a TCP window scaling option for all TCP connections it establishes - in RV 7.4.0 the window size is hard-coded to 128K, but from RV 7.5.0 the window will only be set to 128K if this number is larger than the current setting returned by getsockopt().
Given appropriate operating system configuration, one should be able to observe that TCP sliding window option is turned on in the SYN packets. However, it is important to realize that this feature just enables TCP to open larger windows, but whether that will actually happen depends on the dynamics of a given connection. In other words, just because testing never shows a window bigger than a certain size, it does not mean that TCP would not open a window larger than that if the TCP implementation determines that given current network conditions a larger window would be appropriate. Actually, it is up to the TCP/IP stack to decide the size of the window given the network conditions at that moment in time.
Issues involving the TCP sliding window usually arise when there is a high latency in the connection, where the throughput of RV messaging is not as high as expected considering the bandwidth that should be available. To determine the latency, try to FTP a large file between the same two boxes and compare its throughput to that of RV. This is a good starting point in attempting to find out whether RV is able to take full advantage of the available bandwidth. This, of course, assumes that neither of the boxes is experiencing any other issues, such as high memory or CPU usage.
A TCP sliding window is the amount of outstanding (unacknowledged by the recipient) data a sender can send on a particular connection before it gets an acknowledgment back from the receiver.
The primary reason for the TCP sliding window is congestion control. If there is a possible congestion and if the bottleneck is at the transmitting host then there is no problem; if the bottleneck is not at the transmitting host, and if the transmission occurs too fast for the receivers, this will result in data being lost. When a data-loss is detected, the TCP window throttles the transmission speed down to a level where congestion and data-loss will not occur. All this is taken care of in the underlying TCP/IP Stack. The TCP window size can be tuned via the TCP parameters at the operating system level or at the application level.
From RV release 7.4.0 and onwards, the RV daemon connection will include a TCP window scaling option for all TCP connections it establishes - in RV 7.4.0 the window size is hard-coded to 128K, but from RV 7.5.0 the window will only be set to 128K if this number is larger than the current setting returned by getsockopt().
Given appropriate operating system configuration, one should be able to observe that TCP sliding window option is turned on in the SYN packets. However, it is important to realize that this feature just enables TCP to open larger windows, but whether that will actually happen depends on the dynamics of a given connection. In other words, just because testing never shows a window bigger than a certain size, it does not mean that TCP would not open a window larger than that if the TCP implementation determines that given current network conditions a larger window would be appropriate. Actually, it is up to the TCP/IP stack to decide the size of the window given the network conditions at that moment in time.
Issues involving the TCP sliding window usually arise when there is a high latency in the connection, where the throughput of RV messaging is not as high as expected considering the bandwidth that should be available. To determine the latency, try to FTP a large file between the same two boxes and compare its throughput to that of RV. This is a good starting point in attempting to find out whether RV is able to take full advantage of the available bandwidth. This, of course, assumes that neither of the boxes is experiencing any other issues, such as high memory or CPU usage.
Issue/Introduction
How does TCP’s sliding window affect TIBCO Rendezvous?
Feedback
Yes
No
Powered by
