Hot answers tagged

172

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 ...


105

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 your 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 ...


79

Polling refers to repeatedly checking whether a resource (any kind of resource) is ready. A spinlock is when the resource you are polling is a lock. Note that polling is not bad. In particular, polling is efficient when there is usually data ready when you poll. Polling is only inefficient if you do it without then getting any data in return. On the other ...


39

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 ...


29

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 ...


10

A spinlock is a type of lock, specifically, one achieved via polling. Polling is a method of checking the status of something (by asking for the status, as opposed to waiting to be told the status). Not all polling is a spinlock, for example, polling the status of keyboard keys. Also, polling isn't inherently bad. Very short periods of polling can avoid ...


10

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 ...


9

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 ...


7

Is there a forumla, or generally accepted approach? There is no formula. Averaging will not work reliably. If an update happens on Sunday and the client polls on Mondays, its data is only one day out of date. If the next update happens on Tuesday, the data will be out of date until the following Monday's poll. The generally-accepted approach is to ...


5

Spinlock is different from polling because it only occurs for a very short period of time, on the order of a few milliseconds or less. Polling can go on indefinitely. In parallel programming, a brief episode of spinning is often preferable to blocking, as it avoids the cost of context switching and kernel transitions. Further Reading SpinLock and SpinWait ...


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 ...


4

You want a connection pool - 100 clients will be throttled to using a pool of a handful of DB connections so your DB will not get overloaded responding to many simultaneous requests. You could try to optimise the calls but you will still need to allow the clients to access the DB through a mechanism identical to a connection pool, even if there is just 1 ...


4

The difference is that a spinlock is (hopefully) only used in situations where it is appropriate, and in these situations it is very efficient. You use a spinlock if you expect that a resource will only be locked for a very short time - for example if a lock is only used to update a variable. The spinlock polls the lock at maximum speed, but hopefully for ...


4

Actually, I think you've got it backwards. At the low level of the internet, there is no such thing as polling. Everything on the internet actually pushes. Internet messages are made of packets, which are basically bunches of electrons travelling down wires. From the computer's perspective, packets simply show up either as electrons coming down a wire or ...


3

I would Check Availability on Failed Action. Just issue your calls normally and if you get a failure, then call the Service Availability function to verify. Assume service is up, if one gets and error, then issue the additional call to verify availability.


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 ...


2

Excessive polling is something you should not do because it wastes system resources. It follows that polling is fine if it doesn't waste system resources. For example excessive polling will get CPU load to 100% in cases where the actual work would only result in a 2% load. Polling can be used for other things than while(!ready). For example it means ...


1

Ideally you should be pushing to your websocket (through a http request or any queue mechanism as mentioned in the other answers) server at the time the writes happen to the database. That way you can completely avoid polling the database. If you have no other go but to use the database, then execute one query which will get the information for all the ...


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

Web Sockets are the better choice The problem with constant polling is that, much like sending small bursts of data (which it pretty much amounts to), your device goes into an 'idle' state that it has to 'wake up' from in between polls. There is a high cost associated with making the initial connection and this cost is repeated for every poll you perform. ...


1

It happens to be that service is your resource and for some reason it may not be available. What would you do if your client application talks directly to the database. Would you check availability of the database before trying to query it? I would not. I think service not being available is an exceptional circumstance. I would expect my service to be ...


1

Just because a http-ping at time t gets a response, you've still got a large uncertainty that a request at time t' will complete. I suggest you not ping the server if it can be avoided because it is a poor proxy measure of actual availability in the future. If a request is made and no response is received, retry with an exponential back-off interval.


1

Another option is not to poll at all, but to implement a caching solution where, when a request comes in to your API, you use a cached value if you have one that's recent enough, otherwise you update your cache with a call to the external API.


1

If you have control over any of the apis, and for your own api if you are expecting the browser to display "live" updates, you may want to consider implementing "long polling", also known as "comet". In long polling, whena request is made, the server checks to see if anything has changed since the client last polled (it can be helpful if the client includes ...


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

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 ...



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