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.
Regards,
Mark
On Sun, Aug 3, 2014 at 12:25 AM, M. Manca <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>
> <mark.l...@gmail.com> wrote:
>
> Well, shame on me!
>
> I was actually
> usinghttp://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>
> <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
> listlwip-users@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
> _______________________________________________
> lwip-users mailing
> listlwip-users@nongnu.orghttps://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
>
>
>
>
> [image: logo]
>
>
> * Massimo Manca**, Micron Engineering*
> via della Ferriera, 48 33170 Pordenone PN ITALIA
> Tel: 39 0434 1856131 | Mobile: 39 349 4504979
> www.micronengineering.it
> [image: Twitter]
> <http://s.wisestamp.com/links?url=https%3A%2F%2Ftwitter.com%2Fmassimomanca>
> [image:
> LinkedIn]
> <http://s.wisestamp.com/links?url=http%3A%2F%2Fit.linkedin.com%2Fpub%2Fmassimo-manca%2F7%2Fa15%2F479%2F>
> [image:
> SlideShare]
> <http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2Fmicronpn>
> Contact me: [image: 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
> https://lists.nongnu.org/mailman/listinfo/lwip-users
>
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
