![]() Today, virtually every modern browser has full support for WebSockets. ![]() ![]() The WebSocket protocol (RFC 6455) was published to the IETF website in 2011. In 2010, Google Chrome 4 became the first browser to ship its support for WebSockets, with other browsers following soon after. Following collaboration on the W3C mailing list and Internet Relay Chat (IRC), the duo came up with a plan to introduce a new standard for modern, real-time, bi-directional communication on the web- and coined the name ‘WebSockets.’ The idea eventually found its way to the W3C HTML standard, after which Michael Carter introduced the comet community to WebSockets in an article. There was no solution with TCP/IP socket-style capabilities in a web environment that could address all concerns associated with operating in a web environment.Īround the mid-2008, the restrictions and pain of implementations using long-standing HTTP connections was felt particularly by two developers Ian Hickson and Michael Carter. It was attained by hacking available web technologies that were not primarily built for real-time applications. This preceding ‘real-time’ web was typically slower and hard to achieve. It's solid and easy to use.WebSockets have been around for over a decade now, but the real-time web existed long before they came. Watch this space!īy the way, if you do plan on writing some WebSocket implementation code I highly recommend Sockette. The experiment app does collect everyone's results (just the timings and IP) and I hope to find the time to process this and build graph a correlating the geographical distance compared to the difference between the two techniques. Keep building cool stuff with WebSockets but if you expect one result per action, XHR is good enough. In summary, don't bother just to get a single-digit percentage performance increase if the complexity of the code and infrastructure is non-trivial. ![]() There's nothing wrong with WebSocket and it has its brilliant use cases. They shine in their ability to actively await results without having a loop that periodically pulls. Things like that need to be fast and "snappy". At almost every keystroke, you send it to the server and as search results come in, you update the search result display. My original thought was to use WebSockets instead of XHR for an autocomplete widget. However, suppose you do have all your potential clients physically near the server, it might be beneficial to use WebSockets. Not the time it takes the browser (or the server) to process it. If you're far away a large majority of the total time is sending and receiving the data. Or rather, the distance the bytes have to travel. No matter how fancy you're trying to be, what matters is the path the bytes have to travel. The technique, for the benefit of performance, doesn't matter much. I don't have a screenshot for it but a friend of mine ran this from his location in Perth, Australia. Now, when I run the whole experiment all on my laptop the results look very different: My result between South Carolina, USA and New York, USA What you'll find is that the closer you are to the server (lower latency) the better WebSocket performs. The server used in this experiment is in New York, USA. What matters is the geographical distance between you and the server. (Just press "Start!", wait and press it 2 or 3 more times) Location, location, location So the browser keeps sending the number back to the server that decrements it and when the server returns 0 the loop ends and you look how long the whole thing took. # Inside app.py # from the the GET querystring "?count=123" count = self.
0 Comments
Leave a Reply. |