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

Реализация этой технологии, как не сложно догадаться, основывается на JavaScript. Основной идеей является поддержание долговременных HTTP-соединений с каждым клиентом приложения и отправка новых данных клиентам с их помощью как только произошло их обновление или возникновение на сервере. Этот принцип послужил основой для альтернативных названий этой технологии: Server-push, Reverse AJAX. В случае классического AJAX (о котором тоже стоило бы сначала написать статейку, потом может быть соберусь) клиент асинхронно отправляет серверу запрос на получение какой-либо конкретной информации. В Comet же клиент с сервером как бы меняются ролями: инициатором передачи информации является сервер, а не клиент. Что же это меняет? Самым наглядным примером послужит реализация постоянного обновления какой-либо информации в реальном времени:

• Классическая модель отправки запросов. Для решения задачи понадобится постоянно обновлять всю страницу целиком, вручную пользователем или альтернативными способами автоматически. Совсем не вариант, будет генерироваться огромное количество запросов к серверу, каждый из которых будет очень существеннен по объему. Большое количество одновременно работающих пользователей такое приложение явно не выдержит, да и доступность данных в реальном времени не обеспечит.
• AJAX. По сравнению с предыдущим вариантом AJAX предоставляет массу преимуществ: размер передаваемых данных существенно уменьшается, особенно если использовать в качестве формата данных не XML, а JSON. Но тем не менее необходимость регулярно отправлять запросы серверу для получения обновленной информации останется. С ростом количества пользователей будет расти и количество запросов, открытие и закрытие которых будет неуклонно генерировать нагрузку на сервер. Для снижения нагрузки можно попытаться увеличивать интервал между запросами, но это лишь временная мера, обладающая существенным недостатком — увеличение этого промежутка времени повлечет за собой рост задержек между обновлением информации на сервере и обновлением клиентской части приложения.
• Comet. С каждым клиентом поддерживается постоянное HTTP-соединение, как только данные на сервере обновились — сервер сразу же отправляет по уже открытому соединению уведомление о необходимости провести изменения в клиентской части, это позволяет существенно сократить нагрузку на сервер и практически избавиться от задержек между обновлением данных на сервере и клиенте.

Для написания серверной части приложения может использоваться практически любой язык программирования, наиболее распространенным решением, пожалуй, является Java Servlet, запущенный в каком-либо контейнере — Apache TomCat, Jetty или Sun GlassFish. Для реализации этого подхода к организации общения клиента с сервером написано достаточно большое количество framework’ов и библиотек, наиболее полный список, я думаю, можно найти в английской википедии.

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

Если Вас заинтересовала эта тема — могу посоветовать взглянуть на пару достаточно интересных статей, в котором более с практической точки зрения описывается этот подход к построению приложений:

• Создание масштабируемых Comet-приложений с использованием Jetty и Direct Web Remoting
• Asynchronous HTTP and Comet Architecture (eng.)

Я же надеюсь написать статью более практической на направленности по этой теме лишь в обозримом будущем, не пропустить этот момент Вам поможет абонемент.