Hello,
I develop for C6748 on CCS5, BIOS 5_41_11_38 and NDK_2_20_04_26.
How can I set the receive window in the stack?
Anatoly.
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello,
I develop for C6748 on CCS5, BIOS 5_41_11_38 and NDK_2_20_04_26.
How can I set the receive window in the stack?
Anatoly.
Hi Anatoly,
It sounds like you are wondering how to configure some socket timings. A few things I can think of are the keep alive probe times, keep idle times and send and receive timeouts.
To configure the send and receive timeouts, you can do this when creating a socket by setting the socket options SO_SNDTIMEO and SO_RCVTIMEO (see 'getsockopt()' API in NDK Programmer's Guide).
To configure the others, you would need to do this at run time via the NDK configuration infrastructure
Int keepIdleTime = 100; // change to value you want ...
CfgAddEntry(hCfg, CFGTAG_IP, CFGITEM_IP_TCPKEEPIDLE,
CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&keepIdleTime, 0);
Int keepProbeInterval = 100; // change to value you want ...
CfgAddEntry(hCfg, CFGTAG_IP, CFGITEM_IP_TCPKEEPINTVL,
CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&keepProbeInterval,
0);
Int keepProbeTimeout = 100; // change to value you want ...
CfgAddEntry(hCfg, CFGTAG_IP, CFGITEM_IP_TCPKEEPMAXIDLE,
CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&keepProbeTimeout, 0);
For more info, please again refer to the NDK Programmer's Guide, in Chapter 4 "Initialization and Configuration."
Steve
Thank for the information.
I referred to the user guide, and got that there is an option to set a value to receive/transmit buffers of the TCP.
But actually, I wonder how to configure the TCP Receive Window in the NDK?
Anatoly.
Hi Anatoly,
Yes, I believe you need to configure the TCP receive buffer size.
By definition, the TCP receive window is the amount of free receive memory available for the connection (the socket buffer). The socket receive buffer size for a TCP socket is set by the TCP receive buffer. So initially, the window size would be the size of the TCP receive buffer. Then, as data is received, the window size shrinks to be the amount available in the buffer.
Looking at the TCP receive code (tcpin.c line 353), we can see the window size calculation comes from the size of the receive buffer (hSBRx):
// Get our receive window (function should not return <0, but
// check anyway). We also know our window can not shrink.
// (We can not reduce the size of an allocated receive buffer).
win = SBGetSpace( pt->hSBRx );
if( win < 0 )
win = 0;
else if( win > TCP_MAXWIN )
win = TCP_MAXWIN;
Steve
Isn't the receive window of TCP the size on which the protocol expects to receive acknowledges from the remote host?
I mean, if I set the receive window 5K for TCP, so the protocol app will receive an acknowledge only after 5K of data is being received on the side of the host. Am I wrong with the definition?
Anatoly.
Anatoly,
Yes, the size receive window changes dynamically depending on what data the receiving process has received. The initial value is the full size of the receive buffer. For example let's say that it is initially 8K.
If then 2K of data is received, the window may then be advertised as 6K, since 2K of it was just filled up. Then the sending process, when it receives that ACK with new window size of 6K, knows that it can send across 6K more of data and the receiving process will be able to handle that.
Coming back to your question:
Anatoly Odler said:I mean, if I set the receive window 5K for TCP, so the protocol app will receive an acknowledge only after 5K of data is being received on the side of the host. Am I wrong with the definition?
This is not necessarily true. The receiving thread does not wait for its entire buffer to fill up before sending an ACK. It sends an ACK as soon as it can. If you think about it this makes sense as waiting for the entire buffer to fill up before processing data received could be inefficient (e.g. what if the sender were only to send a total of 2K of data?).
So in your example of 5K, if 4K is sent across the receiver may process that and send an ACK back with a window of 5K again. In this example, 4K of the 5K buffer was used, but the receiver would have already processed all of it and so there would again 5K of buffer size (window) available, so the ACK would specify a 5K window.
Steve