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.
>
> Regards,
> Mark
>
>
> On Sun, Aug 3, 2014 at 12:25 AM, M. Manca
> <m.ma...@micronengineering.it <mailto:m.ma...@micronengineering.it>>
> wrote:
>
>     Il 02/08/2014 20:52, Mark Lvov ha scritto:
>>     Hello,
>>
>>     It seems, I still have some unanswered questions with regard to
>>     correct connection teardown. Let's consider the active close situation
>>     (we are closing the connection). We've just called tcp_closed and are
>>     waiting for the tcp_recv callback to be called with an empty pbuf.
>>     But, as I understand, if the remote side sends RST or does not send
>>     anything at all, the err handler will be called instead. The problem
>>     is, one does now know which particular connection (pcb) the callback
>>     is addressed to, because the callback function does not receive a pcb
>>     as an argument.
>     This is one of the reason I wrote an "upper layer" to the raw
>     functions to manage a tcp client connection.
>     The idea is simple: create a struct to embed every information
>     needed to manage a particular connection so I can pass it as the
>     void *arg
>     that is also present in the error callback.
>     I think you can understand my idea just reading the struct I made:
>
>     typedef enum
>     {
>       STATE_NOT_CONNECTED = 0,
>       STATE_CONNECTING,
>       STATE_CONNECTED,
>       STATE_CLOSING,
>     } TTcpRawSktState_e;
>
>     typedef struct
>     {
>        TTcpRawSktState_e eState;
>        err_t eError;
>        struct pbuf *pPbuf;
>        struct tcp_pcb *pPcb;
>        struct ip_addr tServerIpAddr;
>        uint16_t wServerPort;
>        uint16_t wBindPort;
>        char szDescription[8];
>     } TTcpRawSkt;
>
>     the description field isn't necessary, I used it to debug in the
>     simplest way my code.
>>     Consider the scenario, when one needs to keep a connection open by
>>     reconnecting to the remote side whenever the connection is closed
>>     (either by the remote or the local side). It is all fine when the
>>     remote side closes the connection - we just receive a NULL pbuf, after
>>     that we can just call tcp_close on the "current" pcb, then immediately
>>     ask for the new pcb and reconnect. If, on the other hand, *we* want to
>>     close the connection (to reopen if afterwards), and call tcp_close, we
>>     might have the err callback called and then we won't really know if it
>>     means, that the current connection was terminated or some older
>>     connection, that maybe stuck in LAST_ACK finally timed out.
>>
>>     Does this mean, that in such a situation, one has to keep only one err
>>     callback active at a time? It seems, the best course of action is to
>>     zero out the err callback on a pcb after calling on it tcp_close
>>     successfully (actually, its more like this: zero out the callback,
>>     then call tcp_close and if it fails reattach the callback, because we
>>     will have to wait a bit before calling tcp_close again). But then,
>>     once we call tcp_close, we have to start a timer (for, say, 5
>>     seconds?) and if it runs out we consider the connection closed, remove
>>     all callbacks from that pcb and ask for the new one.
>>
>>     Hopefully, I've managed to explain the problem I am facing. Sorry,
>>     that it took such a long message.
>>
>>     Thanks,
>>     Mark
>>
>>     On Fri, Aug 1, 2014 at 9:01 AM, Mark Lvov <mark.l...@gmail.com> 
>> <mailto:mark.l...@gmail.com> wrote:
>>>     Well, shame on me!
>>>
>>>     I was actually using
>>>     
>>> http://git.savannah.gnu.org/cgit/lwip.git/tree/doc/rawapi.txt?id=5b8b5d459e7dd890724515bbfad86c705234f9ec
>>>     as a reference and it obviously lacks the details, that are present on
>>>     the page you've linked. All my questions are answered by that page,
>>>     thanks very much.
>>>
>>>     Mark
>>>
>>>     On Thu, Jul 31, 2014 at 10:01 PM, Sergio R. Caprile 
>>> <scapr...@gmail.com> <mailto:scapr...@gmail.com> wrote:
>>>>     Counter-proposal:
>>>>     Read the wiki, and if it is not clear enough, I will change it
>>>>
>>>>     http://lwip.wikia.com/wiki/Raw/TCP
>>>>
>>>>     Regards
>>>>
>>>>     --
>>>>
>>>>
>>>>     _______________________________________________
>>>>     lwip-users mailing list
>>>>     lwip-users@nongnu.org <mailto:lwip-users@nongnu.org>
>>>>     https://lists.nongnu.org/mailman/listinfo/lwip-users
>>     _______________________________________________ lwip-users
>>     mailing list lwip-users@nongnu.org <mailto:lwip-users@nongnu.org>
>>     https://lists.nongnu.org/mailman/listinfo/lwip-users
>>
>>
>>     ---
>>     Questa e-mail è priva di virus e malware perché è attiva la protezione 
>> avast! Antivirus.
>>     http://www.avast.com
>>
>>
>
>
>
>     logo 
>       *
>
>     Massimo Manca*/, Micron Engineering/
>     via della Ferriera, 48 33170 Pordenone PN ITALIA
>     Tel: 39 0434 1856131| Mobile: 39 349 4504979
>     www.micronengineering.it <http://www.micronengineering.it>
>
>     Twitter
>     
> <http://s.wisestamp.com/links?url=https%3A%2F%2Ftwitter.com%2Fmassimomanca>
>     LinkedIn
>     
> <http://s.wisestamp.com/links?url=http%3A%2F%2Fit.linkedin.com%2Fpub%2Fmassimo-manca%2F7%2Fa15%2F479%2F>
>     SlideShare
>     
> <http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2Fmicronpn>
>     Contact me: Skype micron.engineering
>     Designed with WiseStamp -
>     
> <http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1407010845407%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>Get
>     yours
>     
> <http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1407010845407%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>
>  
>
>
>     ------------------------------------------------------------------------
>     <http://www.avast.com/>   
>
>     Questa e-mail è priva di virus e malware perché è attiva la
>     protezione avast! Antivirus <http://www.avast.com/> .
>
>
>
>     _______________________________________________
>     lwip-users mailing list
>     lwip-users@nongnu.org <mailto:lwip-users@nongnu.org>
>     https://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>
>
> ------------------------------------------------------------------------
> <http://www.avast.com/>       
>
> Questa e-mail è priva di virus e malware perché è attiva la protezione
> avast! Antivirus <http://www.avast.com/> .
>
>
>
>
> _______________________________________________
> lwip-users mailing list
> lwip-users@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/lwip-users




logo 
        *

Massimo Manca*/, Micron Engineering/
via della Ferriera, 48 33170 Pordenone PN ITALIA
Tel: 39 0434 1856131| Mobile: 39 349 4504979
www.micronengineering.it

Twitter
<http://s.wisestamp.com/links?url=https%3A%2F%2Ftwitter.com%2Fmassimomanca>
LinkedIn
<http://s.wisestamp.com/links?url=http%3A%2F%2Fit.linkedin.com%2Fpub%2Fmassimo-manca%2F7%2Fa15%2F479%2F>
SlideShare
<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2Fmicronpn>
Contact me: Skype micron.engineering
Designed with WiseStamp -
<http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1407097092353%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>Get
yours
<http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1407097092353%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>
 


---
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! 
Antivirus.
http://www.avast.com

<<attachment: m_manca.vcf>>

_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

Reply via email to