Реализация кометы для ASP.NET? [закрыто]

Я искал способы реализовать gmail-подобный обмен сообщениями внутри браузера и пришел к концепции Comet . Однако мне не удалось найти хорошую реализацию .NET, которая позволила бы мне сделать это в IIS (наше приложение написано на ASP.NET 2.0).

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

Итак, мой вопрос: знаете ли вы о реализации ASP.NET для Comet, которая работает по-другому? Возможно ли это даже с IIS?

Комету сложно масштабировать с помощью IIS из-за постоянного подключения кометы, но сейчас есть команда, изучающая сценарии кометы. Также посмотрите блог Аарона Лерха, поскольку я считаю, что он проделал некоторую раннюю работу с Comet в ASP.NET.

WebSync - это совместимый со стандартами масштабируемый сервер Comet, который интегрируется непосредственно в конвейер IIS / .NET. Он также доступен по запросу как размещенная услуга.

Официально он поддерживает до 20 000 одновременных клиентских подключений на серверный узел, но отдельные тесты показали, что оно достигает 50 000. Пропускная способность сообщений оптимальна на отметке от 1 000 до 5 000 одновременных клиентов, при этом сообщения доставляются со скоростью 300 000 в секунду с одного узла.

Он включает клиентскую поддержку JavaScript, .NET / Mono, iOS, Mac OS X, Java, Silverlight, Windows Phone, Windows Runtime и .NET Compact, а также серверную поддержку .NET / Mono и PHP.

Кластеризация поддерживается с использованием SQL Server или кэширования Azure из коробки, но настраиваемые поставщики могут быть написаны практически для чего угодно (Redis, NCache).

Отказ от ответственности: я работаю в компании, которая разрабатывает этот продукт.

Недавно я написал простой пример сервера чата с длительным опросом, использующего асинхронные контроллеры MVC 3, на основе отличной статьи Клея Ленхарта.

Вы можете использовать этот пример для развертывания AppHarbor, которое я настроил на основе источника из проекта BitBucket.

Кроме того, дополнительная информация доступна в моем сообщении в блоге, объясняющем проект .

На самом деле есть много вариантов создания веб-сайта с поддержкой ajax с помощью ASP.NET, но, честно говоря, PokeIn - это самый простой способ создать веб-приложение с поддержкой ajax кометы. Он сохранил один из проектов моей компании.

Вы также можете взглянуть на Kaazing Enterprise Gateway, который выпустил производственный выпуск своего шлюза webSocket [HTML5], который полностью заменяет путь кометы и обеспечивает полнодуплексные соединения между браузерами и серверами приложений.

Вы также можете посмотреть демоверсии Light Streamer

Однажды я давно использовал сайт чата, который использовал специально построенный сервер потоковой передачи http. Я фактически воспроизвел это программное обеспечение однажды из чистого любопытства, и я думаю, что это достаточно легко сделать. Я бы никогда не попытался реализовать подобный тип «бесконечного запроса» в IIS, особенно в ASP.NET, потому что запросы связывают поток пула потоков (или поток ввода-вывода, если используются асинхронные обработчики) на неопределенное время, что означает, что вы можете только обрабатывать столько на сервер, сколько позволяет конфигурация пула потоков.

Если бы у меня была серьезная законная потребность в такой функциональности, я бы честно написал для нее собственный http-сервер.

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

Группа WS-I опубликовала нечто под названием «Надежный безопасный профиль», в котором есть реализация Glass Fish и .NET, которые, по - видимому, хорошо взаимодействуют .

Если повезет, есть и реализация Javascript .

Также существует реализация Silverlight, использующая дуплексный режим HTTP. Вы можете подключить javascript к объекту Silverlight, чтобы получать обратные вызовы при возникновении push.

Есть также платные коммерческие версии .

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