Tag Info

Hot answers tagged

153

Pushing works well for 1, or a limited number of users. Now change the scenario with one photographer and 1000 users that all want a copy of the picture. The photographer will have to walk to 1000 piles. Some of them might be in locked office, or spread all over the floor. Or their user on vacation, and not interested in new pictures at the moment. The ...


81

I'm really surprised that only one person has mentioned WebSockets. Support is implemented in basically every major browser. In fact PubNub uses them. For you application the browser would probably subscribe to a socket that would broadcast whenever a new photo is available. The socket wouldn't send the photo, mind you, but just a link so the browser could ...


30

Sometimes good enough is good enough. Of all the possible ways to implement a "real-time" communications process, polling is perhaps the simplest way. Polling can be used effectively when the polling interval is relatively long (i.e. seconds, minutes or hours rather than instantaneous), and the clock cycles consumed by checking the connection or resource ...


27

The HTTP protocol is limited in that the client MUST be the one to initiate the request. The server cannot communicate with the client unless responding to a client's request. So to adjust your real world example, add the following restraint: User 2 can ONLY respond to User 1's questions with a single sentence reply, after which User 1 must leave. User 2 ...


11

You were correct the first time, polling is the correct term to use in this situation. Whether you are polling at 1 mHz or at 1 MHz, it is still polling. Note milli Hertz is not a unit I've ever see used, a poll rate of once every million seconds (11.6 days) having limited use. *8') From the wikipedia polling page: Polling, or polled operation, in ...


8

Polling is always acceptable when real-time isn't a necessity. What you have to ask yourself is why would you use one instead of the other? The purpose of a push service is a couple things; it can be considerably less traffic for you to deal with if your pushes are broadcasts and a 3rd party provider does the broadcast - this allows you to send one message ...


8

One advantage of polling is that it limits the harm that can be caused if a message goes missing or the state of something gets glitched. If X asks Y for its state once every five seconds, then the loss of a request or a reply will merely result in X's information being ten seconds out of date rather than 5. If Y gets rebooted, X can find out about it the ...


8

Immediately show some feedback: change the visual state of button, display an animated throbber. If the app logic allows, disable the button once it has been pressed, enable it back when the answer arrives. Once the answer has arrived, show the real feedback: update the controls, remove the throbber.


7

This is a bit of a "which is better, fish or the colour orange" type of question, but in terms of the general behaviour of JavaScript, and particularly the more functional side of it's nature it is probably more idiomatic to use events to react to changes of state than it is to have a timed polling system. It is a lot more flexible and less confusing to be ...


5

Why is polling accepted? Because in reality every solution is actually low-level polling! If the server should update you as soon as new pictures are available, it usually has to have a connection to you - because IP addresses change often and you never know if someone isn't interested anymore, so the client has to send some form of keep-alive signal, for ...


4

If the server can give a rough estimate of how long a job will take, then I would return that estimate in the first response (the one indicating that the job was received/accepted). The client can then wait at least that time before it starts polling for results. To avoid flooding a server with unsuccessful polling requests, you might also use a scheme that ...


2

This really depends on how much time it takes on average to perform the job and the standard deviation of this time. Once you know this, you have a good idea about what your minimum and maximum waiting times are for 95% of jobs (2 standard deviations). So I would plan for a minimum polling time somewhere in the vicinity of 2 standard deviation (so that ...


1

From your question and the comments to other answers already given, I feel like you're working on two things: 1) eliminating the middleman, 2) converting your poll-mechanism to a push-mechanism. I'd say, those can be viewed separately. Let's start with the poll-to-push change. In general, I'd say yes, pushing is superior to polling. If I understand your ...


1

The question is to balance the amount of unnecessary polls vs the amount of unnecessary pushes. If you poll: You get an answer at this very moment. Good if you ask only occasionally or need a data set this very moment. You might get a "no content" answer, causing pointless load on the line. You put load on the line only when you poll, but always when you ...


1

In general, my preference is to base the design on polling at fairly low frequency, but then to use events to trigger early scans. The good thing about events is responsiveness. There are a few bad things about them: They can happen more often than you want, as for example there may be 10 events in a row, early ones being overridden by later ones, and ...


1

Polling should be fine in your case. And you won't have to integrate with yet another system (or multiple systems for multiple platforms). Device specifics may be an issue, though. Can you reliably poll when the app isn't front and center on the device? (may or may not be an issue for you). Your ability to do so may depend on the techonolgy you are ...


1

Of course. It's also easier (just beware of pull spikes if everyone is pulling on the same schedule). That said, I would challenge the assumption that 'a large delay is acceptable', considering mobile users expectations. ('Maps are not updated in real time! Unacceptable!' - or - 'I know it's the weather service, but I'm going to keep pushing that refresh ...


1

An alternative option is to use something like long polling or websockets. This way you can replace slamming the server with multiple "is it done yet?" requests with a single "tell me when your done" request


1

One way of handling this is to use PubNub. It is a paid service, but well worth it since it basically handles the entire messaging portion of what you describe, and wouldn't have any scale issues. Its very easy to implement. The clients would connect to the service using long polling (if you roll your own) or one of their client libraries. Messages are ...


1

You might want to check out Comet or BOSH Which are two methods to simulate sockets over HTTP, they are way more efficient than polling, and technically could scale to the 10k if you use a light weight server such as Nginx which is alot better at handling concurent connections than apache. As for the server with more than 100 connections you could get a ...



Only top voted, non community-wiki answers of a minimum length are eligible