long-polling

问题 I have read many articles on real-time push notifications. And the resume is that websocket is generally the preferred technique as long as you are not concerned about 100% browser compatibility. And yet, one article states that Long polling - potentially when you are exchanging single call with server, and server is doing some work in background. This is exactly my case. The user presses a button which initiates some complex calculations on server-side, and as soon as the answer is ready,

问题 Hopefully I can explain this well enough. I am working on creating a PHP library to handle ajax requests through PHP in an object oriented manner. I am currently pondering a good way to implement a long polling solution but am curious about something. Apache doesn't handle keeping multiple connections open very well. The thread-per-request model makes Apache highly inefficient for long polling. Using server's such as nginx and lighttpd handle these threads much better so in the library, I

问题 I am implementing a system where I need real-time updates. I have been looking at certain scenarios and among all was Comet. Implementing this I do not see any way this is different from traditional long-polling. In both cases you have to send a request, and then the server send a response back. In the browser you interpret the response and then you start a new request. So why should I use comet if in both cases I need to open and close connections. 回答1: Some Comet techniques don't require

问题 I understand that SignalR is used to communicate with client browsers using the injected artery script. I have what seems to be a common problem, which is that my browser's network log is filled with entries that look like this: .../arterySignalR/poll?transport=longPolling&connectionToken=... This tells me that SignalR has fallen back to long polling instead of using web sockets. Assuming that we have a browser that supports web sockets, and that browser is running on the localhost, shouldn't

问题 I have a socket.io connection using xhr as its only transport. When I load up the app in the browser (tested in chrome and ff), the socket connects and everything works well until I navigate away from the page. If I reload the browser, I can see the 'disconnect' event get sent out by the client, but the server disconnect event doesn't fire for a very long time (presumably when the client heartbeat times out). This is a problem because I do some cleanup work in the server when the client

问题 I am using Firefox, but I'd like to know how browsers decide this in general. It seems that when I access the same URL twice in a short amount of time, my browser tries to re-use the TCP same connection for both requests (this is called keep-alive). However, when I access two different URLs (but still served by the same server ), the browser sometimes decides to open up a new connection for each request. Obviously, the browser does not use a one-connection-per-URL policy. I am asking this

问题 For interactive web apps, things like Websockets are getting more popular. However, as the client, and proxy world is not always fully compliant, one usually use a complex framework like 'Socket.IO', hiding several different mechanisms for any case that may disable the other ones. I just wonder what the downsides of a properly implemented long polling are, because with today's servers like node.js it is quite easy to implement and relies on old http technology which is well supported (despite

问题 Is it possible to take an HTTPServletRequest away from its thread, dissolve this thread (i.e. bring it back to the pool), but keep the underlying connection with the browser working, until I get the results from a time-consuming operation (say, processing an image)? When the return data are processed, another method should be called asynchronously, and be given the request as well as the data as parameters. Usually, long pooling functions in a pretty blocking fashion, where the current thread

问题 I know there are ways to fake it, polling (or long polling) but is there any way to have the server contact the browser to push out information? Either polling option wastes resources on the server and depending on the server can lock it up (apache and iis for example). Seems like a lot of sites are using long polling to fake a server-side push mechanism over http. Wouldn't it just be better to have a true push protocol built into a browser? What options are there that are server friendly to

问题 I have read this question but it doesn't exactly answer my question. Unfortunately, it looks like things have changed in in the XHR object since I last looked at AJAX, so it is no longer possible to directly access responseText before it is finished being populated. I have to write a page that uses AJAX (preferably jQuery, but I am open to suggestions) to retrieve CSV data via HTTP from a server I have no control over. The response data could be quite large; a megabyte of text is not uncommon