Re: [lwip-users] Closing TCP connections
On Sun, Aug 03, 2014 at 16:21:07 +0400, Mark Lvov wrote:
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.
You seem to use connection here in a more abstract sense of
association between two entities that is served by an underlying TCP
connection (in the narrow sense), and that TCP connection may be
closed and reopened - as you described in an earlier email.
What you seem to be saying is that you associate an object
representing this high-level notion of connection with the tcp_pcb of
the underlying connection.
What Massimo is saying is that you need a separate object to represent
TCP connection that you can discard on error.
Either way, since TCP state machine and associated lwip callbacks are
known, you can track pcb state and know when to dissociate from it
(callbacks and arg), so you will always know your error callback
is called for the current pcb.
On Sun, Aug 3, 2014 at 12:25 AM, M. Manca 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.lvov-re5jqeeqqe8avxtiumw...@public.gmane.org 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
Re: [lwip-users] Closing TCP connections
Hi,
if you do need to detect a particular situation on tcp_err(), then you
can use the arg parameter. You are not getting the pcb because, afaik,
it no longer exists; it has been removed and freed before calling the
callback function; see tcp.c line 393 for example
The tcp_err() callback that will be called is the one you provided as a
parameter when you set the environment for that pcb. How come you don't
know what you setup ?
tcp_err(mypcb, myerr);
If you will reuse one tcp_err() function for many connections, you will
use the arg parameter, as shown in every example application:
tcp_arg(mypcb, myapplicationstructurepointer);
A closure action is something like this:
static void myclose(struct tcp_pcb* pcb)
{
state = myCLOSING;
if(tcp_close(pcb) == ERR_OK){
tcp_recv(pcb, NULL);
state = myCLOSED;
}
}
You need to have a state (or equivalent) and try to do close later if
the call to tcp_close() fails for low memory or whatever. If the other
host sends RST, you are going to close anyway.
To try later, you can use tcp_poll():
tcp_poll(mypcb, mypoll, POLL_TIME);
static err_t mypoll(void *arg, struct tcp_pcb* pcb)
{
if(state == myCLOSING){
// Retry closing the connection
myclose(pcb);
} else {
// Retry sending data we couldn't send before
mysend(pcb);
}
return ERR_OK;
}
--
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing TCP connections
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. 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 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 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 https://lists.nongnu.org/mailman/listinfo/lwip-users ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing TCP connections
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 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
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
https://lists.nongnu.org/mailman/listinfo/lwip-users
___
lwip-users mailing list
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
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_10Get
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
Re: [lwip-users] Closing TCP connections
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 https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Closing TCP connections
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 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 https://lists.nongnu.org/mailman/listinfo/lwip-users ___ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
