|
Подход понятен ...
Мой опыт базируется на личном 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), а лишь эмуляция его. Для чатов - самое оно - работает в реальном времени, но для онлайн-игрушек, имхо, мелковато.
|
