Re: [lwip-users] FreeRTOS/lwIP Win32 simulator project now hosted

[FreeRTOS Info]

The FreeRTOS project has now been updated to include a sockets API based
example, in addition to the already existing raw API based example.

The sockets example implements a Telnet "style" interface that can be
connected to using either a telnet client (only tested from Windows) or
dumb terminal type TCP/IP interface (connecting on port 23).

The code and a little set up explanation can be found here:

http://interactive.freertos.org/entries/20290712-freertos-win32-project-with-lwip-web-server

As the command interpreter is not re-entrant, the implementation only
allows a single connection at a time.


One quick question, and one longer question:

1) As this is to be used (by me at least) as a reference, I would like
to ensure it is set up optimally.  When implementing a telnet style
server (i.e. sending and receiving very small packets), using a sockets
API, how/should I configure the socket for optimal performance?  Is
there a way to do that?

2) This relates to the SSI functionality.  I want to minimise RAM usage
for when this code is running on real microcontroller targets.  The SSI
functions I have implemented return a very large string, so I have set
LWIP_HTTPD_MAX_TAG_INSERT_LEN 1024.  At the time, I didn't realise this
resulted in 1024 bytes being allocated for each http connection, whether
it was using SSI or not.  Ideally I would like to use a single, global
buffer.  Is that possible (obviously I would need to change the lwIP
code a little in my local copy).

To elaborate a little on this second question.  The command interpreter
just implemented for the sockets example returns the same amount of data
as the SSI functions (in fact, they call the same functions).  In the
command interpreter I have allocated one large buffer that uses a mutex
to ensure only one command uses the buffer at a time.  This is ok, as
the sockets based server runs in its own task, and can block on the
mutex.  Ideally, I would like the SSI functions to use the exact same
buffer - but as the http server uses the raw API I don't think it can
block without blocking the entire stack.  Is there a solution to this?


Regards,
Richard.

+ http://www.FreeRTOS.org
Designed for Microcontrollers.
More than 7000 downloads per month.




On 26/07/2011 07:20, Paul Archer wrote:
> Hi Richard,
> 
>> Done - although I think it should be SYS_STATS_INC_USED( mbox ) /*
>> without the .used on the mbox. */
> You are corerct, it should have been just SYS_STATS_INC_USED( mbox )
> 
>> I could not see that there was a SYS_STATS_DEC_USED equivalent.
> Also correct, just use the SYS_STATS_DEC as you have.
> 
>> I have attached my current file.  It has also been bent into the
>> FreeRTOS coding style since I posed it up, as it is FreeRTOS specific file.
> This file looks good. And does all that it needs to.
> 
> The only comment I have is due to my requirement for DNS lookups.
> In my sys_arch.c file I needed to add a way to track tasks. This is due
> to performing DNS lookups without needing to lock for each task.
> 
> There is a function
> struct hostent *sys_thread_hostent(struct hostent *hostent)
> 
> My function that I have is
> /**
>  * Get the thread's hostent structure
>  *
>  * \param[in] hostent Copy the data from this into the threads hostent
>  *
>  * \return The threads hostent with the data copied from the argument
>  */
> struct hostent *
> sys_thread_hostent(struct hostent *hostent)
> {
>     sys_tcb_t *current;
> 
>     syslog(LOG_DEBUG, "Got here: '%s'", inet_ntoa(hostent->h_addr));
> 
>     /* Find the current thread */
>     if ((current = sys_arch_thread_current()) == NULL)
>     {
>         return NULL;
>     }
> 
>     /* Check if we need to allocate the memory */
>     if (current->hostent == NULL)
>     {
>         current->hostent = pvPortMalloc(sizeof(*current->hostent));
>         if (current->hostent == NULL)
>         {
>             return NULL;
>         }
>     }
> 
>     /* Copy the data into the return result */
>     memcpy(current->hostent, hostent, sizeof(*hostent));
> 
>     return current->hostent;
> }
> 
> What is needed here is a way to get a per tasks hostent structure.
> The way that I did this is sub-par, and is just an linked list of task
> handles, which is searched when needed.
> It works, but its not particularly quick or memory efficient.
> 
> If you can find a better solution and include that in the sys_arch
> example I am sure that many people would like
> thread safe DNS resolving out of the box.
> 
>> To demonstrate sockets use, the current plan is to add in a simple
>> telnet "like" console (just single connection to keep it really simple),
>> and command interpreter (to return the same information that is already
>> being returned by the web server).  Then it will just be a case of
>> adding in a sockets client side demo.
> I think this is a perfect example and is exactly what most people would want.
>