Francois PIETTE wrote: >> Some proxies just close or reset the connection if, for instance, the >> remote server is not listening or if Socks authentication fails for >> some _technical reason. It's my understanding that in such cases >> SessionConnected should be triggered with an error > 0 before >> SessionClose, is that correct? >> Currently both Socks and HTTP-Tunnel code in TWSocket don't do >> that but only trigger SessionClose, even without an error in case >> of close (fin). > > Yes, normally in case of a connection cannot be established,
OK. > OnSessionConnected should be called with a non nul error argument and > then OnSessionClosed with same argument. Currently I do not think so. With a proxy we have a special case, in case the connection to the proxy is established successfully we delay OnSessionConnected until we either passed thru or got some error response from the proxy. Now if the proxy silently resets or closes the connection without prior returning any error response while the tunnel is not established yet the component should pass a proxy-specific error code to OnSessionConnected and the true winsock error code to SessionClosed IMO. Why must the error code in SessionClosed be faked as well? Note that the true error code on SessionClosed in case above can WSAECONNRESET or zero respectively. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
