#1948 socket-2.4 fails on WinNT

obsolete: 8.4b1
closed-invalid
5
2002-07-08
2002-07-06
Kevin B KENNY
No

In the current HEAD, socket-2.4 appears not to be
working owing to some sort of synchronization problem
within the test case.

==== socket-2.4 tcp connection with server interface specified FAILED
==== Contents of test case:

removeFile script
set f [open $path(script) w]
puts $f {
set timer [after 2000 "set x done"]
set f [socket -server accept -myaddr [info hostname] 0]
proc accept {file addr port} {
global x
puts "[gets $file]"
close $file
set x done
}
puts ready
puts [lindex [fconfigure $f -sockname] 2]
vwait x
after cancel $timer
close $f
}
close $f
set f [open "|[list $::tcltest::tcltest $path(script)]" r]
gets $f x
gets $f listen
if {[catch {socket [info hostname] $listen} sock]} {
set x $sock
} else {
puts $sock hello
flush $sock
lappend x [gets $f]
close $sock
}
close $f
set x

---- Result was:
couldn't open socket: connection refused
---- Result should have been (exact matching):
ready hello
==== socket-2.4 FAILED

Discussion

  • Logged In: YES
    user_id=75003

    Sorry, I am unable to reproduce this on my Win2K system.
    Does this happen for every run, or only now and then ? How
    many server sockets are open on your system ? Maybe you
    exceeded what the system allows.

    The only possible sync problem which might exist is the race
    between reading the port number from the pipe and opening
    the socket in the caller, and writing the port number and
    entering the event loop in the server. I am unsure about this
    because the server socket already does exist at that time
    and maybe the OS buffers a connection request coming in,
    before the event loop starts looking for such events.

    And this we should be able to avoid with a small delay
    between 'gets $f listen' and the 'socket' command. [after
    1000] or so.

    Can you test this ?

     
  • Kevin B KENNY
    Kevin B KENNY
    2002-07-08

    Logged In: YES
    user_id=99768

    Sorry about the false alarm. There was a brief DNS outage while I was running the test suite, and that apparently
    caused the problem.

    We might want to have the tests use 127.0.0.1 in place of [info hostname] when making connections that are
    known to be on the local host.

     
  • Kevin B KENNY
    Kevin B KENNY
    2002-07-08

    • status: open --> closed-invalid
     
  • Jeffrey Hobbs
    Jeffrey Hobbs
    2002-07-08

    Logged In: YES
    user_id=72656

    It is important to note that [info hostname] will of course
    follow different code paths, so it may not be appropriate to
    replace it for all tests. Also, at the OS leve, the loopback
    address often follows a different codepath than referring to
    machine by name or global IP. This may not be important to
    all tests, but there are likely a few where info hostname
    should still be used.

     
  • Logged In: YES
    user_id=75003

    From the comments below and talking with Jeff I have
    decided to make the change for the test mentioned in this
    report, i.e. socket-2.4, but nowhere else.