ok, maybe it's different in our situation. For the browser had already sent
the 'ack' in fact, and it will not send it again. So it's meaningless to
make
the receiver part of web server open to wait for 'ack' from the browser.
"the upper layer", I mean relative to low_level_input, for I set breakpoint
in 'case FIN_WAIT_2" in function "tcp_process", and occasionally it will not
reache here after
the web server sends [FIN,PSH].
that means somehow the ack message is lost or ignored in the level "tcp_input"
(in low_level_input, we have count the number of received message,
and compare it to the number of message sent by the browser with the help of
wireshark, it's the same.)
Thus, the connection of webserver is still open(stay in FIN_WAIT_1 state)
while the the connection of browser is closed.
Then, bad things will happen when the webserver retransmit [FIN,PSH], and the
browser just responds [RST], resulting in all tcp connections blocked or failed.
we cannot figure out how to avoid all tcp connections breaking down when lwip
receives [RST] (our web server is inside the tcpip_thread).
we don't know what makes the connection not entering FIN_WAIT_2 state. we had
debug and trace the code, just not that easy to find out.
From: Noam weissman [via lwIP]
Date: 2016-08-07 01:41
To: lampo
Subject: Re: http server problems/bug
Hi,
Every socket has a sender part and a receiver part. Normally it is full duplex
!.
TCP has layers. Some data is handled inside the TCP stack MAC + L1 and some is
handled in L2,L3 etc...
When an ACK or some other low level message arrives it is handled inside the TCP
and never get to the upper layers.
I do not know the exact internal mechanism but what I know that when you call
tcp_close
it shuts down the sender and receiver handling inside the TCP stack for the
open connection.
It frees any internal memory and deletes the related PCB.
If you shut down the sender only using tcp shutdown function the connection is
still is open for
the receiver part. That means that is the remote side closes your tcp_recv call
back will be triggered
with data that has ZERO length. Also the TCP stack will respond (low level) to
that message by acknowledging it.
http://stackoverflow.com/questions/4160347/close-vs-shutdown-socket
BR,
Noam.
c - close vs shutdown socket? - Stack Overflow
stackoverflow.com
In C, I understood that if we close a socket, it means the socket will be
destroyed and can be re-used later. How about shutdown? The description said it
closes half ...
From: lwip-users <lwip-users-bounces+noam=[hidden email]> on behalf of lampo
<[hidden email]>
Sent: Saturday, August 6, 2016 6:37 AM
To: [hidden email]
Subject: Re: [lwip-users] http server problems/bug
> On LwIP side when you close a connection using the tcp_close it closes
> ALL.
Does that mean it closes all other connections including other independent
threads,like tcp client ,tcp server in our multithreaded system?
> From having problems in some TCP module that I wrote I found that if I
> call tcp_shutdown and only
> define shutdown the TX side the connection is closed only after getting
> the ACK.
sorry,I can't quite get it. In our example, you mean TX side is our web
server, RX side is browser from PC, right? But browser has already
got the ack from web server after it sends out FIN,and close the
connection,while in fact the TX side does not closed totally.
can you show the process in following format ,so I can get it precisely?
web server <------ GET HTTP/1.1----- web Client
web server (FIN_WAIT_1) -------- FIN,PSH-----------> web Client
web server (FIN_WAIT_2) <-------- ACK------------- web Client
(web server will stay in FIN_WAIT_2 for we find it receives no ACK here )
web server <-------- FIN-------------- web Client
web server -------- ACK-------------> web Client
(web client receives the ack, so it close the RX side connection, thus it
cannot respond to a FIN now)
--
View this message in context:
http://lwip.100.n7.nabble.com/http-server-problems-bug-tp27017p27032.html
lwip-users - http server problems/bug
lwip.100.n7.nabble.com
http server problems/bug. With more infomation provided, I re-post it here(I
post it through nabble before), sorry for that. Problem, web server <------ GET
HTTP/1.1----- ...
Sent from the lwip-users mailing list archive at Nabble.com.
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
lwip-users mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/lwip-users
If you reply to this email, your message will be added to the discussion below:
http://lwip.100.n7.nabble.com/http-server-problems-bug-tp27017p27035.html
To unsubscribe from http server problems/bug, click here.
NAML
--
View this message in context:
http://lwip.100.n7.nabble.com/http-server-problems-bug-tp27017p27037.html
Sent from the lwip-users mailing list archive at Nabble.com.
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
