heinbali01 wrote on Tuesday, May 10, 2016:
Great to see a TCP/IP stack which is tightly coupled with an RTOS.
FreeRTOS+TCP is indeed built on FreeRTOS and it uses many of its features, notably the event groups and queues.
The status of the project: FreeRTOS+TCP has been ported to many platforms and it has been tested by many people. Today you will still find it in the freertos/labs section, but it is about to be moved to the standard FreeRTOS release.
The labs release will then be upgraded to include multiple interfaces and IPv6.
- Multiple interfaces (eg 2 MACs)
As said it is in preparation, it is being tested right now! Pretty soon FreeRTOS+TCP will support multiple interfaces and multiple end-points. So you can also bind several different IP-addresses to a single interface.
The basics of IPv6 will be implemented so you can find devices (Neighbor Discovery and Name Service protocols), and use UDP and TCP on top of IPv6.
- Packet fragment reassembly
Not at the IPv4 level if that is what you mean. FreeRTOS+TCP stopped supporting fragmentation because it is rarely used now.
The only useful case would be an IPv4 UDP server that sends fragmented packets which are larger than the MTU (which is not my favourite solution).
Another reason to use fragmentation used to be: a lack of RAM. But if your device has a very small amount of RAM, you can also decide to use a smaller MTU (smaller packets) and thus use smaller RAM buffers.
The TCP protocol doesn’t need fragmentation, it reassembles all packets at the end-point.
TCP was heavily tested through the internet: an MCU was serving interactive (Java Script) web-pages through an unreliable and low band-width ISP. We recorded all TCP data with Wireshark and analysed the conversations.
- Delayed acknowledgement and Retransmission
That is for TCP: yes it does both
There is a small problem with “Delayed acknowledgement” and embedded applications: some devices have very little RAM and use a sliding window of 1 MMS, e.g.
WIN=1460. Normally an OS will delay it’s ACK to a single packet for 200 ms. These connections will therefore never get faster than 5 x 1460 bytes per second.
FreeRTOS+TCP decided to make this delay considerably shorter than 200 ms, in order to increase the speed of TCP connections with low-RAM devices.
It has congestion control but it does not implement all recommendations that have been published in RFC’s. We had to make a choice between small code and smart behaviour.
Selectable, by default it has sliding TCP windows ( ipconfigUSE_TCP_WIN = 1 )
As embedded devices often have small amounts of RAM, you can determine exactly how much RAM will be dedicated to network buffers and TCP-buffers, see FREERTOS_SO_WIN_PROPERTIES.
Every TCP socket has its own stream buffers. The socket advertises a
WIN size to the other party, the stream buffer guarantees that space will be available to receive
The stream buffers are implemented as circular buffers (with
tail pointers): bytes can be added or retrieved within any locking mechanism.
- Round-trip time estimation
Yes it does, both for Sliding TCP Windows as well as non-sliding version. Time-outs will be doubled after a missing ACK. The “fast retransmission” mechanism is also implemented.
Yes it does. You can either poll how many bytes can be written to a TCP socket ( TX space ), or you can call FreeRTOS_send() in a blocking way and test how many have actually been sent.
- Are there any plans to support WiFi and 3G/4G modems as well?
I am using WiFi and a 4G modem indirectly: my laptop serves as a gateway for my embedded devices which are on a LAN.
3G/4G Modems are normally part of a router which often has LAN connections and/or WiFi.
It shouldn’t be too difficult to write a driver for WiFi (access point or station).
Two questions that you didn’t ask:
There is a time between receiving a SYN and a successful call to
FreeRTOS_accept(). The SYN will lead to the creation of a socket which is owned by the IP-task. Because nobody can close the socket, the IP-task will set a timer to give these anonymous sockets a maximum life time:
/* Include support for TCP hang protection. All sockets in a connecting or
disconnecting stage will time-out after a period of non-activity. */
#define ipconfigTCP_HANG_PROTECTION ( 1 )
#define ipconfigTCP_HANG_PROTECTION_TIME ( 30 )
The socket will be closed automatically if it doesn’t reach the connected state with N seconds. Once it gets connected, it wait for the application to call
As long as a TCP connection is idle, you can not be sure if the path (from end-point to end-point) is still valid. Maybe a NAT-router has been reset and the connection has in fact gone. Maybe you are waiting for an important TCP message which never comes, and you think that no news is good news
When keep-alive messages are enabled, the path will be tested from time to time:
/* Include support for TCP keep-alive messages. */
#define ipconfigTCP_KEEP_ALIVE ( 1 )
#define ipconfigTCP_KEEP_ALIVE_INTERVAL ( 20 ) /* in seconds */
Not every router will recognise or cooperate with keep-alive messages. If you write the source-code for both client and server, it is better to include AYA (Are You Alive) messages in the protocol.