[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Writing a proxy server - how "non-reentrant" is lwip ra

From: wurzel
Subject: Re: [lwip-users] Writing a proxy server - how "non-reentrant" is lwip raw API?
Date: Mon, 20 Jun 2011 17:40:53 -0700

Leon Woestenberg wrote:
> On Wed, Jun 15, 2011 at 2:13 AM, wurzel <address@hidden> wrote:
>> My question is, can I call tcp_write from within a tcp_recv
>> callback?  In this code, I've opened a pair of TCP pcbs and
>> each one's state struct has a "mate" field that points to
>> the other side's state struct so I can get its pcb.
>>         snderr = tcp_write(rs->mate->mypcb, q->payload, q->len, 0);
>> By the strictest definition of "non-reentrant" this might not be
>> legal.  On the other hand, this seems like a commonly-desired case,
>> so I'm hoping it is expected to work?
> Yes, this should work. The tcp transmit code paths are cleanly
> seperated from the receive code paths through data structures. We
> should assume at the callback point the tcp state machine has those
> structures in valid state, valid enough to call into tcp_write().

A followup to this discussion; after further debugging I did find
the cause of my "flaky behavior" and it was because the call to
tcp_write above needs to have TCP_WRITE_FLAG_COPY set. 

I was optimistically hoping that since I called tcp_write and
tcp_output() from my receive callback, that the transmit side
would have what it needed by the time my receive callback exited.
However, that doesn't appear to be the case; my packets were definitely
coming out with some bytes overwritten until I added that flag.

With the flag, my app now appears to work in basic testing.

Thanks for the help and for a nicely-crafted TCP stack. 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]