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

[Simon Goldschmidt]

Sounds pretty much like the same like a TCP-to-serial converter I wrote on 
lwIP. I did it with the raw API though:
- I have a tcp_recv-callback that waits until a complete packet is received
- then that packet is parsed and sent to the right serial thread (together with 
the PCB, for responses)
- the serial thread sends the data and waits for a response
- if a response is received, it is sent through RAW API by calling 
tcpip_callback (with the correct PCB)

It works quite nice and has the advantage that I only have one thread (aside 
from the serial threads, of course) instead of 2 for the TCP management.

Simon


> On Wed, 2009-05-13 at 12:19 +0200, ncoage wrote:
> > Thank you for your reply. I need more time to analize what you wrote :).
> > But now I have a question, you wrote:
> > 
> > > 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).
> > 
> > I hope I understood you. The scenario is: I get new data from TCP, I
> > put them to (exact) queue, another task reads data and send them to
> > serial port. Now the task waits (blocks on semaphore) for reply from
> > serial port and forms a reply to tcp. If I dont have a netconn in a
> > the task, how can I send reply by TCP?
> 
> Ahh, OK, I didn't realise you needed to write data too.  In that case I
> would keep all netconn accesses in the task.  The sequence would be
> something like this:
> 
> 1) you get a netconn_callback on a connection: look up in your own list
> which task is responsible for that connection and send it a message
> (e.g. via a queue) to say this connection needs attention.  You can
> include details from the callback, e.g. what type of event it is, but
> you shouldn't need to read or write from/to the netconn in the callback
> to do any of this.
> 
> 2) the task then pulls things off this queue, and reads (or whatever)
> from its netconn, and does whatever it needs to with the data.  If len=0
> when it reads, it can close it.
> 
> 3) if the task needs to send data, it can do so directly as it won't be
> conflicting with the callback as the callback doesn't touch the netconn
> - only forwards the callback details to the appropriate task.
> 
> Kieran
> 
> 
> 
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/lwip-users

-- 
Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss 
für nur 17,95 Euro/mtl.!* 
http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a