Tcl Source Code

OriginalBugID: 2713 Bug
Version: 8.0p2
SubmitDate: '1999-09-10'
LastModified: '1999-11-10'
Severity: SER
Status: Assigned
Submitter: techsupp
ChangedBy: hobbs
OS: Solaris
Machine: Other
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'


Name:
Hermann Hüni

Comments:
Is this bug already fixed in a later release of tcl?

ReproducibleScript:
static Tcl_Channel remoteServerChannel;
    
    int main()
    {
      /*
       *open client socket to remote server
       */
      remoteServerChannel = Tcl_OpenTcpClient(/* interp */ NULL,
      /* port */ remoteServerPortNb,
      /* host */ remoteServer,
      /* myaddr */ NULL, /* myport */ 0,
      /* async */ 1);
    
      if (remoteServerChannel == NULL) {
        /*
         *tcp open has failed
         */
        perror("Tcl_OpenTcpClient failed:");
        exit(-1);
      }
    
      /*
       * register establishedEvent handler for this channel
       */
      Tcl_CreateChannelHandler(remoteServerChannel,
       TCL_WRITABLE|TCL_EXCEPTION,
       establishedEvent,
       (ClientData)remoteServerChannel);
    
    }
    
    /* 
     *socket connection established Event callback
     */
    static void establishedEvent(ClientData clientData, int mask)
    {
      Tcl_Channel channel = (Tcl_Channel)clientData;
    
    {
      Tcl_DString optionString;
      Tcl_DStringInit(&optionString);
      {
        int success = Tcl_GetChannelOption(/* interp */ NULL,
           aChannel,
           /* optionName */ "-peername",
           &optionString);
    
        /* ... */
        }
      }
    }
    
    ./myClient someHost undeployedPortNumber

ObservedBehavior:
In the following usage:
    
    ./myClient someHost undeployedPortNumber
    
    the Tcl_OpenTcpClient call does not return NULL and
    the establishedEvent callback is NEVER called.
    
    How can we get to know, that the socket connection will never succeed?
    
    Here is a real trace:
    
    bash$ ./myClient butler 799999
    main; channel options are: /-blocking 1 -buffering line -buffersize 4096
    -eofchar {{} {}} -translation {auto crlf} -sockname {0.0.0.0 0.0.0.0 0}/
    
    We could check for -sockname  not beeing {0.0.0.0 0.0.0.0 0}  as a work
    around just after the
    the call to Tcl_OpenTcpClient() ?
    
    But the real place to check the success or failure should be in the
    establishedEvent() callback.
    Unfortunately, this callback does never occur. This seems to be a real
    bug.
    
    I am using tcl8.0p2 on Solaris 2.7.
    
    Democode is available uppon demand

DesiredBehavior:
The establishedEvent() callback should occur as it does, if we give an
    unreachable host.



This should be tried again with 8.2.2, there have been many fixes
in this area since 8.0p2. 
-- 11/10/1999 hobbs

Logged In: YES 
user_id=1312539

This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

File Added - 171040: async_event.tcl

Logged In: YES 
user_id=75003

I just tried using 8.4 branch head using the attached Tcl
script, and the writable event fires for both successful and
failed connections. In case of a failure [fconfigure -error]
contains an error message. It is empty otherwise.

This for linux. On solaris the 'socket'-creation actually
came back with an error for a bad host, or port withoit
listener.

The C stuff should work in the same manner.

Logged In: YES 
user_id=79902

Can error information be retrieved (in a writable fileevent)
using the -error option to fconfigure?  ISTR that that's the
way it is supposed to happen...

Logged In: YES 
user_id=7549

fileevent writeable should fire upon either success or error, 
IIRC.

How TCL_EXCEPTION relates to the specifics of the winsock 
channel driver is unknown to me :)

Logged In: YES 
user_id=80530


Another candidate for oldest Open bug.

Still valid?

Logged In: YES 
user_id=75003

Hermann Hüni <[email protected]>

Is it possible to open this socket in asynchronous mode (with the flag -async)?  Then you can get a timeout quite simply using the [after] command, and you know (by watching for either the timer event or a writable fileevent) whether you've successfully connected or not.

Hmm.  Perhaps the -async option should note (via demo-code?) that any [fileevent writable] events defined on an async socket get fired when the connection is made...