Thanks Roger, Doc, for this very interesting info. I think this thread is very appropriate for an SVG forum (though perhaps not so much for the details under the bonnet). There are many kinds of programs which use SVG in their GUIs, and which need this kind of server response. Its not only robotics. I'm now watching Websockets closely. :-)
--- In email@example.com, "Roger F. Gay" <rogerfgay@...> wrote:
> Thanks Doc. Good to meet a fellow traveler. One of the groups I'm aiming at is people interested in robotics. There, I'd like to stream video and audio from the robot's camera to the human operator's browser-based GUI. Haven't done that sort of thing yet. Don't want to download a huge package and install. I'm still emphasizing "light-weight." Maybe this isn't the best place to ask you if you have tips on that - this being an SVG discussion forum. :)
> FrÃ¥n: Doc <drclue@...>
> Till: firstname.lastname@example.org
> Skickat: torsdag, 8 september 2011 19:46
> Ãmne: Re: SV: [svg-developers] Websockets, explained
> Howdy all
> Actually I'm just finishing up my implementation of the latest HyBi
> (WebSockets) protocol as an upgrade
> to my previous WebSocket server, so one might say I've gotten to know
> the beast reasonably well.
> The biggest thing that WebSockets have over all previous methods
> (AJAX,Comet, etc etc) is that
> WebSockets provide a true , continuously connected bi-directional
> communications channel with very little overhead.
> All previous methods are based upon constantly polling a web server.
> Polling is like having kids in the back seat on a long
> road trip constantly asking "Are we there yet?,Are we there yet?,Are we
> there yet?..." , whereas WebSockets only
> make traffic when there is data.
> My primary use of WebSockets is to provide event driven interactions
> between a browser client and Asterisk PBX (VOIP) servers,
> and it has always amazed me that when I press , let's say a [hold]
> button on a telephone that the hold indicator
> on the browser display appears to come on at nearly the exact same
> instant. No such synchronized interactions are possible
> with older methods.
> The difference in network traffic is like night and day. In the past ,
> those browser applications flooded the network
> with bulky repetitive HTTP requests , constantly opening and closing
> TCP/IP connections ,but with the
> WebSockets, all the browser clients together don't use as much bandwidth
> as even a single client did with polling.
> As to security, the same type of encryption available to HTTP
> connections is also available to WebSockets.
> The original issues in the earlier drafts seemed related mostly to the
> opening handshake, and have indeed
> been addressed. Currently they are on I believe the 13th iteration of
> the draft for the protocol with
> the latest changes seemingly related mostly to the protocol extension
> mechanism that allows one to
> build sub-protocols on top of the WebSockets protocol.
> The "wire protocol" as they like to call it has been stable since the
> 7th iteration if I recall correctly.
> Anyways , I've been coding for the Internet since ~1994, and having
> implemented a number
> of the protocols , my opinion is that WebSockets are a natural evolution
> and that the protocol itself
> is reasonably sound.
> On 09/08/2011 01:05 AM, Roger F. Gay wrote:
> > The real answer is that I don't know exactly how secure they are. It looks like they're at least as secure as Http and other transmissions.
> > Security has been a major concern, perhaps the major concern in development of the standard. Quite frankly, I can see no other reason except security concerns that such a standard took years to create. I'm quite confident that security is the reason this hadn't been done years ago.
> > The has been lots of open review and people looking for ways to hack. A security issue did arise in one of the earlier drafts of the standard and they fixed it. There are extra requirements for communication from browsers to avoid hijacking - which was the big security issue that was fixed in version 7 of the draft standard. For non-browser communication, developers are allowed to be slightly more relaxed and it's up to server developers to take advantage of some of the security features. On the other hand, they're also allowed to implement additional security schemes within their own client-server designs that wouldn't be available in browser communication.
> > If I'm not mistaken, your reference to issues with Ajax toolkits has to do with cross-site-scripting / hijacking. The WebSocket standard development group has announced that they're satisfied that the problem has been fixed as far as the WebSocket standard is concerned. It's up to server developers to ensure that the security measures are all completely implemented. In browser communication, most of them can't be avoided. But it appears absolutely certain to me that implementing all the security features properly is the way to go.
> > Yes, you can encrypt data. There are two new prefixes to be used in place of http:// in the websocket address; ws:// for non-encrypted communication and wss:// for encrypted. Default ports 80 and 443 apply to each.
> > ________________________________
> > FrÃ¥n: Pranav Lal<pranav.lal@...>
> > Till: email@example.com
> > Skickat: torsdag, 8 september 2011 3:29
> > Ãmne: RE: [svg-developers] Websockets, explained
> > Roger,
> > How secure are websockets? I believe there were security issues with Ajax
> > toolkits? Can the communication between the browser and server be encrypted?
> > Pranav
> > -----Original Message-----
> > From: firstname.lastname@example.org [mailto:email@example.com]
> > On Behalf Of Roger F. Gay
> > Sent: Wednesday, September 07, 2011 3:58 PM
> > To: firstname.lastname@example.org
> > Subject: [svg-developers] Websockets, explained
> > specification. It's the next big leap in interaction between browsers and
> > "back-end" (server side) processes.
> > If you've been around long enough, you may remember the olden days when you
> > clicked and then had to wait until the response came back. Your browser was
> > locked until it did. In fact, if there was a problem, your browser could
> > just get locked up and you'd have to restart it. While that got smoother,
> > "asynchronous" request-response (supported by Ajax) came along so there was
> > no longer any need for the browser to wait for a response. Using this
> > technology, you can continue about your business instead of coming to a
> > standstill after a request is made. The browser doesn't lock up when the
> > request is sent. It will react whenever the response shows up.
> > WebSockets are the next big jump in this evolution. Their application in the
> > client-browser is like Ajax, only easier and more powerful. Just a few lines
> > communication between the browser and the server. By "bi-directional" I
> > don't mean request-response. It's true bi-directional communication. (Since
> > request-response is "bi-directional" (with limited characteristics), perhaps
> > I would have chosen a different term to make the distinction. But this is
> > what you'll find in descriptions and tutorials everywhere else.)
> > THE SERVER CAN SEND DATA TO THE BROWSER ANYTIME THE APPLICATION PROCESSES
> > TELL IT TO. It isn't limited to servicing requests from the client. The
> > connection isn't closed when a response is made. It remains active for
> > two-way communication until one side or the other closes it. (Which happens
> > automatically when you close the page tab or browser, for example.)
> > IT'S A HUGE OPPORTUNITY for everyone involved in web development, whether on
> > the browser side or server side, or both; to completely rethink the web-page
> > experience. The change-over to WebSockets is going to be more "disruptive"
> > than the change to Ajax. Ajax made old-fashioned point-and-click
> > request-response web functions (which I do not expect to go away completely)
> > a much better experience. WebSockets provide the opportunity to easily turn
> > browsers into full-fledged application interfaces. It becomes practical to
> > deliver any application through the browser. It doesn't just make the
> > webpage experience better, it makes it different.
> > What about Ajax: Obsolete? I would still use Ajax in applications that are
> > limited to point-and-click request-response. Why not? It's good technology.
> > You can however, get the same effect with WebSockets. Neither end requires a
> > response except when making the initial connection. Everything from there is
> > inherently asynchronous. If you expect a larger number of interactions while
> > a user sits on one page (searching through and listening to music samples
> > for example) WebSockets offer the more efficient way to go. Once the
> > connection is established, the overhead of communication is less, so it's
> > faster and more economical for the Internet as a whole.
> [Non-text portions of this message have been removed]