• Resolved

CC3100 TCP Client Recieve

Is there an interrupt or a flag when the CC3100 receives data from a server. Basicly I am talking to a server but there may be messages sent from the server periodically and I was wondering what the best way to catch these messages would be. I have looked at some examples but they all seem to have a very exact communication sequence so they have no need to look for a flag, interrupt or use a callback. Any help would be great.

Thanks

Kas

  • Hi Kas,

    When you say "server", what are you referring to? A TCP server, the internal web server, or just any server on a network sending TCP packets?

    If it is just receiving packets from a server on the network, then you set up a socket by binding to a ip:port and then use sl_select to monitor for activity, then you would receive the packet using sl_Recv or sl_RecvFrom and then you would examine the packet (usually the packet header) to make sure it is a packet you are wanting to receive (i.e. it is the right protocol). Then you process this how every you wish. Many examples show how to do most of this.

    There are also a number of callbacks and event handlers, including: SimpleLinkWlanEventHandler, SimpleLinkNetAppEventHandler, SimpleLinkHttpServerCallback, SimpleLinkGeneralEventHandler, SimpleLinkSockEventHandler - Most examples have these included.

    Glenn.

    Code Examples, Libraries and Solutions for IoT Projects

  • In reply to Glenn Vassallo:

    Hello Glenn, 

     

    When I refer to a server I am talking specifically about Plot.ly, I am using them to plot streaming data. The issue that I am now working with is that the connection drops after a number of data points have been sent, plotly sends back an error message if something goes wrong on their end. It is this error message that I would like to try and catch to see if the disconnection is originating from them or somewhere else along the connection route.

     

    I would prefer to not poll for this message sent from plotly so if there is a call back that I can use to set a flag or preferably a built in flag that I can check to see if data is waiting to be serviced that would be much better.

     

    Thanks

    Kas

  • In reply to Kas Lewis:

    If this message is just a TCP packet sent on a particular port....then use the message I outlined above. 

    Glenn.

    Code Examples, Libraries and Solutions for IoT Projects

  • In reply to Glenn Vassallo:

    Hello Glenn, 

    If my understanding is correct sl_select() is used in a polling fashion that is it is called and waited for, is this correct ? Are there any examples of its use.

    Thanks 

    Kas

  • In reply to Kas Lewis:

    Hi Kas,

    It is listening to a particular port rather than polling. The sockets api and methodology used is BSD sockets, this is the standard for network communication - http://en.wikipedia.org/wiki/Berkeley_sockets

    The tcp_socket example is the one you need to look into.

    Glenn.

    p.s. BSD Standard does have a poll function defined, but this is not included in the SimpleLink implementation.

    Code Examples, Libraries and Solutions for IoT Projects

  • In reply to Glenn Vassallo:

    Hello Glenn, 

    I am now very confused. The tcp_socket, in CLIENT mode does not receive any thing, for this it the example opens a server. I do not see any use of sl_select in that example. Could you please be a little more elaborate in your explanation on how I would listen for incoming packets in client mode.

    Kas

  • In reply to Kas Lewis:

    Hi Kas,

    I know it can be a little bit confusing at first. May I suggest you review the documentation available in the SDK. Also you can get an intro from the Berkley sockets link I provided above, or search on the Internet for Berkley or BSD sockets.

    Glenn.

    Code Examples, Libraries and Solutions for IoT Projects

  • In reply to Glenn Vassallo:

    Hello Glenn, 

    Are there any examples of a client listening for packets coming from a server at a possibly unexpected time or at least examples of how a client would use select(). I have read the link you provided as well as TI's API neither of which explain much about the select() function or how to use it.

     

    Kas

  • In reply to Kas Lewis:

    Hi Kas,

    In the TCP Socket example's BsdTcpServer function look for accept() instead of select(). I am mainly working with UDP and select() is used in this instance, however it looks like listen() and accept() are the preferred method when working with TCP.

    Also I should have probably paid more attention to your post's title "CC3100 TCP Client Receive". Just in case there is confusion, I want to make it clear that a client initiates communication with a server. Hence in your case, your server will be the "tcp client" and the CC3100 device will be the "tcp server". Once you set up your CC3100 device as a TCP server, it will be waiting/listening for packets, that could come at anytime. 

    Thanks for getting me to look into this a little more...I learnt something new.

    Glenn,

    Code Examples, Libraries and Solutions for IoT Projects

  • In reply to Kas Lewis:

    Hi Kas,

    The SimpleLink API is BSD adherence.

    I'm not familiar with plot.ly but as much as I understand you are opening a TCP client and connect it to their server as HTTP client.

    On a TCP client you have two major methods for receive: blocking / non-blocking.

    In both methods the data is kept in the device until you call the sl_Recv function to read the data and there is no asynchronous event to indicate that there is data waiting on the socket.

    By default a socket is opened in blocking mode and you can change that using sl_SetSockOpt.

    The select API (sl_Select) is generally used to wait for different events from several sockets on a single context.

    Depends on your application's design and the platform it is running on (OS/Non-OS for example) you can choose to use sl_Recv / sl_Select + sl_Recv to read data from a socket.

    According to plot.ly a disconnection from their server could happen most probably if the device doesn't send anything for more than 60 seconds or a new TCP client has connected using the same token.

    If you detect the disconnection by getting error after calling sl_Send you can simply try to call sl_Recv to read the received data from the socket at that point.

    If the data (HTTP error) exists, you will get it, otherwise you will get error since the socket was closed by the server. You should read all data by calling sl_Recv until you get error in order to validate that you get the last response.

    Barak