Re: [lwip-users] netconn - using in different tasks

[Kieran Mansley]

On Wed, 2009-05-13 at 11:25 +0200, ncoage wrote:
> > > I thought about that solution, but my application is more complex.
> > > There are three tasks, each of them communicates with his own serial
> > > port. When new data come from TCP, I check specific flag, which
> > > determines wich task (serial port) must get rest of the data frame. 
> > 
> > Where do you get this flag from?
> 
> From TCP data, in callback_function I receive netbuf, so I can see all
> data. The value of particular byte determines where the rest of the
> TCP data must go.

In that case I would just keep a list of connections and which task they
should go to, so you don't have to look at the TCP data, and can route
the connection in the case where there is no data.  This assumes that a
single connection always routes data to the same thread, but I'd hope
that is the case.

It sounds like at the moment you are reading from the connection in two
different threads (once to get the flag, once to get the rest of the
data).  This is not supported unless you are protecting the connection
with locks.  You could end up with the two tasks trying to read
simultaneously.

The other thing that worries me about the way you have structured things
is what happens if the chunk of data delivered to the callback does not
have the flags byte in it.  It sounds like you might be assuming that
TCP will not split the data stream arbitrarily, but it can do this
however it likes.  i.e. It could deliver the data in two chunks: one
containing the flag and some of the data, and one containing the rest.
How do you protect against this?

The most reliable way to implement what you describe would be for the
callback connection to read all the data, reassemble and buffer it as
necessary until it has assembled an entire application-level unit, then
put the data (rather than the connection) on a queue and send them to
the other task.  The other task would then not need to use lwIP at all,
and all the lwIP access would be done from one task (in the callback).

Kieran