The new MultipleMessagesPerPoll mode added to PollingDuplex in Silverlight 4, comes with some new timeouts , so I thought it would be useful to post a detailed description of how those work. Unfortunately this is not currently covered by our documentation, which is something we are looking to address in upcoming documentation refreshes.
This is a fairly advanced topic, and the default settings should work well for most customers, so only modify these if you are encountering an issue, and you are fairly confident a timeout is causing the problem. The information below applies only to the new multiple messages mode, which is activated by setting duplexMode="MultipleMessagesPerPoll" on the PollingDuplex binding or binding element.
One important thing in the text below is to differentiate between infrastructure messages (such as polls in this case) and application messages. Infrastructure messages such as polls (and poll responses) are not initiated by or surfaced to the user – they are just an implementation detail of the protocol. Application messages are messages that actually originated in the user code. They can be separated into client-to-server messages (“requests coming from client”) or server-to-client messages (“server responses to requests coming from client” and “requests coming from server”). There is no “client responses coming from server” because of the way polling works. I will try to stick to this terminology in the text below.
Most of the new timeouts live on the server. All class and member names refer to the server-side System.ServiceModel.PollingDuplex.dll that ships in the “Server” folder of the Silverlight SDK. Take a look at the following diagram for a visual explanation:
The diagram shows an incoming poll and the chunked response being returned containing application messages. The first server-to-client application message is greater than 16/32KB (16 for self-hosted PollingDuplex services, 32KB for IIS-hosted), so the chunked response is flushed and the message should arrive immediately at the client. The then client sends a smaller application messages, but the total size does not reach 16/32KB, so the chunked response is not flushed. To prevent the message from getting stuck, the chunked response will be flushed and closed when the MaxOutputDelay timer expires, and the message will then be delivered to the client. Then the client sends two application messages coming in from the client and the timeouts associated with those.
Here is a more detailed description of each timeout.
On the client side, we also have some timeouts that may be of interest. All class and member names below refer to the client-side System.ServiceModel.PollingDuplex.dll that ships in the “Client” folder of the Silverlight SDK.
Hope this is useful.
-Yavor Georgiev Program Manager, WCF