StreamedResponse с дуплексом опроса Silverlight 4 не отправляет обновления

Question

Я пытаюсь включить потоковый ответ, используя Silverlight 4 и опрос дуплекса, но я получаю странное поведение, когда частота отправки обновлений клиенту выше, чем maxOutputDelay, что приводит к тому, что обновления не отправляются.

Например, при maxOutputDelay 7 секунд и 1 обновлении, отправляемом каждые 10 секунд, все работает нормально.Но если у меня maxOutputDelay 1 секунда, а обновление отправляется каждые 500 миллисекунд, обновления просто располагаются на стороне сервера и не отправляются клиенту.

Насколько я понимаю, настройка TransferMode = "StreamedResponse "должен немедленно отправлять обновления клиенту, но, похоже, это не работает.

Вот привязка в моем Web.config для веб-службы:

Этот конфиг основан на информации из этой статьи: http://blogs.msdn.com/b/silverlightws/archive/2010/06/25/http-duplex-improvements-silverlight-4.aspx

Спасибо.

Answer 1

Если вы не полностью сконцентрированы на использовании дуплексных каналов (которые сложно настроить при любом сценарии, кроме сценария с одним хостом), возможно, стоит попробовать альтернативные решения для реализации обратных вызовов сервера - даже если это означает, что вам необходимо поддерживатьдва разных типа подключения к вашему бэкэнду.

Варианты дуплексного канала:

• PokeIn
• Kaazing WebSocket Gateway

Answer 2

Я думаю, что эта статья отвечает на вопрос:

http://blogs.msdn.com/b/silverlightws/archive/2010/07/16/pollingduplex-multiple-mode-timeouts-demystified.aspx

maxOutputDelay больше похож на таймер внутри сообщения. Поэтому, если ваша скорость сообщения превышает эту задержку, вы никогда не будете запускать очистку до тех пор, пока буфер не заполнится. Он сбрасывается при каждом новом сообщении, добавленном в очередь. Поэтому, я думаю, нам нужно настроить размер очереди и этот таймер для достижения максимальной фактической задержки.

Я не уверен, почему потоковый ответ все еще буферизуется, но я его тоже вижу. Кто-нибудь знает, как настроить этот размер буфера?

[Изменено] Хорошо, в этой статье говорится, что мы не можем контролировать буферизацию в поточном ответе (это 16 Кбайт в автономном режиме и 32 КБ в IIS) Таким образом, учитывая, что небольшие сообщения, поступающие со скоростью, превышающей вашу максимальную задержку, являются патологическим случаем. Может быть, я должен дополнить их данными ...

http://blogs.msdn.com/b/silverlightws/archive/2010/06/25/http-duplex-improvements-silverlight-4.aspx