CODEWITHSUNDEEP
tcl
daviddem
daviddem

Reputation: 9

tcl close does not gracefully terminate tcp/ip connection

In tcl (tcl 8.4 or 8.6 on Windows), closing a socket connection does not seem to terminate the underlying TCP/IP connection gracefully.

The code below shows a simple time server and associated client. Upon connection from the client, the server sends the current time and server uptime, then closes the connection. The client also closes its side after reading the response from the server. However the underlying tcp/ip connection lingers as a zombie connection in "TIME WAIT" state for 30 seconds before it times out.

Once a few thousands of these zombie connections concurrently exist, the code ends up crashing with an "unable to connect to the server" message or the likes.

Is there a way I can prevent this and gracefully terminate the underlying tcp/ip connection?

#server
proc Server {startTime channel clientaddr clientport} {
    puts "Connection from $clientaddr registered"
    set now [clock seconds]
    puts $channel [clock format $now]
    puts $channel "[expr {$now - $startTime}] since start"
    close $channel
}
socket -server [list Server [clock seconds]] 9900
vwait forever

#client
set server "127.0.0.1"
set sockChan [socket $server 9900]
gets $sockChan line1
gets $sockChan line2
close $sockChan
puts "The time on $server is $line1"
puts "That is [lindex $line2 0]s since the server started"

Output from currport (zombie connection)
==================================================
Process Name      : Unknown
Process ID        : 0
Protocol          : TCP
Local Port        : 9900
Local Port Name   : 
Local Address     : 127.0.0.1
Remote Port       : 27524
Remote Port Name  : 
Remote Address    : 127.0.0.1
Remote Host Name  : 
State             : Time Wait

Upvotes: 1

Views: 635

Answers (1)

sebres
sebres

Reputation: 820

Well reproduced now: flood with lot of sockets in TIME_WAIT is good observable, almost for every socket (if opened and closed immediately).

Normally it does exactly the opposite, so per default after closesocket Windows executes "graceful shutdown" (in order to enable queued data to be sent), but for some reasons lindering causes such flooding with "half" closed or opened sockets for a long time, despite there is nothing to send (excepting possibly a notifying packet "socket going closed").

I investigated a bit (is quite strange) and opened a ticket in tcl-core now [b6d0d8cc2c].
I'll try to provide some solution for that.

Thank you for notifying us.

Upvotes: 1

Related Questions