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 <drc...@drclue.net> Till: svg-developers@yahoogroups.com 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. --Doc 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....@gmail.com> > Till: svg-developers@yahoogroups.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: svg-developers@yahoogroups.com [mailto:svg-developers@yahoogroups.com] > On Behalf Of Roger F. Gay > Sent: Wednesday, September 07, 2011 3:58 PM > To: svg-developers@yahoogroups.com > Subject: [svg-developers] Websockets, explained > > Browser / JavaScript support for WebSockets is part of the HTML5 > 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 > of JavaScript code (easier than Ajax) and you have bi-directional > 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] ------------------------------------ ----- To unsubscribe send a message to: svg-developers-unsubscr...@yahoogroups.com -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: svg-developers-dig...@yahoogroups.com svg-developers-fullfeatu...@yahoogroups.com <*> To unsubscribe from this group, send an email to: svg-developers-unsubscr...@yahoogroups.com <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
