#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

#2 2015-04-03 16:08:15

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

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?

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 !!!

ab wrote:

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

Board footer

Powered by FluxBB