[plt-scheme] weak tcp-fu or bug?
Hi there,
I am having some trouble quickly establishing and tearing down TCP
connections and bindings on the same port. After a couple of
iterations my connecting thread reports a successful connection but
the accepting thread does not. This might be a normal artifact of how
TCP is implemented on Windows but I do not know enough about TCP to be
sure.
Below is a little sample that illustrates the problem. Iteration on my
Windows XP Professional stops at 2 or 3. I have also attached the
output of the sample, which includes interleaved calls to netstat.
Any ideas?
Thanks in advance,
-pp
(begin
(require (lib "async-channel.ss")
(lib "thread.ss")
(lib "process.ss")
(lib "setf.ss" "swindle"))
(define ch (make-async-channel))
(define (accept port)
(run-server port
(lambda (in out)
(printf "Accepted~n")
(async-channel-put ch (current-thread))
(sleep 100000))
#f))
(define (connect port)
(printf "Connecting~n")
(tcp-connect "localhost" port)
(printf "OK~n"))
(define (test port)
(let ((th1 (thread (lambda ()
(accept port)))))
(connect port)
(system "netstat")
(printf "Waiting for read thread to start~n")
(let ((th2 (async-channel-get ch)))
(printf "OK~n")
(kill-thread th1)
(kill-thread th2))))
(let loop ((n 0))
(printf "Test ~a~n" n)
(test 41235)
(printf "...OK~n")
(loop (+ n 1))))
-------------------------------------------------------------------------------------
Test 0
Connecting
OK
Accepted
Active Connections
Proto Local Address Foreign Address State
TCP Strider:1602 localhost:41235 ESTABLISHED
TCP Strider:41235 localhost:1602 ESTABLISHED
Waiting for read thread to start
OK
...OK
Test 1
Connecting
OK
Active Connections
Proto Local Address Foreign Address State
TCP Strider:1602 localhost:41235 CLOSE_WAIT
TCP Strider:1603 localhost:41235 ESTABLISHED
TCP Strider:41235 localhost:1602 FIN_WAIT_2
TCP Strider:41235 localhost:1603 ESTABLISHED
Waiting for read thread to start
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20060413/4af14ea8/attachment.html>