[zeromq-dev] Websockets as a Transport ?

[Bennie Kloosteman]

On Sat, Jul 7, 2012 at 8:16 AM, Mark Farnan <mark.farnan at petrolink.com>wrote:

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

I know but  you said minimal authentication  , if you break the
authentication you can create an SSL socket.
I have also wondered about HTTPS  on private network  , people with network
access have admin and can watch your packets  and on the internet it is
really hard to separate a single http channel in a gigabit traffic stream (
I tried )... It does cover low speed ISPs and wireless connections where
people don't turn on encryption and that makes it essential .

> ****
>
> ** **
>
> 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.
>

So are they look for a http in the header ? That's easy enough to dummy ...
I have frequently used tcp over port 80 which works through most firewalls
 unless you have a nasty http proxy server / load balancer but a lot of
those ( not all ) also have issues with web sockets.


> ****
>
> ** **
>
> 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).
>

How can it fail when web sockets do the same thing ..I worked for a major
merchant bank and if you had a good reason security was normally granted.
You may be stuck with a requirement for encryption which can make sense,


> ****
>
> ** **
>
> 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.
>

That is useful a friend had a look at it last year and had some hassles.
That said unless you have tested MANY ISP I would  extremely careful with a
new technology.   especially transparent  http proxies , load balancers
which can be 10 year old boxes and nasty things like the great firewall. I
mean some isp love breaking long connections since you may be hogging
resources.

> ****
>
> ** **
>
> 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.
>

Its still client server even if bi directional eg you cant have 2 clients
communicating directly without going to your server.   Its just the client
is piggy backing on the return channel which makes it similar to bi
directional but unlike real bi directional system if the one socket goes
the connection goes.

> ** **
>
> 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.
>

Once you add the encryption and internet latency the difference becomes
very small possibly negligible.
****

> ** **
>
> 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.****
>
> **
>
Nope ,nothing in the spec says that only the common implementations are bi
directional .I have seen store and forward  and I  built a system with
WS-Eventing where the clients  ( 3000 windows mobile handhelds behind many
different  NATs) polled  a message holding service which held the eventing
server for new messages.  Building push was also possible  , since it was
WCF based I quickly build a prototype ( change the binding and hook it up
to where the polled messages were dispatched ) which automatically used  a
connection similar to web sockets but it didn't make it because we had many
connection drop outs(mobile nets)  and there were a few bugs to sort out
which would make it too expensive .


> **
>
> ** **
>
> 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.
>

I really have seen little use for these roles, to me the compelling roll
for web sockets is to write more complex html5 javascript apps that use
them due to a simple API will less security hassles . Not to replace
messaging systems which all have ways through firewalls already.

For many cases the cloud based connection services offer a compelling
argument due to the possibility of server less communication for many
clients and a fall back to relay.  And for internet based system a huge
issue in communication is still the protocol hence FIX and SOA /WSEventing
wsdl systems have a big place.  Many messaging systems like zeroMQ are used
in merchant banks and things like that and they are counting every tenth of
a milli second especially for   price information and frequent trading
systems.  In many of those environments they use private links so no need
for encryption. So to me its likely that messaging will remain fragmented.
I thought the same about WS-Eventing and to me its a great system , very
flexible ( eg easy to hook in many systems , or down load events to new
servers to handle alsmots limitless load ) but few people have used it -
public internet pub sub itsefl is not that popular, both of which to me are
dissapointing.

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

It makes more sense for AMQP based systems  , they are more complex/
flexible  and less light weight. I havent heard anyone in ZeroMq using http
yet alone https though im only  a casual observer now.



Regards,

Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20120707/0e6afa9e/attachment.htm>