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 <[email protected]> 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 <[email protected]>
>> 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
>>> [email protected]
>>> https://lists.nongnu.org/mailman/listinfo/lwip-users
> _______________________________________________
> lwip-users mailing list
> [email protected]
> 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
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>
---
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 [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
