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.

CC3100: Socket API functionality

Part Number: CC3100


HI,

I am using CC3100 for communicating with a TCP server. I have proprietary protocol that I am using for communication. The size of data transfer varies depending on the protocol frame type. Here the communication is asynchronous, means client or server can send packets at any time. Below is the sequence I have used for communication with server

1. Open the socket (sl_Socket)

2. Connect to the server (sl_Connect)

3. If data need to be send to server, send using sl_Send

4. Receive data using sl_Recv

I have some queries regarding the usage of sl_Recv API as shown below.

*************************If the socket is in Blocking mode *********************

In blocking mode (without timeout), the sl_Recv function will return only if the data is received. Here my doubt is, data is received in serial manner (byte_0, byte_1, byte_2........byte_n).  Whether the sl_Recv returns immediately after getting the byte_0 or wait till complete packet got received? In sl_Recv API there is a parameter for specifying the data buffer length. Why it is required? Does it mean that the sl_Recv returns only after receiving as much bytes as specified by the data length?

*************************If the socket is in Non-Blocking mode *********************

In non-blocking mode we will get SL_EAGAIN if there is no data. What will be the behavior, as explained above for blocking mode

  • Hi Shijo

    1. sl_Recv returns after data is received and it also returns number of bytes received or if the connection breaks
    2. It waits till the complete packet is received
    3. Packet size is limited
    4. Buffer data length is the length is the maximum size of your buffer pointed by your parameter
    5. No it does not wait for the length specified by buffer data length

    The API for sockets is based on Berkeley Sockets, read a bit about it. It will help you a lot

    www.google.co.in/url

    Regards
    Farhan
  • Hi Farhan,

    Thanks for the reply.

    I still have confusion with the socket API.  I am connecting to a TCP server and server can send data of any size at any time. For receiving the data I have implemented a thread. This receive thread will check for data and exit if timeout occurs or data got received. Server is sending data in JSON format. The length of JSON can vary. Since the length is not constant, sl_Recv return cannot be implemented based on the receive data length. So my question is if the sl_Recv returns before getting the complete packet, how can I validate the packet? Whether it will return only after getting the complete application message?

    Thanks,

    Shijo Thomas

     

  • Hi Shijo,

    Because your data packet (JSON message) can be fragmented into more TCP packets, you need read data from sl_Recv() into your buffer and analyse by yourself this buffer to determine when you have all data available.

    Jan

  • Hi Jan,

    Can we set the fragment size of TCP packet? What will be the maximum fragment size?


    Thanks,
    Shijo Thomas
  • Hi Shijo,

    No you cannot. Packet can be fragmented during transferring via infrastructure.

    Size of one TCP packet can be at this type of wlan from 1B to ~1400B. But NWP can buffer incoming packets and return more data at one sl_Recv() call. Max. size depends on Len parameter of this API call. For more information please see programmers_guide in SDK.

    You have no other option than call sl_Recv() repeatedly, store data into large buffer and analyse content of this buffer.

    Jan