Ticket UUID: | 5425f2c08257f7d9660276c4c8f764ad2d178e1c | |||
Title: | Async socket connect may flag error and still connects | |||
Type: | Bug | Version: | 8.6.1 | |
Submitter: | oehhar | Created on: | 2013-11-12 08:52:47 | |
Subsystem: | 25. Channel System | Assigned To: | max | |
Priority: | 5 Medium | Severity: | Important | |
Status: | Closed | Last Modified: | 2013-11-12 15:50:56 | |
Resolution: | None | Closed By: | max | |
Closed on: | 2013-11-12 15:50:56 | |||
Description: |
(text/x-fossil-wiki)
<h1>Issue</h1> In an asyncroneous socket connect, there might be errors flagged even if the connect finally succeedes. This appeared on MAC-OS X with tcl8.6.1. <h1>Demo</h1> We have a server socket on an IPV6 enabled system which only binds to the IPV4 address. This might be done in a tclsh console with the following program: <verbatim> % proc accept {s a p} { puts ok } % socket -server accept -myaddr 127.0.0.1 61680 sock192 % vwait a </verbatim> In a second tclsh, the following is run: <verbatim> % set client [socket -async localhost 61680] sock103825910 % fconfigure $client -error connection refused % update % fconfigure $client -error % fconfigure $client -sockname ::1 localhost 64153 </verbatim> The issue is the flagged "connection refused" and the final connect. <h1>References</h1> Reported by DKF on Ticket [13d3af3ad5] and copied here by oehhar. | |||
User Comments: |
max added on 2013-11-12 15:50:56:
Just for completeness: the tracing I mentioned in the last comment doesn't work as I thought, because [fconfigure -peername] is not available before the socket is connected. max added on 2013-11-12 13:27:29: Fixed in [80ca9fe746] and [f644fb5a9f]. When implementing multi-address [socket -async], I thought it would only be used together with fileevent, and [fconfigure -error] would not be called before the readable event has fired. But now I see that -async without fileevent even makes sense, e.g. to trace the addresses that were tried and why each of them failed, so the error caching (reading SO_ERROR is destructive) needs to go both ways, from the event handler hidden behind [socket -async] to [fconfigure -error] and vice versa. dkf added on 2013-11-12 12:22:33: (text/html) To be clear, the issue is that <i>looking</i> at the transient error prevents the client from ever connecting. That's much more serious than merely seeing a transient error. |