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.

SIMPLELINK-CC32XX-SDK: Multiple sessions with Telnet connection using TCP socket

Part Number: SIMPLELINK-CC32XX-SDK
Other Parts Discussed in Thread: CC3235MODSF,

Hi,

We are developing an application as a TCP client using the following components:

    Custom hardware with CC3235MODSF
    SIMPLELINK-CC32XX-SDK Version: 5.20.00.06
    Service Pack Version: 4.11.0.0

We are using the Simplelink API to connect to a server using Telnet. After Telnet negotiation the application is just a terminal emulator. Here is how we open the socket:

/* Create a client socket for telnet. */
sd = sl_Socket(SL_AF_INET, SL_SOCK_STREAM, 0);
/* Try to connect to server. */
sl_Connect(sd, (SlSockAddr_t *)&addr, sizeof(SlSockAddr_t));
/* Block socket to receive first byte. */
rs = sl_Recv(sd, gp_buff, 1, 0);

Our problem is happening when we get an error from the socket. Sometimes sl_Recv returns 0 even though we block the socket for receiving 1 byte. In that case, we have to close the socket by calling sl_Close and open it back again. However, this causes multiple sessions on the server side. One of our customers has warned us about the issue because these multiple sessions are causing unnecessary rise of RAM usage on their machines.

Why do you think that the socket is not closed properly? Can we somehow make sure that our device closes the socket successfully?

Thank you for your help.

Best,

Ogulcan

  • sl_Recv return with 0 when the remote side closed the connection (i.e. sent TCP-FIN which means he stopped its TX).

    You will need to close the socket in response to terminate the connection (calling sl_Close will tell the CC32xx to send its TCP-FIN and enable the remote side to release the socket resources).

  • Hi Kobi,

    Thank you for the information. However, this is exactly how we are handling the communication right now. Even though we are calling sl_Close, the session is open on the server side.

    Can you think of some other solution that we can test?

    Thanks.

    Ogulcan

  • Also what about sl_Stop after sl_Close? Do you think that it is necessary to end the session or not?

    Thanks.

    Ogulcan

  • Hi Ogulcan,

    Just a quick comment.

    From your description it looks like misbehaviours at server side. It looks that server not properly handle closed sockets. For deeper understanding please provide log from network sniffer - e.g. packet log from Wireshark. Maybe you can try to use socket option LINGER before closing socket.

    It is not mandatory to call sl_Stop() after sl_Close(). Calling sl_Stop() instantly after sl_Close() can cause issue with closing socket, especially when sl_Stop() with short or without timout is used.

    Jan

  • Hi Jan,

    Thank you very much for your comment.

    I will try to get log data from Wireshark and debug this issue together with the customer. I will also try to use the socket option LINGER before closing the socket.

    How long would you recommend to wait after sl_Close to call sl_Stop?  Because we do have cases where we stop the communication with the server and stop Simplelink to go hibernate.

    Thanks.

    Ogulcan

  • Hi Ogulcan,

    It is hard to recommended time between closing socket and disabling NWP. Because this depends on local conditions (latency to your server). It is always trade-off. If you instantly disable NWP after calling sl_Close() it may to not be socket properly closed at server side. If you wait longer, you will waste of energy. Usage of LINGER option is a reasonable way. But you need to properly  tweak timeouts.

    If your application is sensitive to power consumption, it may to be reasonable approach use short timeouts. And to have properly implemented releasing of resources (for not properly closed sockets) at server side. I suppose that at server side is much more powerful hardware than Cortex-M4 inside CC3235 :)

    Jan

  • Hi Jan,

    Thank you very much for the detailed explanation. We will test LINGER option and different timeout values to find the best solution.

    One more question about the timeout value though. Let's imagine that we have given a long timeout for sl_Stop such as 5000 milliseconds. How does sl_Stop behave in that case? Does it return as soon as the socket is closed or does it wait full 5000 milliseconds and then return?

    Yes, indeed the hardware on the server side must be much more powerful than CC3235 :)

    Best,

    Ogulcan

  • Hi Ogulcan,

    Unfortunately I am not sure what is exact behaviour of sl_Stop() in the conjunction with TCP socket closing packet exchange. Timeout for NWP stop works generally by that way NWP hibernate as soon is possible - that means all necessary "cleaning" is done (e.g. closing Flash write is done, etc.). Power off time cannot exceed timeout. But I am not sure if closing socket is taken into account. You can test this by yourself or you can wait for answer from TI.

    Jan

  • Hi Kobi,

    Can you confirm the behaviour of the function sl_Stop according to my previous question? Does the function return as soon as all the necessary tasks are finalized by the NWP or does it wait until the end of given timeout value no matter what?

    Thanks.

    Ogulcan

  • sl_Close will return as soon as the socket is closed. The timeout will be used only in the worse case (e.g. when connection is not closed gracefully).

  • Thank you very much for the help.

    Best,

    Ogulcan