lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Normal way how highlevel API interfaces with stack ?!


From: Bonny Gijzen
Subject: Re: [lwip-users] Normal way how highlevel API interfaces with stack ?!
Date: Wed, 1 Dec 2004 15:43:09 +0100

----- Original Message -----
From: "K.J. Mansley" <address@hidden>
Subject: Re: [lwip-users] Normal way how highlevel API interfaces with stack
?!

> Normally the sockets API will return to the application (with no error -
> i.e. success) before the data have even been transmitted once.  Usually
> the send() function returns when it has successfully put something on a
> queue of things to be sent.  It does not wait until the data are
> actually transmitted, and certainly doesn't wait until the data have
> been acknowledged, before it returns.

OK, this I understand. Its the non-blocking way sort of I think.

Normally, when I use nonblocking sockets I simply send some data and wait
for an answer (highlevel). When the answer doesn't reach me in the specified
timeout, I raise an error and possible try to send the data again (and also
wait for a response ofcourse).

Assume I dont try to resend the data but simply continue .. then at some
later time
I again need to send some data and wait for a response.
But in the meantime the previous data is (or can be) still inside lwIP and
being retransmitted until MAXRETRY. This means that the data I will receive
from that time on, can be an answer to the old frame still inside lwIP or an
answer to my newly sent frame. From my highlevel app point of view I cannot
tell the difference.

Ofcourse I can think of mechanisms in where my highlevel code informs lwIP
to stop doing something, but I guess all stacks suffer this problem. So how
is this normally handled inside stacks?

Rgs Bonny,





reply via email to

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