|
From: | Albert Bartel |
Subject: | Re: [lwip-devel] communication hangs after single ACK |
Date: | Fri, 20 Nov 2009 13:40:33 +0100 |
> I can see there is something not quite right here, but not sure the > suggested change will fix it. How can you be sure that conn->socket is > valid the second time you call it?
Because it is tested in (2)
and we return in every case, if it is not valid. s = conn->socket; (1) if (s < 0) { /* Data comes in right away
after an accept, even though * the server task
might not have created a new socket yet. * Just count down (or
up) if that's the case and we * will use the data
later. Note that only receive events * can happen before
the new socket is set up. */ sys_sem_wait(socksem); (2) if (conn->socket < 0) { if (evt == NETCONN_EVT_RCVPLUS) { conn->socket--; } sys_sem_signal(socksem); return; } // set s to conn->socket
because now conn->socket s valid // and s (old conn->socket)
is invalid (3) s = conn->socket; sys_sem_signal(socksem); } sock = get_socket(s); if (!sock) { return; } In our case it was
frequently that the first check (1) failed because s (conn->socket) was -1. So we get into the first if
(1). There we wait for the semaphore to be signalled and after that there is a
second check (2). If this check fails, we get into the next if (2) and there we
return in every case. Otherwise, if the second
check (2) succeeds, we signal the semaphore and call sock = get_socket(s), but
s is still -1. So get_socket(s) fails, we return and the socket is not signalled,
that there was data received. If we get into the second if
(2), the conn->socket is still invalid and the return is correct, of course.
But if we don’t get into the second if (2), the conn->socket is valid,
isn’t it? And because s is used later
on, we have got to set s to the now valid
In our case, when we got into (1) but not into (2) we never receive a signal that data was received, so lwip_selscan in lwip_select never returns > 0 because ->rcvevent is not incremented. And because the received data was the HTTTP GET, no more data follows, the data is not processed and we get no answer until the connection is closed manually (then the FIN,ACK increments the ->rcvevent and we get the data after the connection closed).
So in our case it works, every connection is processed correctly. That’s why I think, that (3) is correct and should be inserted.
Albert |
[Prev in Thread] | Current Thread | [Next in Thread] |