First of all, I might be completely misunderstanding what is needed here as I am new to TCP/IP, so forgive me if I have the wrong end of the networking stick. I have successfully got the SAM4E demo with the FreeRTOS TCP/IP stack that was originally for Atmel Studio going on Crossworks and spent the week playing around with HTTP. I have data going to and from my desktop Apache server (using GET and POST) which is a great start. It’s reasonably easy to follow and the examples are very helpful indeed. One thing I am unclear about is that, if I understand correctly, when a GET command is sent to the server, the server sends a load of packets back and when it has finished sending the information, it sends a FIN, ACK packet. Wireshark shows this, indeed, is exactly what happens. However, I can see no way of getting access to the TCP flags that indicate this. As far as I understand, and indeed can see looking at what is passed to the thread using FreeRTOS_recv(). you just get the data in the TCP packet, not the header too. If I am understanding it correctly, I would need the header and to look at the [TCP] flags to see whether FIN and ACK were both set to know the transmission was complete. There does seem to be a flags you pass TO the FreeRTOS_recv() function. I was wondering whether that was going to be a pointer to a value when it was implemented and eventually they would be passed back? So:

1. Am I completely misunderstanding how this should work?
2. If not, how do I get access to the TCP flags?
3. Is this completely the wrong forum to ask this and should be on a TCP/IP forum somewhere completely different?!

Many thanks 🙂 Rob

The TCP flags are used by the low level TCP protocol to ensure the application is presented with a reliable and correct stream of data. So the application does not need to see the flags at all, it just sees the data. The API provides a way of connecting and closing sockets and sending and receiving data. The implementation of the API will use the flags internally, there is no visibility to the application. Can you give an example of what you are doing that needs visibility to the internal implementation?

I’m not necessarily saying I do need access, it was an assumption. As I said above, this is me getting started programming with TCP/IP in general, let alone with FreeRTOS, so I am far from sure I’m doing things correctly. I am trying to ascertain how you know when a server has finished sending all the packets necessary in response to a GET command from the client (in the case a FreeRTOS device). So: FreeRTOS -> Server HTTP GET Request for config.txt Server -> FreeRTOS HTTP Packet 1 Server-> FreeRTOS HTTP Packet2 Packet 2 has the FIN, ACK flags set, so how does my HTTP thread know that second packet is the end of the config.txt file? Or, indeed, any other file that it will be requesting? I fully realise this might be an HTTP question, rather than FreeRTOS TCP/IP issue, but I don’t know for sure and was checking here first. Thanks!

Ah, it’s OK, I’m being stupid. It’s exactly the same as the outgoing request to the server in that the first packet tells you the content length. You must have to parse the first block and get the information and then compare the message length against how many bytes have come in. Sorry for the dumb question. Sometimes you just become blind to things from staring at numbers and text. An overnight break often helps!

Hi Rob, You did a good job in short time! Or maybe it proves that +TCP is not too difficult to adopt 🙂

Packet 2 has the FIN, ACK flags set, so how does my HTTP thread know that second packet is the end of the config.txt file? Or, indeed, any other file that it will be requesting?

You can inspect the contents and know how many bytes are expected:

Content-Type: multipart/form-data; uploadData.boundary=---------------------------114782935826962
Content-Length: 2241

-----------------------------114782935826962

Or without the special token:

Content-Length: 2092
Keep-Alive: timeout=5
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8

This is the contents consisting of 2092 bytes...

At the lower level it is also possible: keep on reading from the socket until you see an error:

xResult = FreeRTOS_recv( xSocket, pcBuf, sizeof pcBuf, cFlags = 0 );
if( ( xResult < 0 ) && (xResult != -FREERTOS_ERRNO_EAGAIN ) )
{
    /* The peer has gone, socket may be closed */
}

Where EAGAIN is not an error. Normally you will see ENOTCONN, or ENOMEM in case a pvPortMalloc() has failed. The TCP protocol is robust, the sender (Apache server) will not allow the connection to be closed until every byte has been confirmed. +TCP guarantees that recv() will return a value >= 0, until the last byte has been read from the RX buffer. The flags you pass to recv() : At this moment the value of ‘flags’ is ignored and it should be passed as zero. There are values (MSGDONTWAIT, MSGPEEK) that could be handy in some situations (and can be added soon). In case of UDP, the value of flags is meaningfull: with FREERTOSZEROCOPY, frames can be sent in a way that memcpy() isn’t called. As Dave wrote: the TCP status is nothing to worry about, you only see streams of data. For debugging however, see FreeRTOS_socket.h:

/* returns pdTRUE if TCP socket is connected */
BaseType_t FreeRTOS_issocketconnected( xSocket_t xSocket );
/* for internal use only: return the connection status */
/* See 'enum eTCP_STATE' in FreeRTOS_TCP_IP.h for the meaning of the
values. */
BaseType_t FreeRTOS_connstatus( xSocket_t xSocket );

Regards, Hein

Hi Hein :~) I’m parsing the header at the moment to pull out relevant information. The TCP/IP side of this was very easy to get going. It took me around a day to get the Atmel Studio version going on Crossworks and pulling info from the server. The harder part has been getting to grips with HTTP itself. POST proved harder, I completely misunderstood how that worked which ate up a couple of days. So, yes, I’d say +TCP is very easy to use. For someone who, a week ago, had no experience of working with Berkeley sockets, it’s been very straightforward. It’s more a case of learning the protocols that sit on top! UDP will come for me before too long too… Cheers, Rob