Масштабируемость LongPolling в .Net: Grand Finale

Question

Я провел исследование о том, как реализовать кометоподобный чат на asp.net / MVC. я обнаружил, что это может сделать Лонг Поллинг ..

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

Теперь инструменты для бизнеса: Pokein, SignalR, SocketIO, Now.Js (Пропуск платных инструментов, бесплатно это довольно :)) насколько я знаю, что все они используют длинные опросы, то что они на самом деле делают для улучшения производительности в IIS (все это можно использовать с asp.net) ..

Я также обнаружил, что Facebook использует Erlang (не знаю, как его использовать), чтобы реализовать это, и, конечно, стоит оборудования на 100 миллионов долларов (баланс 70 миллионов пользователей). и FB использует длинный опрос, а не какой-нибудь комет-сервер (насколько мне известно).

Я хочу реализовать масштабируемый длинный опрос на asp.net MVC 3 я нашел два финала: Здесь и здесь

Все, что я хочу знать, что лучше и почему .. а также какой инструмент лучше среди приведенных

Answer 1

Мое мнение таково, что SignalR будет лучшим выбором, хотя бы потому, что если вы используете SignalR.WebSockets , он автоматически обновит подключение к веб-сокетам, если пользовательбраузер поддерживает это.Таким образом, со временем, когда пользователи начнут обновлять браузеры и отказаться от схемы длинных опросов, масштабируемость вашего чат-приложения станет на самом деле лучше.

Более того, есть замечательный пример кода, называемый JabbR,созданный теми самыми людьми, которые создали SignalR. (которые также являются разработчиками в команде ASP .NET)

http://jabbr.net/ - пример SignalR в действии.https://github.com/davidfowl/JabbR - источник JabbR.

Answer 2

Хотя вы отметили ответ, я испытываю желание дать этот ответ, поскольку я прошел через это и в течение долгого времени.

Я использовал решения двух крупных игроков COMET. Один - websync, а другой - PokeIn. Веб-синхронизация была хорошей, но дорогой. У меня было много проблем с PokeIn с точки зрения его успешного использования. На самом деле я использовал это не для сервера чата, а для оперативного обновления, когда какая-то внешняя программа отправляет / отправляет обновления подписанным клиентам.

Я предлагаю вам попробовать использовать логику на основе IHttpAsyncHandler. Это снова метод с длительным опросом, но клиент возвращается после отправки запроса, и сервер может отправить ответ асинхронно.

Извините за саморекламу. У меня есть пример реализации этого в проекте с именем flycomet в codeplex. Это просто имеет обработчик, который получает запросы и в зависимости от типа запроса отвечает с ответами, если таковые имеются.

В настоящее время реализация представлена ​​не как сервер чата, а как консольное клиентское приложение Windows, и подписчики могут быть из asp .net или MVC или silverlight. Преимущество в том, что вы можете настроить код для масштабирования для себя.

Если вы хотите изменить это как приложение для чата, довольно просто протолкнуть данные через jQuery.