[lwip-users] problem closing a stream

[trex7]

Hi,
I'm using lwip 1.3.2 in an audio stream client application. I close my
application like this:

static void httpclient_connection_close(struct tcp_pcb *tpcb, struct
httpclient * hc )
{
if (hc->pcb)
{
tcp_arg(hc->pcb, NULL);
tcp_sent(hc->pcb, NULL);
tcp_recv(hc->pcb, NULL);
tcp_poll(hc->pcb, NULL,0);
tcp_err(hc->pcb, NULL);
if( tcp_close(hc->pcb) != ERR_OK )
{
tcp_abort(hc->pcb);
}
}
if(hc)
{
mem_free(hc);
}
}

Everytime I want to close the connection and open a new one the old
connection is not close and and the old pcb state is in fin_wait_2 and stays
there. I waited for more that 5 mins but it didnt close.
I can see on wireshark that both connections are still open, as if the first
connection is still streaming.

When I call tcp_close() lwip sends fin and the servers ack it. But the
server never sends fin and continues sending data.

Are there any precautions that I need to do before closing a tcp stream
connection?

trex

--
View this message in context: http://old.nabble.com/problem-closing-a-stream-tp33517666p33517666.html
Sent from the lwip-users mailing list archive at Nabble.com.

_______________________________________________
lwip-users mailing list
lwip-...@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

[gold...@gmx.de]

trex7 wrote:
> When I call tcp_close() lwip sends fin and the servers ack it. But the
> server never sends fin and continues sending data.

TCP provides full duplex connections: the fact that you close your side
of the connection doesn't necessarily mean the server also has to close
the connection. The procedure of when which side is closed has to be
defined by the application protocol using TCP, i.e. the streaming
protocol in your case.

Simon