Третий день воюю с Comet, но устраивающего меня варианта так и не получил.
Сервер - с NIO протоколом, то есть де-факто поддерживающий эту технологию (Tomcat 6). При инициализации с клиента запускается трид и каждые N секунд отдает клиенту строку со временем.

Вариант 1. Единственный, который работает, но мне не нравится как.
есть линк с target="my_iframe" и iframe, который и должен получать ответ сервера. Он ответ получает и время выводит постоянно, но страница находится постоянно в стадии получения данных, то есть в ИЕ на закладке крутится кольцо и в строке статуса строка, которая извещает, что идет получение данных с сервера.
iframe как раз и нужен нам, чтобы можно было на него повесить взаимодействие с сервером и скрыть всю "жизнедеятельность" от посторонних глаз. Почему он не забирает на себя все это???

Вариант 2. Использование request.readyState == 3. Идеальная технология для Комета и чудненько работает в ФФ. Но ИЕ не имеет доступа к response пока не получит статус 4!!! Вроде сталкивался, что вопрос как-то решен, но где и как - не нашел. Возможно, кто-то слышал или знает что и как делать.

Вариант 3. Использование протокола Bayeux - интересная реализация, специфицированная dojo и в основном работающая "под маркой Комет". Есть даже jquery.comet.js для работы с ней. Но не могу найти доки в инете, где можно было бы нормально разобраться. Есть даже исходники чата на нем (html + реализация сервера) - с релизом Jetty 6.1.15 (последний), но что-то у меня не складывается с этим Jetty. Возможно, кто-то сталкивался и подскаже направление.

Вариант 4. Если сегодня до ночи не получится разобраться, то прийдется пользоваться им - делать на флеше и из флеша управлять элементами на странице. Очень действенно, но как-то слегонца некошерно ... Причем, можно использовать как сокеты, так и уже готовую реализацию Comet.

Моим большим заблуждением раньше было то, что я, используя технологию Continuations, путал/мешал ее с технологией Comet. Однако это совсем разные вещи, которые можно смешивать и получать очень мощный инструмент взаимодействия сервера с клиентом (именно так, а не наоборот), и все это на базе протокола HTTP.

Очень прошу помощи в интересующих вопросах.

Спасибо за советы :)
Реализовал-таки клиента под сервер с технологией Comet, пока тестовый вариант, но полностью работающий. Пришлось использовать флеш как транспорт, но меня это не пугает, так как проект флеш-ориентированный и отказ от установки флеш-проигрывателя (если его нет) автоматически запрещает вход на сайт. js-версия также рабочая (Вариант 1), но видимая жизнедеятельность работы (приема и передач) мне не нравится, и во фрейм не прячется.
Вещь - супер. Нагрузка сервера - 0, клиент не делает никаких телодвижений (события по таймауту, реквесты и т.д.), загрузка сети минимальна, отклик мгновенный, сервер и не подозревает что есть такая вещь как сокеты - все на одном стандартном порту (в моем случае 8080, но можно и на стандартном 80), но при этом сам дергает клиента :), да к тому же сам определяет - закончилась сессия или клиент отвалился. Одним словом - мечта веб-программера! :) Большую нагрузку у меня пока нет возможности попробовать, да и не надо, но люди говорят, что достаточно простой сервер держит стабильно 20000 одновременных коннектов.

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

Если говорить, что в идеале хотелось получить на js, то близко, только вот запрос, сделанный AJAX'ом, не закрывается - сервер оставляет его открытым, коллекционируя response на запросы. А пакеты отправляются протоколом chunked (последновательность байт, ограниченная нуль-байтовыми символами).

Естественно, основное и главное преимущество - это именно та самая нотификация сервера - server-push. Это следующий "шаг" после server-polling, который можно сделать с помощью технологии Continuations, ну и совсем далеко от client-polling, который реализуется обычными асинхронными событиями по таймауту. А что же еще нужно от технологии?

Конечно, если мы смотрим количество людей на сайте, то вполне подойдет client-polling раз в секунду-пять, но если делается игрушка с реал-тайм-движком? Или полноценный Jabber? Тут такая штука не подойдет: реал-тайм - на то он и реал-тайм, чтобы выдавать сообщения сразу, а не когда их попросят. У меня как раз именно такая ситуация ...

Естественно, серверная реализация без удерживания связей быть не может, то есть нити процессов висят. Казалось бы, данная реализация близка к реализации сокет-сокет, только вот различия очевидны: серверу на каждый подключаемый сокет нужен отдельный порт - и это со всей инфраструктурой и выделяемой под сокет памятью - цифра при большом количестве соединений будет огромной - сервером можно не обойтись, понадобится серверный кластер (реализация мейл.ру и рамблер - по 200-300 серверов в кластере), ну и количество доменов прийдется увеличивать. Хотя я и не располагаю глубокими знаниями по комет-архитектуре, но саму возможность и функциональность осуществляет веб-сервер (сервер приложений), используя ExtendedIO или AdvancedIO (у Апача это вроде как NIO), а канал - всего лишь поинтер на реквест/респонс, то есть памяти расходуется несоизмеримо меньше, а порт всего один. По скорости комет и сокет-сокет должны быть одинаковы: в обоих случаях коллекция, которую надо в цикле обойти и отправить что кому нужно. Приэтом Continations немного должен отставать по времени, так как в качестве ответа сервер отдает полноценный ответ (респонс), то есть добавляется время "стыковки" - конечно, мизер, но кто что ищет ...

Еще пару отличий, которые, возможно, облегчат жизнь веб-программеру:
- пока открыт канал, сессия не теряется, вне зависимости, на сколько она выставлена и сколько не трогали страницу;
- как следствие предыдущего пункта - пока открыт канал, можно полноценно управлять учетными записями (лично у меня с этим загвоздка всегда - перезаход под тем же именем/паролем или должен перебить/закрыть первоначальный коннект или, если же это очень существенно, то либо дожидаться конца сессии, или делать механизм опроса первоначального коннекта) - в реальной жизни молозначимое действо, но в серьезных проектах с серьезным секъюрити может очень выручать.
- можно использовать разные протоколы - для контента обычный HTTP, а на комет-запросы - HTTPS; правда, слабо представляю реализацию на js, но для флеша совершенно незаменимая вещь - вся страничка по обычному, а запросы в флеш - по защищенному (кстати, так и планирую дорабатывать).

Сразу приношу извинения за возможные неточности и даже возможно ошибки, так как мои знания в этом предельно поверхностны, изначально делалось больше по наитию, и полагаюсь больше на инфу, подчерпнутую со страниц, коих было пересмотрено огромное количество. Да и "публикуюсь" не для "зарисовок" или отчетности, а в надежде, что есть/появятся люди, понимающие в этом больше меня и которые смогут меня поправить/дополнить или элементарно дать совет :)