Question on update techniques (pooling,long pooling, SSE...ect)

[rover2341]

This is for learning purposes I don't have a project i am working on.

Lets suppose you have a webpage, that you want some graphs or data to update in real time, or worse case 5 sec per update (But doesn't hurt if its faster, user may be more happy) and would allow more options in the future.

Whats Important to me

• Simple (or Straight forward, less requirements)
• Works in all situations, assuming they can access a web page with a internet connection. (Meaning I don't want this to work for 50% of my users, at least 98%)
• Speed Is Nice, But not super important, the more speed the more flexibility I have.
• Flexible

What I Found


Pooling - Ajax request on a timer, that ask server for info and sends any info it needs.
The Best thing about this technique is its super simple requires no work on the server side.

Long Pooling - Ajax Request, but Server waits to return data to the user intill i has data ready to return. so keeps request open.
Requires some sever coding, to handle this, and ajax call in javascrpit. Faster then pooling, less requests sent, But if user wants to send data in, it needs to do it separately, from ajax call, else you would be waiting for the server to get its data ready before you can tell it you did something else.

SSE (Server Sent Events) Or a tech like this (Comet, forever frame) - users sends ajax request to server, and server gives data back when it wants, and never closes the msg. requires a ect coding on both sides. if user wants to send it needs to send it separately (I believe).
Faster, then long pooling, only one connection, to get data, aside from ect coding on both sides to handle this i read its often used for things like stocks.

Web Sockets - Fastest, requires coding and many requirements on both sides. In today's world you wont have 98% of your users working with this, as it can be blocked by many things including firewalls, or just not supported (cell phone, ect).

SignalR - Microsoft's support. Fairly new. It requires code on the server and ajax calls and javascrpit includes. But uses websockets, foreverFrame, seversentEvents, longpolling. it trys the fastest but then falls back on the next one if it fails. It handles channels and has a fuction class, that you can use. Makes it simple to send to who you want or everyone. But prehaps the most overhead and requirements.

I think this is what i want to use, for most things future... unless i find somthing better.
It may be over kill on some projects but as a project gets larger it makes more sense. Its pretty much the only way i can use websockets with out coding a fall back system my self. I read it still has some bugs in it, as its fairly new. (Another note: is i can use it to connect to my unity, wpf projects , windows phone projects quite easily as well. and the server side stays the same)

At work we are just using polling as its fast enoufe, and works.
But for my own projects unless pooling is more then fast enough, i think i would use signalR over any of the other methods. But I would like to know of other ways, and what you guys think, and what you would use your self.

What are some good techniques for doing this, and why?
why shouldnt i use SignalR?

I used this a one of my sources of info to understand ways of doing this. (and for the images)
http://stackoverflow.com/questions/...g-websockets-server-sent-events-sse-and-comet

 

[monoVertex]

SignalR is more of a framework, it seems, rather than a communication protocol, we should get the terms straight: a protocol is a method of communication, like the ones you described: polling, long polling, sockets. A framework is like SignalR. A library / collection of functions / whatever, which implements one or more protocols.

If you are asking which protocol to use, WebSockets is the way of the future for what you want, it's obviously the best protocol and this is what is used in network communication in similar instances as well. Sockets are generally a better way of communication when it comes to near real-time updates of some information, while the other protocols may be used in some special cases, when sockets are over kill.

However, WebSockets has horrible support at the moment, as you stated. In your case I'd go with polling, it's the easiest way to achieve what you want and it has reasonable speed, especially if you limit the number of requests per second / minute.

However, this is when talking about particular protocols. In a production project I would most certainly use a framework (like SignalR) and I am convinced that SignalR is not the only one on the market. I would use a framework because they generally have communities and are more robust than whatever I could scrape up. I am not quite fond of Microsoft frameworks (it's enough to take a look at the MS file system API to be horrified), so I'd rather search for alternatives.

At the moment I'm a bit pressed by time so I can't search for an alternative to suggest, but the base line is this: If you want to learn about the various protocols, implement WebSocket yourself with a polling fallback. If you want to make a professional project which is fast and flexible, use a framework. In case you don't find any other framework, use SignalR.

 

[rover2341]

First off thanks for the clarification on things.

SignalR is more of a framework. A library / collection of functions / whatever, which implements one or more protocols.
Protocol is a method of communication, polling, long polling, sockets ect.

WebSockets is the way of the future for what you want

Ok, Cool I wasnt sure if in the next 3-7 years it was going to just be that option that existed that is not really supported enoufe on phones, or have to many issues with antivirus or broswers (even though its in the html5 specs, that broswers plan to add) to become somthing that would be relieable enoufe to use in production and hit most users. But as you agreed its not ready to be the only way the user gets data today. But its my imperssion from you that at some point the future this will become much more standard, across all major broswers and phones.

However, WebSockets has horrible support at the moment

Good to know, and makes sense.

In your case I'd go with polling, it's the easiest way to achieve what you want and it has reasonable speed, especially if you limit the number of requests per second / minute.

Well I can agree, that its super simple to do this, and makes the most sense.

However, this is when talking about particular protocols. In a production project I would most certainly use a framework.

Ah. makes sense, if you were to attempt to do more then one protcol, its best to use somthing many people have used and viewed. I assume thats what you mean. Or do you mean you would use a framework even if using a single Protocol? I Imagine it may be helpful when using webSockets even if all the framework used was webSockets as Its my impression there a bit more involed.

I am not quite fond of Microsoft frameworks

I figured this was coming . But I am to new of a programer to have experinced many of the other programering languages and frameworks. But I venture out more soon.

so I'd rather search for alternatives (Other then singalR)

K, Ill check some out, in a phone project we didnt want to host the msg sending, or build anything up from scratch so we used a paid service that had there own protcol, but for us was free as we had less then 100 concurrrent users. We used photon. But my younger brother did the coding for that. It took him quite a while to get it working just right, with our project, but that was a application not a webpage, but Pretty sure it can be used with html as well.

So far I have had pretty good luck with singalR, but I would imagine there are other more mature things out there. So i will look around. I dont care to know everything about every option, but it would be nice to at least look at a few before i dive into learning and practiceing one.

If you want to learn about the various protocols, implement WebSocket yourself with a polling fallback.

I will, I want to learn about this as much as i can, with out going to deep as i have many things i would like to learn. As its one thing to make somthing work, and another thing to have idea of what your doing.

I am planing on reading though this to get a better idea of packets. http://www.amazon.com/gp/product/0596002971/ref=oh_details_o00_s00_i02?ie=UTF8&psc=1 But i know thats quite a bit differnt then request, but prehaps it will relate to webSockets. (Still learning likey have many terms off) (Also I cant start reading that book till i finsh my "Mircosoft" books. on asp.net and mvc. more then 50% done but still 700 pages to go. (may also read this http://www.amazon.com/Definitive-Gu...TF8&qid=1389897450&sr=1-2&keywords=websockets)

If you want to make a professional project which is fast and flexible, use a framework.

Great so it sounds like i am on the right track.




Really Appericate it man. Very helpful to me. Ill work on keeping my terms more stright in the future.

 

[monoVertex]

Ah. makes sense, if you were to attempt to do more then one protcol, its best to use somthing many people have used and viewed. I assume thats what you mean. Or do you mean you would use a framework even if using a single Protocol? I Imagine it may be helpful when using webSockets even if all the framework used was webSockets as Its my impression there a bit more involed.

Generally, in a professional project, if you can find a robust framework with good support and documentation, it's faster and easier to just use it, regardless if they implement a single protocol or more than one (applicable to anything else besides communication protocols).

Of course, if it's a complex subject, there might be a learning curve (take Backbone.js for example), good practices, specific techniques and so on. And again, I re-iterate: robust, good support and documentation. If it's a shaky framework, you're better off implementing it yourself, if you can't find a replacement.

There also comes the time when you can't find something for your specific needs so then you either expand an open-source framework or create your own, but that's not applicable here.

So in this case, even polling might need some minimal framework, but web sockets definitely needs a framework, both for working with them and for fallback.

However, when you want to learn, implement things yourself.

As for web sockets, it has bad support at the moment because it's something new. The HTML specification wasn't originally built with things like web sockets or web workers (parallel computing) in mind, so HTML5 is bringing some new, really tricky and complex stuff to web development and we have to wait for the browser devs to step their game up.

On one hand, it's bad that they use the HTML specification for it, web workers for example are a bit cumbersome to work with (no idea about web sockets, didn't try my hand at them yet). On the other hand, it's nice that we at least have a glimpse that in the future we might be able to use them.