Il 03/08/2014 14:21, Mark Lvov ha
scritto:
This is exactly what I've done, only I have a
class, each instance of which manages a connection to a
particular endpoint (only, my "state" enum has ACTIVE_CLOSE and
PASSIVE_CLOSE instead of CLOSING, since those are handled
differently). The thing is, it does not really help much with
the problem I've outlined in the earlier message. Even though I
get the pointer to a particular instance of the class in the
"arg" argument to the err callback, it is still impossible to
know if it is the latest connection, that errored out, or if it
is some other, older connection, that was also opened to the
same endpoint, but was stuck in some "waiting" state, such as
LAST_ACK. I hope, this makes sense.
Yap, it makes sense but you should manage a little bit better your
connection. You can't open a connection that is not close so... this
event shouldn't be managed, in any case there are some timers in
lwip to manage the timeouts, you should check in that area.
|
Questa e-mail è priva di virus e
malware perché è attiva la protezione avast!
Antivirus .
|
_______________________________________________
lwip-users mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/lwip-users
|
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus .
|
|