How does long polling ACTUALLY invoke callback on client?

Question

The client initiating long polling, calls a method on server and passes in an instance of AsyncCallback which contains the callback delegate which will be invoked when server asynchronously gets back to the client.

Now my understanding on this is limited but it appears that in BasicHttp WCF the AsyncCallback parameter is serialised and sent to server which then de-serialises it, caches it and ultimately invokes it to "get back" to the client.

Firstly, is the above explanation correct? Secondly, how does the AsyncCallback invoked on a client all the way across network?

Answer 1

The connection is kept open so the server responds over the existing connection, including the callback handler name in the response.

The client understands the format of the message and can then invoke the appropriate local method (based on the callback handler) with the data from the server response.

I usually prefer not to quote Wikipedia but in this instance, it's not a bad explanation of long polling...

Long polling is a variation of the traditional polling technique and allows emulation of an information push from a server to a client. With long polling, the client requests information from the server in a similar way to a normal poll. However, if the server does not have any information available for the client, instead of sending an empty response, the server holds the request and waits for some information to be available. Once the information becomes available (or after a suitable timeout), a complete response is sent to the client. The client will normally then immediately re-request information from the server, so that the server will almost always have an available waiting request that it can use to deliver data in response to an event. In a web/AJAX context, long polling is also known as Comet programming.

Clarification

• The client sends a POST to the server, including a callback handle and keeps the connection open
• A length of time later, the server responds with the callback handle from the POST and the response data (This happens when you call the AsyncCallback's methods on the server)
• The Client reads the response from the server, identifies the callback handle that has been returned and uses that to identify which method to execute,
• The client executes the method specified by the callback handle and passes in the rest of the server response.

This is similar to the way JSONP works (The callback part, not long polling), if you're familiar with that? Essentially, the Callback handle is only passed to the server so that it can be sent back with the response and allow the client to call the correct method.

There are additional checks going on under the hood to make sure that only the intended methods are called and a malicious server can't just execute any method it chooses in client code.

Answer 2

@Basic's answer is very good, but I'm feeling like writing a description that hopefully is easier to understand for some people.

1. Your code calls a method in a local class representing the webmethods on a server
2. That local class, makes a connection to the server, and puts that connection into an object along with a reference to the AsyncCallback passed in
3. That object containing the information is put into the background, with some sort of trigger in it to know when a response has been received
4. In the meantime the main thread gets returned to go onto process whatever it wants
5. Once the server has responded (in the case of long polling it will wait a while before returning a false response) the object is pulled up and the AsyncCallback is called with the information

So it really the framework (on the client side still) waiting for the response that is the async part. The TCP connection and server processing is all standard (other than the waiting to respond in the case of nothing to return for long polling)

This should describe the basic process for any async web requests in any language, be it long polling, downloading images, etc.