Successful connection:

% package require Thread
2.7.1
% set t [thread::create]
tid000016FC
% set h [socket -async www.google.com 80]
sock01AE4608
% thread::transfer $t $h
% thread::send $t "fconfigure $h -error"
% thread::send $t "puts $h GETS"
%

and connect error:

% set t [thread::create]
tid000014C0
% #set h [socket -async www.google.com 80]
% set h [socket -async localhost 30001]
sock01AE4708
% #fconfigure $h -unsupported1 1
% fconfigure $h -blocking 0
% thread::transfer $t $h
% thread::send $t "fconfigure $h -error"
connection refused
% thread::send $t "close $h"
%

Bugs

Win TCL8.6.1 only tries first IP

Bug 13d3af3ad5

TCL8.6.1 only tries the first of eventual multiple IP addresses to connect. This may cause serious connect issues, specially with IPV6.

This is fixed in branch bug-13d3af3ad5 which also serves as main branch to fix all bugs in TCL8.6.1 and to test enhancements too.

Win connect ignored

Bug 336441ed59

Two issues:

1. When a connect terminates to quick so the notifier is not ready yet, the connect is ignored and thus it waits forever for it.
2. A call of puts, gets or read while connecting shortly switched off the connect notification.

Test for 1 is timing dependent and may ignore issue on some machines. Test for 2 is to run the teapot client massively, see bug description.

Empty error message on close on failed background flush

Bug 97069ea11a

The test is difficult, as an async connect must fail after a puts is issued on the channel.

Idea: write a dummy channel driver, which may be set to an error state by fconfigure -seterror and where the readbale/writable state may be set. So one could:

set h [open dummy]
fconfigure $h -seterror EWOULDBLOCK
fileevent $h writable {set x writable}
fconfigure $h -blocking 0
puts $h abc
fconfigure $h -setwritable 1
vwait x
catch {close $h} e d

No readable event on async socket connect failure

Bug 581937ab1e

TCL hangs in event queue when an async socket tries next IP and there is already a connected socket

Bug c6ed4acfd8

ToDo's

Robust tests

(Bug 42d50ebd ) Many tests now got timing dependent. Here is my discussion proposal to eventually cure that:

As found out yesterday, it is not possible any more to fix the moment when a socket connect fails. Example:

set h [socket -async localhost [randport]]
# This needs two "updates" to fail, one for ::1, one for 127.0.0.1
# Background connect to ::1 started
fconfigure $h -blocking 0
# if connect to ::1 already failed, connect to 127.0.0.1 starts
puts $h Hi
flush $h
# if connect to 127.0.0.1 already failed, this shows the error
"connection refused"
# if connect to ::1 already failed, connect to 127.0.0.1 starts

For most tests, we need the connect procedure fail after the flush.

So I propose to:

• Add a test command "testsocket testflags $h bool" which sets a channel flag to not continue the connect on any command.

Thus, the upper test may go like that:

# Switch auto-continue off
set h [socket -async localhost [randport]]
testsocket testflags $h 1
close $h
# Now do the test setup:
set h [socket -async localhost [randport]]
fconfigure $h -blocking 0
puts $h Hi
flush $h
fileevent $h writable {set ::x 0}
# switch auto-continue on to have normal operation
testsocket testflags $h 0
vwait x

This is implemented in fossil branch robust-async-connect-tests

The same way, we could also do the test for tclIO.c "background error but no error message".

There are still a couple of test failures on CentOS and on FreeBSD documented in ticket 13d3af3ad5 .

prioritize connect errors and return most appropriate

If a socket connect fails, the error in the latest connect stage should be returned. This would prioritize "access denied" (e.g. socket in use) before "network unreachable" (no route).

Project stage for Win and Unix.

This is already implemented for Unix server sockets.

TclWinGetSockOpt() stubs entry may return wrong state

The Win TCL stubs table contains an entry for TclWinGetSockOpt() which returns the info from getsockopt().

