Frank Greco on WebSocket
Recorded at:

Interview with Frank Greco by Barry Burd on Oct 24, 2013 | NOTICE: The next QCon is in London, March 6-10, 2017. Join us!

Bio Frank D. Greco is Director of Technology for Kaazing Corporation. He is responsible for the Kaazing cloud computing strategy and guiding customers with new technology approaches that leverage the value of extending application protocols over the web. Frank chairs the NYJavaSIG (largest Java User Group in North America) and the NYHTML5 User Groups. Twitter: @frankgreco

Software is Changing the World. QCon empowers software development by facilitating the spread of knowledge and innovation in the developer community. A practitioner-driven conference, QCon is designed for technical team leads, architects, engineering directors, and project managers who influence innovation in their teams.


1. I am Barry Burd from Drew University in Madison, New Jersey, and I am talking with Frank Greco at QCon. Frank, introduce yourself, tell us what you’re thinking about these days!

Thank you. I am Frank Greco. I am director of technology for Kaazing Corporation, and what I am really hot on right now is this new technology for doing event driven programming over the web: WebSocket.

Barry: Then tell me about WebSocket.

Sure, so for 15+ years we’ve had only one protocol for the web and it has been HTTP and it’s something… it’s done as really a good thing over past 15 years, given us efficient document upload/download. But for event driven things, which is the world that we live in, it is really not suitable. It’s not suitable in a lot of different respects. It’s very verbose, because as you know it is stateless. So you have to maintain where you were along with the communication at every point. So it’s very, very verbose, I mean we are talking about the difference between WebSocket and HTTP is possibly 100 to one, in terms of bytes sent over the wire. And for simple documents that might not be an issue, but again as we move into a more real-time environment this becomes painful. And as most enterprises now take their applications over the web, this becomes very painful. So it’s just a better protocol to use. I mean WebSocket is a peer protocol to HTTP. It’s not that you have WebSocket on top of HTTP, it’s that they are peer protocols. So any real-time TCP-protocol can now live over the web by being converted to WebSocket. And there are many open source implementations and like my company there are many commercial implementations.


2. It sounds like it is all good, a win-win. Are there disadvantages or reasons why we did not do this in the very beginning of the web?

Well, if we go back to the beginnings of the web, I mean we are talking about the early 90ies and even late 80ies with hypertext. The world was different than. Network technology was different. So HTTP really was suitable for the technology of the day. We did not have the hyper fast networks that we have, really interesting programming languages and other ways of retrieving data and extending real time protocols over the web. So HTTP really reflected the world, as I remember 1987 or 1988, when hypertext was very hot. So it was just obviously the combination of internet and hypertext gives us the web. But now we do have better networks and the network that I have in my home is significantly faster than what we had way back in the early 90ies. And with enterprises having even faster networking, to do a lot of the event driven things that they want to do is just too painful to do with HTTP. So, if you want to have some sort of event driven technology and applications in your enterprise, what you had to do before WebSocket was something called AJAX. And there is also something called reverse-AJAX or as it is commonly known as Comet techniques, which were never standardized.

There are some implementations which never worked together, but it was a way of doing asynchronous communication, having a server tap the user as opposed the user always going up to the server. Now we learned inside the enterprise that doing this type of technology, basically a polling type of technology, and we learned in Computer Science 101 that polling is resource intensive. And this is certainly true with AJAX and Comet technologies. Inside the enterprise we learned ten years ago that these types of technologies were not scaleable, they were brittle. We had technologies that were point-to-point like Sun RPC, CORBA, that were point-to-point, and we learned very quickly they are to brittle. They were inflexible. And we were doing multi-part transactions, it was difficult to get a guarantee, to get a transactional guarantee from point to point that indeed I did make that trade, or did buy that product. So now over the firewall, outside of the enterprise, or cross enterprises, we can now extend similar types of internal protocols over the web, using WebSocket. So this is a big change for enterprises. So we don’t want to go over the same problems we had ten years ago. We have already learned this. And it is going to be interesting, what’s going to happen to REST. REST was invented as a very simple model for doing remote procedure calls – and a lot of open source implementations and a lot of standardization about REST, but REST was created in a world were we had HTTP. So if you go back ten years, you can consider REST almost like CORBA and like Sun RPC.

