[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] How to force-close a netconn from the server side?
From: |
Freddie Chopin |
Subject: |
Re: [lwip-users] How to force-close a netconn from the server side? |
Date: |
Thu, 26 Jan 2017 14:34:04 +0100 |
On Wed, 2017-01-25 at 20:49 +0100, address@hidden wrote:
> In "specialities" like this one, the netconn API is (unfortunately)
> sometimes incomplete as the "core" and socket APIs are more widely
> used.
>
> While you don't have to "mess" with the "so_options" field, you'd
> have
> to call "ip_set_option(conn->pcb.ip, optname)", which should work
> for
> you but is still not a clean solution as accessing the "pcb" member
> of a
> netconn should not be done by client code and should not be done from
> an
> application thread (only from tcpip_thread).
Would any additions to the netconn API be accepted, or maybe the plan
is really to add a function or two to sockets to allow netconn-like
interface (with no copying) and then netconn would be deprecated?
Anyway - I've noticed something very very strange after a few more
hours of debugging and random changes (; If I force-close the client
(and listen) connections with "netconn_close()" + "netconn_delete()",
then most of the time everything works fine, only sometimes there is a
PCB (maybe more than one) stuck in TIME_WAIT state, but in this case I
just have to wait ~2 minutes and the problem is solved. This is the
first strange thing - why sometimes the PCBs stay in TIME_WAIT and
other times (like 90%) they don't. But I guess this is network-related.
The second strange thing is much more interesting. It works only if I
introduce a small delay between close+delete and opening of new listen
connections (I'm using a multithreading system). Something like this
works:
for (5 client connections and 5 listen connections)
{
netconn_close(connection[i]);
netconn_delete(connection[i]);
}
distortos::ThisThread::sleepFor(std::chrono::seconds{1});
for (5 listen connections)
{
listenNetconns[i] = netconn_new();
netconn_bind(listenNetconns[i], IP_ADDR_ANY, ports[i]);
netconn_listen(listenNetconns[i]);
clientNetconns[i] = netconn_accept(listenNetconns[i]);
}
With this code the PCBs are only sometimes stuck in TIME_WAIT state for
~2 minutes. But if I remove the "sleepFor()" call, then there is a PCB
(maybe more than one) stuck in FIN_WAIT_1 forever.
Any idea what could be the reason for this behaviour? I'm not very
comfortable with random fixes which I don't understand at all (; The
delay obviously allows main TCP/IP thread to run for a while, but what
does it change? The connections are closed and deleted anyway, so why
would lwIP behave so differently in these two cases?
Thanks in advance!
Regards,
FCh
- [lwip-users] How to force-close a netconn from the server side?, Freddie Chopin, 2017/01/25
- Re: [lwip-users] How to force-close a netconn from the server side?, address@hidden, 2017/01/25
- Re: [lwip-users] How to force-close a netconn from the server side?,
Freddie Chopin <=
- Re: [lwip-users] How to force-close a netconn from the server side?, address@hidden, 2017/01/26
- Re: [lwip-users] How to force-close a netconn from the server side?, Freddie Chopin, 2017/01/26
- Re: [lwip-users] How to force-close a netconn from the server side?, address@hidden, 2017/01/26
- Re: [lwip-users] How to force-close a netconn from the server side?, Freddie Chopin, 2017/01/26
- Re: [lwip-users] How to force-close a netconn from the server side?, address@hidden, 2017/01/26