• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 42 subscribers
  • Views 1924 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3200 socket option difference: SL_SO_NONBLOCKING vs SL_SO_RCVTIMEO?

Eric Lo
Intellectual 430 points
Other Parts Discussed in Thread: CC3200

Hi,

Using CC3200 as TCP server, a socket is created to receive data from TCP client.


I see there is two options for creating this socket:

SL_SO_NONBLOCKING & SL_SO_RCVTIMEO

    lNonBlocking = 1;
    iStatus = sl_SetSockOpt(iSockID, SL_SOL_SOCKET, SL_SO_NONBLOCKING,
                            &lNonBlocking, sizeof(lNonBlocking));
    if( iStatus < 0 )
    {
        sl_Close(iSockID);
        ASSERT_ON_ERROR(SOCKET_OPT_ERROR);
    }


    sltimeval.tv_sec = 0;
    sltimeval.tv_usec = 3000;

    iStatus = sl_SetSockOpt(iSockID, SL_SOL_SOCKET, SL_SO_RCVTIMEO ,
                            &sltimeval, sizeof(sltimeval));
    if( iStatus < 0 )
    {
        sl_Close(iSockID);
        ASSERT_ON_ERROR(SOCKET_OPT_ERROR);
    }

What is the difference between them?

Question 1)

Is that setting zero to SL_SO_RCVTIMEO, that is:

sltimeval.tv_sec = 0;
sltimeval.tv_usec = 0;


will achieve the same behavior as SL_SO_NONBLOCKING?

Question 2)

if both SL_SO_RCVTIMEO & SL_SO_NONBLOCKING are set, what will be the resulting behavior for this socket?

Thanks!

Eric

  • 0
    TI__Mastermind 27460 points
    Hi Eric,

    A small timeout will behave much like non-blocking socket, but the timeout resolution for blocking is 10000 uS

    -Aaron
  • 0
    Intellectual 630 points

    i am interested too.

  • 0 in reply to made4engineering
    Intellectual 630 points
    Aaron,

    Did you mean that timeout only worked on blocking socket, not on non-blocking socket?

    --Leo
  • 0 in reply to Leo Xu
    TI__Mastermind 27460 points
    For a non-blocking socket, a timeout is not applicable

    -Aaron
  • 0 in reply to made4engineering
    Intellectual 630 points
    Aaron,
    On then non-blocking socket, I timed 15 seconds when sl_recv() timeout after sl_send() and waiting for server response. Where the timeout came from?

    --Leo
  • 0 in reply to made4engineering
    Intellectual 430 points

    Hi Aaron,


    Thank you very much for your help.

    I would like to know more about the behavior of the non-blocking socket.

    Suppose i have a message, let's say the message format is 500 bytes in length, will be sent from a client (e.g. mobile phone) using UDP broadcast method, and this broadcast message will be received by CC3200 using a non-blocking UDP socket, using the simplelink API sl_RecvFrom():

    #define BUF_SIZE     500
    static char g_cBsdBuf[BUF_SIZE];

        iStatus = sl_RecvFrom(iSockID,
                                g_cBsdBuf,
                                BUF_SIZE,
                                0,    
                                sAddr,    
                                (SlSocklen_t*)&iAddrSize );

    Question 1) To receive a complete message 500 bytes, is that i only need to execute sl_RecvFrom() for 1 times and 500 bytes will be stored into g_cBsdBuf? Will the 500 bytes be broken down several segment and I need to execute sl_RecvFrom() for several times?

    Question 2) What is the minimum time interval need to be waited at client side (mobile phone) for the next 500 bytes transmission, so that CC3200 is able to receive the next 500 bytes message ?

    Best Regards,

    Eric

  • 0 in reply to Eric Lo
    Guru 76035 points

    Hi Eric,

    1. This depend on your network infrastructure. But I expect that 500 UDP bytes you receive at one call of sl_RecvFrom(). Exception will be in infrastructure with MTU lower than +/-520B, in this case will UDP packet fragmented (when don't fragment flag in IP header is not set). In real life you will probably not see infrastructure with that low MTU.

    2. This can't be determined, because it depend on your infrastructure. Time-out about 1-2 sec can be reasonable in most cases. If UDP connection is not done via Internet, that timeout can be much lower.

    Edit: One important thing about UDP broadcast in WiFi networks. Reliability of receiving UDP broadcast is not that big as UDP unicast. In case of UDP unicast and TCP are packets retransmitted by WiFi layer if packets are not delivered. In case of broadcast is this type of retransmitting not done.


    Jan