For simple things it works fine, but for complicated things like doing transactions and with enterprises doing more transactional stuff over the firewall, is REST going to be the solution we are going forward? I am not sure. I think we are going to re-solve an old problem. And we are going to come up with a different way of doing communications over the web. And we learned inside the enterprise that ESBs, enterprise service buses, publish/subscribe mechanisms, that was the solution to doing Sun RPC or other types of things like CORBA and other RPC-type mechanisms. I think we are going to see that in a few years, as we move from REST synchronous type of calls to something that is more real time, because that is the world that we are living in. So it will be interesting in the next few years.


3. So with WebSocket you have a continuing connection between two parties, the peers, the sender and the receiver, whoever calls whoever at what time. Is there a price that we pay for having a connection, maintaining a connection?

Well, it is a persistent connection. That’s very very true. The price, I mean, it is common to think like how scaleable is that? Which is like you see a car, how possibly fast can that car be, without driving it. Right? So it depends on the implementation. Obviously we feel we have a very fast, a very scaleable implementation. It takes care of some of the persistent issues like in a mobile environment, where might not have connectivity, it might be broken for a while, and you reconnect. So it depends on the implementation. You can’t say it’s not scaleable. You might have an open source version that does not do reconnects in a mobile environment, certainly that’s not a good thing. So it just depends on the implementation.


4. [...] There has to be something going on that is more intensive than HTTP. Am I right?

Barry's full question: I’m thinking of comparing it to a very data heavy connection or a very data heavy application, like I if am watching a movie on Netflix. So the data is just coming, coming and coming. What costs am I incurring just to maintain a connection with WebSocket? Certainly it’s not that the data is just flowing as in an mpeg-file. There has to be something going on that is more intensive than HTTP. Am I right?

Well, think about WebSocket as a socket. If you are doing programming inside the firewall, you are not going over the web, you have a socket. What do you do to a socket to do that? You assume that there is a persistent connection, that you have a guaranteed point-to-point connection. Is there anything additional that you do there? Not really, not at that level. I mean obviously, once you start programming at that level, well this happened 40 years ago, or 40 plus years ago, when people first got TCP sockets in their hand, everybody programmed at the TCP socket layer. And very quickly you find out that – how do I do retries, how do I do guaranteed semantics, how do I do pub/sub, how do I do this, how do I do that – so what was invented next? Application protocols were invented next that sit on top of TCP socket. So we feel the same thing is going to happen to WebSocket.

That people will program at the WebSocket layer and they will come to the same realization that they did 40 plus years ago, that we need application protocols that sit on top of WebSocket, because they make life easier. We learned the advantages of application protocols, the are just: we can program faster, we can solve problems faster and took care of a lot of issues, or abstracted away a lot of the issues. So that’s part of what the value Kaazing provides, that we provide a layer on top, that gives you that capability to do JMS on to of the WebSocket, XMPP on top of the WebSocket, AMQP, etc., etc., etc. All the TCP protocols can now sit on top of WebSocket unfettered now over the web, of course in a secure manner. So it is a cool time to be in this HTML5 era we’re at the beginning of this massive wave of change and WebSocket in our opinion and in most peoples’ opinion it’s the most important API in the bag of tricks that HTML5 gives us.


5. [...] If I am developing thinking WebSocket in mind, to what extent has this been standardized and can I assume that a client of one sort or another that wants to visits my website can see it?

Barry's full question: In your talk that you gave at your New York Java SIG, you introduced me to ws:// and told me where to go to visit such a site. But then I asked myself, can I rely on this as a standard? If I am developing thinking WebSocket in mind, to what extent has this been standardized and can I assume that a client of one sort or another that wants to visits my website can see it?

