How does long polling ACTUALLY invoke callback on client?

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?

Solution

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.