Anton S. wrote:
>> however with socks "#20xxx is not a winsock error"
>> is displayed everywhere with socks errors
> What's the problem? ICS uses custom WSocketErrorDesc anyway so just
> add a definition of socks errors there.
There should be multiple new functions to lookup error messages IMO.
On
>however with socks "#20xxx is not a winsock error"
>is displayed everywhere with socks errors
What's the problem? ICS uses custom WSocketErrorDesc anyway so just add a
definition of socks errors there.
--
Anton
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http
Francois PIETTE wrote:
> I think the proxy implementation should be as transparent as possible.
Agreed and also should be as simple as possible to detect, log and display
proxy errors, especially since there are now two and even three different
proxy server types supported (FTP client).
Socks and
e multi-tier middleware MidWare
> The author of the freeware Internet Component Suite (ICS)
> http://www.overbyte.be
>
>
> - Original Message - From: "Arno Garrels"
> To: "ICS support mailing"
> Sent: Thursday, February 10, 2011 3:32 PM
&
-tier middleware MidWare
The author of the freeware Internet Component Suite (ICS)
http://www.overbyte.be
- Original Message -
From: "Arno Garrels"
To: "ICS support mailing"
Sent: Thursday, February 10, 2011 3:32 PM
Subject: Re: [twsocket] Proxy traversal error handlin
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
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?
Cu
Hi,
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 corre
