How to make a Web Server Demo application multithreaded?

joe0x7f wrote on Wednesday, January 13, 2016:

Hello Everyone,

I would like to know what your recommended options are for making the FreeRTOS ARM Cortex-M3 Web Server Demo application multithreaded, please?

I assume there is some way to accept() a TCP/IP cnnection on port 80 within a FreeRTOS Task and then hand the TCP/IP read/write work off to a worker thread?

Are the threads created before or after the accept()?

Does this require one FreeRTOS Task for each thread?

Is there a TCP/IP stack recommended that I use?

Switching gears, any suggestions on fork()ing versus spinning up a worker thread?
I’m not sure fork()ing is available in FreeRTOS either?
Perhaps a fork() is really creating another FreeRTOS Task on the fly?

As I remember from the FreeRTOS class, it seemed that making a FreeRTOS Task on the fly was frowned upon?

Basically, I’m not sure what options I have in FreeRTOS to make respectable, stable multithreaded or forked TCP/IP applications?



rtel wrote on Wednesday, January 13, 2016:

Are you talking about the FreeRTOS+TCP web server example here? . That (which at the moment is quite basic) and the FTP server (which is more sophisticated) currently run in the same RTOS task. So one ‘server task’ is handling all HTTP and FTP connections, which is very efficient from a RAM point of view, and not too inefficient from a run time and throughput point of view as the file system is a bottleneck anyway as all the threads want to access the same file system. You can see a little video demonstration of both running at once, along with three or four other TCP/IP and UPD/IP examples, all running simultaneously in less than 190K RAM. In fact, it would work in less RAM too.

rtel wrote on Wednesday, January 13, 2016:

Should have said the server task uses FreeRTOS_select() to manage multiple connections.

joe0x7f wrote on Wednesday, January 13, 2016:

Great! Thank you for the pointers! I will take a look.

heinbali01 wrote on Thursday, January 14, 2016:

Hi Joe,

Some more background information in addition to what Richard wrote:

It is a classical approach to have a TCP server that calls accept() and forks for every new connection (so fork() comes after a successful accept())
A child process or thread will exist as long as the TCP connection is alive.

That approach works OK in an environment with plenty of resources (lots of RAM).

In an embedded environment, we must be careful with resources. When a browser opens an interactive page, with some Java Script and asynchronous requests, it will open 6 connections to port 80.

A HTML or FTP server uses:

  1. A disk
  2. A network interface
  3. CPU time

In most cases, there is only one of each: a single disk, which is often a memory card or flash. A single network adapter (peripheral). And finally, most smaller CPU’s have a single core.
So you can ask your self: what’s the use of creating extra tasks, if all those tasks are competing to use shared resources?

The FreeRTOS_select() library function is essential: it lets the server wait for specific events on any of the sockets in a socket-set. The server sockets (for which bind(), listen(), and accept() is called) are included in this socket-set, they wait for a READ event.
Another socket has it’s transmission buffer full of data, and it will wait for a WRITE event.
Yet a third socket has sent a file and it waits for a READ event.

FreeRTOS_listen() has a parameter called “backlog”. That protects the application against getting too many concurrent connections.


joe0x7f wrote on Thursday, January 14, 2016:

Thanks, Hein! This is very helpful additional information.