Right, very very good point. So WebSocket is basically two components. There is the WebSocket API which is defined by the W3C, which is a standard API and there is also bits over the wire standard, which is the IETF standard. So both of those components are official standards, by the W3C and by the IETF. IETF RFC 6455 is a formal specification for the bits over the wire for WebSocket. And all the browser manufacturers, I mean all of them, bar none, have now adopted – either they have adopted in their current browsers or have stated direction to have WebSocket in their browsers in the future. So it is a standard. Now, for older browsers, because we know that we still are living in a world of legacy browsers, we all know what legacy browser means. How do you handle that? So there is several ways to handle older browsers: you can fall back to polling. If you detect that you don’t have native WebSocket you can fall back. There are other solutions, I mean Kaazing has a solution where we fall back to HTTP. We give you the same benefit of WebSocket by emulating the WebSocket protocol. The WebSocket abstraction is our base line, now whether you got a physical WebSocket layer underneath it or an emulated WebSocket, that’s part of our value added.


6. Are there use cases that don’t lend themselves to WebSocket?

Well, WebSocket is natural for event driven communications. If you have something that is not event driven and that can be done with HTTP, like it’s a document, get a page or some date, there is nothing wrong to use HTTP for that. So WebSocket will live alongside HTTP for a many years to come. HTTP has a lot of advantages, I mean for caching purposes, it’s simplistic and everybody understands it, use it for that. But for event driven things, HTTP is not suitable for event driven things.


7. We are getting closer and closer to the world in which all I really need is a browser, as a consumer? And the response of the browser is as snappy, as responsive as on the desktop?

I think we are moving to a world where the browser will remain a browser and we’ll certainly get better browsers and I think the big browser companies are providing phenomenal browsers. The Chrome browser, the new Firefox browser, even Safari is moving up and even Microsoft, I mean IE10 is a big change. I have seen some pretty cool graphics capabilities in IE10. But there are other places where the web is showing up, not just in browsers, but the web is showing up in cars and devices. Audi has standardized on HTML5 for their entertainment system in their car. WebSocket is part of the bag of tricks of HTML5. There is no reason why WebSocket can’t live in an Audi in your entertainment system, whether it is for notification, news, alerts, traffic alerts, there are many places where the web will show up, other than just a browser on a desktop.

Barry: It’s more the internet of things than the internet of browsers.

Well certainly browsers are morphing, right? We are obviously moving into a mobile world, if not already, in a mobile cloud world. And that is a standard. You develop the applications for mobile first now, as opposed to desktop. And we have cloud computing, so the browser of tomorrow, or the web client of tomorrow, it could be a desktop browser, it could be one in your pocket, it could be a pad, a tablet type of device. It could be in your car, it could be the internet of things, it could be the web of things, where there are web services, and I mean web services in a lower case, generic services out there on the web, that are provided to machines. Right, machines, we are going to have billions and billions of machines. Those machines typically will need services in the cloud. How will they communicate with the services? They are not going to use TCP. Right, they need something that is safe, you know, web friendly and we feel that they are going to be communicating with WebSocket.


8. Speaking of the future, is there talk about a WebSocket 2.0 standard? What is next for WebSockets?

Well, the WebSocket standard is a fairly fresh standard. I mean the IETF WebSocket standard was ratified in December 2011, so it’s fairly new. And we see implementations like the Kaazing implementations and other implementations of that. There are enhancements to the protocol. I would not say that it’s a WebSocket 2.0, there are enhancements. You know, there are things called subprotocols, standard ways to do compressions to a WebSocket. That is part of these subprotocols. There are things like multiplexing a WebSocket connection. So you can imagine in the future that if I have WebSocket in the cloud and it can multiplex, you could have ad hoc LAN networks appearing spontaneously, safe LAN networks, private LAN networks just appear in the cloud and go away when you are done. So it’s pretty interesting what we will see over the next few years.

Barry: It’s exciting. Frank thank you so much for being here.

Thank you, Barry.

General Feedback
Marketing and all content copyright © 2006-2016 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.