Setting RTO MAX value in Wince6.0 RRS feed

  • Question

  • Hi all,


    I'm trying to configure some TCP parameters for TCP connections in our device.

    I have not been able to find out how to configure RTO MAX parameter. All that i have found is that this parameter is adjusted dynamically according to the values of RTT and SRTT parameters.


    But, is it possible to fix a constant value for the RTO MAX parameter in Wince6.0?


    Thank you very much,


    Best regards,

    Wednesday, November 23, 2011 2:46 PM

All replies

  • I think that the basic answer is "no". We might be able to direct you further if you tell us *why* you want to configure a fixed value for the RTT MAX. Doing so would potentially cause your TCP/IP stack to become less adaptive to various network configurations.

    Paul T.

    Wednesday, November 23, 2011 3:37 PM
  • Hi Paul,


    We use Wince 6.0 as the OS for a custom developed embedded device.

    That device is used for some specific functions inside a custom private network entirely managed by our customer. There are some other devices connected to the same TCP network. There are also some requirements in the TCP parameters configuration for all the devices installed in that network and one of them is the maximum RTO (retransmission timeout) value. That device uses a standard protocol to communicated with the rest of the devices in the network, and that protocol uses TCP. Setting a maximum value for RTO (and other TCP parameters), permits to fix some limits (worst cases) to ensure reconnections processes between the devices.

    So, in brief, it is a customer requirement. The aim is to ensure a maximum value for the retransmission timeout, which will be lower than the maximun value reached by the TCP adaptative algorithm.


    You refer in your post to the RTT parameter. I'm refering to the RTO parameter instead.

    I found some defines in iprtrmib.h file like: MIB_TCP_RTO_CONSTANT. What are these defines used for?


    I should understand that there is no way to ensure a maximum RTO value?


    Thank you,


    Wednesday, November 23, 2011 4:21 PM
  • Nobody else knows?
    Monday, December 12, 2011 7:03 AM
  • OK, so you really need to change when you time out a receive. I don't believe that there is a way to adjust that parameter, as mentioned. However, you can, of course, implement your own time out mechanism at the application level using a non-blocking socket (for example), and a timer.

    DWORD tickStart = GetTickCount();

    int result;

    while ( ((result = recv( socket, buffer, length, flags ) ) != SOCKET_ERROR) && (result != length) && (result != 0) )    // You may also have some other means of wanting to stop the recv...


        if ( GetTickCount() - tickStart > myTimeout )    // Obviously, you want to take care when GetTickCount() rolls over.


            closesocket( socket );

            // Somehow indicating to the outer code that a time out occurred.

            result = SOCKET_ERROR;




    Paul T.

    Tuesday, December 13, 2011 3:21 PM
  • Paul, thank you for your response.


    I'm afraid that this solution is not the good one for my problem. Modifying the RTO maximum value will allow us to fix a maximum value for the retransmission timeout but at tcp level (imagin that we send some information over a TCP socket, what we want to fix is the maximum timeout for the TCP protocol retransmissions to delivery the information)

    That retransmissions are done without the application to realize that these retransmissions are being done. They are done at a lower level...

    What will also be enough for us, is to modify the operating system source code to change the RTO maximum value. The need to modigy it from an application is not mandatory.

    So, does anybody know the point of the operating system source code where that value is defined, and if it can be recompiled?


    Thak you very much.


    Thursday, December 15, 2011 12:13 PM
  • There's no enough source code available to rebuild things to that level, as I recall. Some portion of the TCP/IP stack is given, but not all of it, even in the super-secret source code package.

    Paul T.

    Monday, December 19, 2011 11:16 PM