You are not logged in.
- Topics: Active | Unanswered
#1 2015-04-03 13:20:03
- Amir
- Member
- From: UAE
- Registered: 2010-08-17
- Posts: 36
Probable connection fail in presence of proxies !!!
Hi Dear Arnaud.
I took a look at "THttpClientWebSockets.WebSocketsUpgrade()" method's implementation, I think we need an additional connection check even if the WS-upgrade reported successfully. As you may know WS connections may fail in presence of many widely used tunneling-services, especially with regular websocket connections. WSS (TLS Enabled) websockets may pass this step with much much greater chance (very rare to fail). As the use of tunneling [for security reasons, logical network segmentation, traffic control (bandwidth management) and ...] seems very common, I think such a solution should be considered.
Thanks.
Last edited by Amir (2015-04-03 23:03:12)
Amir
Offline
#3 2015-04-03 19:47:28
- Amir
- Member
- From: UAE
- Registered: 2010-08-17
- Posts: 36
Re: Probable connection fail in presence of proxies !!!
How do you want to make the connection check?
By sending a ping on the other side?
Hi,
"Ping" uses an ICMP echo, so it is expected to work with any active connection regardless of being run within a network-tunnel (if we assume there would be NO blocking firewall-roles or route-maps). As the problem is basically the web-socket itself, we should send the traffic directly through the currently upgraded web-socket and get the result(s) back; in order to validate its functionality.
You have introduced a method to check the server availability as "TSQLRestClientURI.ServerTimeStampSynchronize()" which performs fast and simple pulling. After the web-socket's handshake - which is HTTP-based -, the rest of connection semantics uses web-socket's standards; so if the "upgrade" is satisfied, any other traffic should be transferred in web-socket's way. Therefore "ServerTimeStampSynchronize()" should fulfill the need.
What is your idea ??
As you may know https://www.websocket.org/echo.html implements an echo-server using HTML5 web-sockets. Here you can use a VPN (using different tunneling protocols) to reveal the problem, as the problem is also noticed on the page.
To be honest I think implementing HTML5 Web-sockets was a very nice try, but unfortunately it is not so accepted by many active network-devices' configurations, simply because it is very young and not widely used, today.
This great technology works nice on a local-host, but may not work as expected in a real world use-case.
For example; consider xDSL users which are connected to their ISPs using a tunnel (very common), they simply may have problems with web-socket connections and also offices/organizations which use proxies and different network tunneling services for different purposes (Security, Segmentation and Net. Traffic management) and ... They all may have unsuccessful experiment with their web-sockets-powered apps.
As I mentioned in my earlier post, secure web-sockets (wss://) using TLS may fail in very rare situations and seem to be operational in real world projects. so if we want to have a safe and working web-socket service with today's common network settings, we'd better use secure web-sockets i.e: over TLS.
But as you yourself noticed, IMHO the best and always working solution to implement a bidirectional, asynchronous, and REST-friendly publish-subscribe collaboration mechanism, for today's mORMot; is hiring a message queue system, as the great, light, cross-platform, open-source and of course very fast "0MQ" - which you also liked.
...and as always, thanks for you great work.
Best.
Last edited by Amir (2015-04-04 00:06:33)
Amir
Offline