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: [email protected] [mailto:[email protected]] 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 <[email protected]> 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
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
