[zeromq-dev] Websockets as a Transport ?

[Mark Farnan]

Hi Ben,

 

HttpS (more specifically SSL) is mandatory requirement in the Industry, just
forget trying to do anything without it that involves the Internet. 

 

You are correct that Websockets uses TCP underneath, just the same as HTTP
uses TCP underneath, and that's also the issue.  The protocol for Websocket
establishment works over 80/443 in places where trying to do a TCP open will
FAIL.  (we've tested it).  There are any number of statefull firewalls which
will allow the initial HTTPS connection, but will block a TCP one.

 

It will also fail a security Audit, as it is against Policy of the major
companies in question.   I'm referring here to some of the biggest Oil
companies in the world. (Policies we can't change).

 

Websockets uses standard HTTP/S methods to upgrade the connection.  We have
found issues using straight ws:// connection due to some firewalls, but so
far almost everything allows  wss://  which is SSL Websocket, upgraded from
a HTTPS connection.   It is this upgrade mechanism that is critical for it
to work.

 

Websockets are bidirectional once established, not 'client server'.    We
also don't want to use STUN, ICE or any of the Nat traversal mechanisms via
the 'cloud'.   That will also fail security audits for a start.  Initial
Establishment of the Websocket connection is client to server of course.

 

I don't personally see how adding encryption makes using something like
ZeroMQ a problem ?  If it's the fastest protocol without transport
encryption, it should remain the fastest one WITH transport layer
encryption.   

 

WS-Eventing still requires bidirectional connection establishment.  This
isn't going to fly with clients where one of the nodes is behind a NAT
device.  We looked at that, but appeared to be a non-starter.

 

 

In my opinion, Websockets will likely represent the future of Internet Push
or Publish/Subscribe Traffic (It's a hunch).  The first few messaging
systems which embrace it are likely to dominate.  I was hoping ZeroMQ might
have been going that way also.

 

RabbitMQ has a websocket transport, going to try that out next week.

 

Regards

 

Mark Farnan

Director, Product Development

Petrolink Services Inc

+1 281 908 9814

 

From: zeromq-dev-bounces at lists.zeromq.org
[mailto:zeromq-dev-bounces at lists.zeromq.org] On Behalf Of Bennie Kloosteman
Sent: Friday, July 06, 2012 10:41 AM
To: ZeroMQ development list
Subject: Re: [zeromq-dev] Websockets as a Transport ?

 

Hi Mark, 

 

Web socket uses tcp underneath so getting through the firewall is no issue
just use port 80  , and in fact web sockets ( and things that use port 80 )
have issues with some ISP html proxy servers and load balancers and it will
take time for these products to mature to handle web sockets.

 

AFAIK web sockets is also client to server and most clients already have
open all ports out and few in , if you want in a solution like Microsoft
Azure uses is ideal ( they have a tcp connection , it tries to open a
firewall port to receive and if it fails it relays it via the cloud - but in
the best case you have direct client to client connections) 

 

 I would not trust https too much it does not add a lot , make sure the
authentication is good.

 

Also  by the time you add the higher level costs like encryption what is the
point to using a light weight protocol  like zeromq ? You may as well use a
nice API like WS-Eventing  which can still do 3ms  packets  (
100Kpackets/sec per server) 

 

Ben

On Fri, Jul 6, 2012 at 6:53 AM, Mark Farnan <mark.farnan at petrolink.com>
wrote:

Correct,  What I am after is a bit different.

I am looking for using Websockets as native transport,  machine to machine
running ZeroMQ natively at each end, across firewalls.   For our case we
can't rely on a TCP port being open to work through.  Websockets provides
the ideal transport protocol for this.

i.e.
 Connects Https
 Handles Security (even  basic Auth is fine, as it is HttpS).
 Upgrades the connection to Websocket  wss
 ZeroMQ runs 'as is' over the now established Websocket.

This, or something similar, is what I am thinking.   (You can actually do
all of this in one step with a http connect and upgrade frame)

So ideally a client would provide the address,  i.e.
"wss://someserver.someplace.com/something", to the Socket Connect function,
along with an optional username and PW,      It establishes the session, and
ZeroMQ works as before from there.

The ZeroMQ receiving the connection would need a registered callback of some
kind to handle  the authentication, which just passes back 'true or false'
if its accepted or not.


Would anyone else maybe interested in doing this ?

Regards

Mark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120706/9100c1f0/attachment.htm>