From: SourceForge.net <no...@so...> - 2004-02-25 14:34:47
|
Bugs item #219195, was opened at 2000-10-26 06:03 Message generated for change (Comment added) made by dkf You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=219195&group_id=10894 Category: 27. Channel Types Group: obsolete: 8.0p2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Andreas Kupries (andreas_kupries) Summary: async Tcl_OpenTcpClient failure remains undetected Initial Comment: 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 ---------------------------------------------------------------------- >Comment By: Donal K. Fellows (dkf) Date: 2004-02-25 14:31 Message: 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... ---------------------------------------------------------------------- Comment By: David Gravereaux (davygrvy) Date: 2003-04-22 21:44 Message: 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 :) ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2002-07-05 21:36 Message: Logged In: YES user_id=80530 Another candidate for oldest Open bug. Still valid? ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2001-09-11 21:01 Message: Logged In: YES user_id=75003 Hermann Hüni <hu...@gl...> ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2001-01-16 13:42 Message: 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... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=219195&group_id=10894 |