Смотрю, что тут дубль вопроса с sql.ru ...
Серж, с тобой категорически не согласен - это не решение проблемы, а слегка каличный костыль. Да, использование запросов по таймеру находит свое применение, но предлагать его для интерактивного двустороннего обмена с сервером - это не то. Наиболее продвинуто с этой задачей сейчас справляется Comet.

Ага, забыли еще упомянуть чистящие средства Comet ...

iConstДве беды - фаерволлы и пул соединений....
Бед нет ни одной: для разрешительных политик флеша на серваке открываем порт (по умолчанию 843), следовательно, разрешения присутствуют. Остальное соединение идет по 80-му порту, что также не вызывает протестов сервера.
По второму пункту и вовсе не понимаю, так как Томкет с НИО-коннектором гарантийно держит 20к одновременных соединений (из реального опыта работы других разрабов) ... естественно, сервер должен быть хотя бы не старше 5 лет :).

Считаю, что такие высказывания "в воздух", как минимум, должны быть подтверждены какими-то обоснованиями.

Подход понятен ...

Мой опыт базируется на личном colocation сервере - 8 ядер Xeon, 6 Гб ОЗУ, RAID6 на 4-ех дисках с горячей заменой, питание с резервным модулем и горячей заменой, 20 Мбит выделенка - поэтому сложно сказать, с какими трудностями люди сталкаваются на хостинге. Однако считаю, что специфичность задачи все-таки заставляет использовать полный доступ к серверу, так как при условии твоего п.1 задача действительно сложновыполнима, хотя ... если сервак/хостинг "заточен" в том числе под флеш, то 843-ий порт гарантийно открыт. Так как все остальные "движения" производятся по 80-му порту, то больше проблем с защитой быть не должно.

Что касается пункта 2, то задача специфическая не только по технологии, но и по аудитории: применять Комет в веб-проектах презентационного плана либо нецелесообразно, либо слишком мало количество одновременных обращений - мало применений. Предположу, что в подавляющем своем применении данная технология используется в онлайн-играх, где критична и скорость, и нагрузка. А это уже коммерческий проект, на который можно и потратить определенную сумму на сервер, а то и не на один (кстати, глупо даже предполагать, что при 20к соединениях может использоваться хостинг - узко мыслите, товарищ).

У меня, чувствую, возникнет в свое время серьезная проблема с распределением нагрузки, так как заказчик предполагает после раскрутки проекта пиковую посещаемость 50к одновременно (!!!) ... я не верю, конечно, но спорить с заказчиком не собираюсь. Правда, его подход мне нравится: если сетевое оборудование, то CISCO (посмотрите на цены компонентов и все поймете), так что проблемы развернуть кластер возникнуть не должно.

Еще пару слов о производительности комет-сервера: противники/оппоненты данной технологии постоянно приводят дикие цифры выделяемой памяти - вплоть до 3-4 Мб на поток и очень скептически относятся к нагрузке в 20к ... Честно скажу, - пока не проверял - и сам как-то слегка скептически отношусь к этой информации, полученной из инета от незнакомых людей. Однако смотрел другие расчеты: для 3-4к соединений используется всего 130-150 потоков выполнения (!), что сильно снижает планку к потребляемой памяти. Связано это с тем, что в цепочке "клиент-передача-сервер-передача-клиент" звено "сервер" как наиболее быстрое, так и одно из самых малоиспользуемых (по крайней мере в сравнении с "клиент"), поэтому при одновременном соединении 20 человек одномоментно сервер использует только один. А удерживать сокет открытым больших ресурсов не надо ...

Резюмируя, скажу, что серьезным специалистом данной технологии себя я не считаю, по крайней мере, до тех пор, пока проект не начнет обкатку. Однако в ней начинаю себя чувствовать весьма уверенно и она мне очень нравится. А главное - альтернативы я просто не вижу, все действительно работающее так или иначе использует данную технологию. Иначе это просто эмуляция keep-alive. Это не утверждение, а наблюдение, так как самому было бы крайне интересно увидеть/услышать что-то другое или новенькое.

Раз уж меня тут "прорвало", то поделюсь еще одной технологией, которую пытался применять (и даже что-то получалось) до использования неблокирующих коннекторов и Комета: называется она Continuations, вроде разработана была Jetty. Принцип прост как 2 копейки: клиент делает запрос на сервер (ожидание приема информации), на сервере реквест обрабатывается, инициализируется респонс, но не отправляется, а помещается в висящий поток, из которого он может быть изъят или по таймауту (скажем, 10 секунд), либо по событию другого клиента. Когда событие возникает, респонс возвращает клиенту ожидаемые данные и тут же (без всяких таймеров) снова отправляется запрос на сервер, где он опять засыпает до наступления события. Реализовать достаточно просто, в сервере приложений Jetty есть как исходники, так и примеры, технология работает, и весьма успешно. Однако, как вы понимаете, это не реальный keep-alive (или как там - server push), а лишь эмуляция его. Для чатов - самое оно - работает в реальном времени, но для онлайн-игрушек, имхо, мелковато.

прдн ...
4 проца х 4 ядра = 16 ядер Xeon
можно не обязательно использовать 843-ий порт, с админом хоста можно договориться на любой другой ...

У НИО-коннектора есть обязательный параметр - время таймаута, когда соединение само отвалится, если не будет запросов. По умолчанию стоит 30 мин. В последнем проекте попросили поставить 4 часа для админки (начастые обращения и висит в окне). Параметр может меняться динамически установкой при запросе. Так что лишнего не сожрет ... :)

Я не знаю как они это делают, но если ничего не отсылается и не принимается, то за полчаса съело трафика меньше, чем при одном запросе :), так что кошелек тут явно не при чем ... :)

Ну, шашки у меня слабо ассоциируются с realtime :), а вот посмотри на игрушку tankionline.com - там комет и вроде на джаве - каково там делать таймеры? :):):)

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

Ждем-с с нетерпением твой релиз :):):) ... я первый на очереди на покупку движка для своего казино :)

ShSergeСерверпуш работает, как типа бесконечная загрузка страницы - отстой полнейший.
Забыл прокомментировать ... согласен на 100%. Я когда попробовал реализовать ЭТО на чистом javascript, плевался сильно. Именно поэтому пропагандирую использовать связку javascript <-> flash <-> server, потому как флеш - замечательно "заточенная" под это штука. С выходом AS3 его возможность стали как для клиента просто несравненными ...

Ого! Не ожидал ...
Не поверишь, но AS3 как две капли похож на Java, хотя AS2 был больше похож на javascript. Единственное, что сразу бросается в глаза - отличие в определении переменных. В остальном сложно сразу даже сказать на чем написано (кроме заглавной части). Поэтому этот язык будет тебе крайне прост в программировании. И никакой кроссбраузерности! :) Я уверен, что львиную долю времени у тебя занял графический интерфейс и адаптация. А во флеше это сущая ерунда ...

Я как-то по-старинке использую родную среду флеша (пока пиратскую, заказчик обещал подогнать профпакет флеша, жду 12-тый). Однако все больше приучаюсь к свободнораспространяемому софту, а так как любимая среда - Eclipse, то мой выбор - FDT (Flash Developer Tools). Вот тут есть неплохое сравнение сред программирование, почти все - бесплатные.

Главное, что надо понять, что сейчас флеш - это не только среда рисования и работы с анимацией, но и серьезное программирование. И если для первого нужна лицензионная среда, то для второго продуктов со свободной лицензией навалом - под любой вкус. На выходе все равно компилируется swf-файл.

Надеюсь, на 5%-ную скидку на шашки постами наскребу ...