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,


> 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
Visit our website at

Reply via email to