In TCL8.5, the result of fconfigure -error was always the return value of the system call getsockopt(). In TCL8.6, a connect failure is cached in a variable and returned by fconfigure -error. Eventually, this should also be done by the routine called by the TclWinGetSockOpt stubs entry.

The purpose of this stub entry seams to be from the times of Windows 98 where a WinSock2.dll may not be present. There are no known usage of this. Thus it was decided to leave it as depreciated and to remove it for Tcl9.0.

When one puts pending data while connecting:

set h [socket -async $host $port]
fconfigure $h -blocking 0
puts $h "HELO"
flush $h
vwait forever

this data is automatically sent when the connection is available.

I have no idea how this works, but it seam to work.

If there is a writable event, ok, I see the entry point for the framework, but without ?

This is a marker for me to investigate this.

A proposed test is a bit like that (sorry, in German from an E-Mail to rmax):

Wir brauchen:
- eine Maschine mit IPV4 und IPV6.
- info ob erst IPV4 oder erst IPV6 geprüft wird.
Im folgenden wird (wie bei mir) erst IPV6 geprüft.

Server und Prüfer:
proc accept {s m p} {
    set ::s $s
    set ::x [gets $s]
    # hier kein close, da es auch Prozesse auslösen kann
}
set server [socket -server accept -myaddr 127.0.0.1 30000]
vwait x
set x
# -> x muss "Hi" sein
close $server
close $s

Client in extra Prozess
set h [socket -async localhost 30000]
fconfigure $h -blocking 0
puts $h Hi
# stößt eventuell zweiten connectversuch an, aber gibt erstmal
EWOULDBLOCK an Framework zurück...
flush $h
# bis hierhin wird nichts gesendet, da noch der zweite Connectversuch läuft.
# Hier wird jetzt connected und im Hintergrund automatisch das flush
ausgeführt. Wie ? keine Ahnung aber bei mir gehts....
after 2000 {set w 1}
vwait w

# kein close, Daten müssen ohne close ankommen...
# auch kein fileevent, da das auch ein background flush auslöst.

In the windows API, there are two system functions which basically do all the work done in the tcl connect loop:

• WSAConnectByList : To try connects to a whole list of IPs replacing the loop in the core
• WSAConnectByName : Even does the name lookup in one call

Those functions are only available for Vista+ (Desktop Applications) and Windows 8.1 (all Applications) (whatever that means).

Jan Nijtmans has sent me the following pointer to make code dependent on the availability of windows features: [L2 ]

To use this would increase performance within the connect procedure as there is no wait for the event loop etc necessary. In addition, the loop over IPs could be removed which makes a whole bunch of things easier.

rmax - I don't think this is The Right Thing to do for now, because the WSAConnectBy*() functions don't seem to allow non-blocking operation, so they would only be usable for blocking connects. This means we'd still need the looping and event loop stuff for [socket -async]. Another reason why we couldn't drop the loops even from the synchronous case is that we probably still want to support Windows versions before Vista.

So on the bottom line, we wouldn't save any of the current code, but add a lot of complexity, because the code would have to decide when these convenience functions can be used and load them. It would also increase testing effort, because different Windows versions are needed to test the different code paths.

I'd rather suggest to invest that time into unifying the two loops from the Windows and Unix platform code into a portable convenience function that goes into generic/tclIOSock.c, so that future changes don't have to be done twice.

HaO Thanks Reinhard (also for the chat session). After reading the docs it seams only be usable for syncroneous operation and lacks of options '-myip/-myport'. So using those commands is not an option.

For me, the final goal for the command 'socket -async' is:

• it returns imediately (not after DNS lookup)
• it works fully in the background and only gives a status when connected or completely failed
• it has highest possible performance

and I hoped I can reach those aims without putting all the connect process in its own thread. Aparently, this is not the case using those functions. They block and they don't have the full functionality.

Thanks

Thanks to Wojciech Kocjan for his book BOOK Tcl 8.5 Network Programming and discussions which taught this network stuff to me.