Комментарии 108
НЛО прилетело и опубликовало эту надпись здесь
В продакшене нет, но планирую в скором будущем. Там ещё есть слабые места.
НЛО прилетело и опубликовало эту надпись здесь
Пока в продакшн не внедрили писать особо нечего — нет опыта применения. Как используем — напишу.
о нем уже немного рассказывали — habrahabr.ru/blogs/webdev/60803/
Понятно понятно, то есть не использовали, но заклеймили велосипедистов? Или если есть APE, то всем остальным можно забыть о comet серверах?
Dklab_multiplexor не претендует на полную универсальность или исключительность (кстати, если знаете аналоги, близкие по простоте к multiplexor-у, пишите в комментариях).
Если есть APE то лучше попробовать поддержать/развить существующий проект. Хотя велосипеды с префиксом в виде инициалов я не запрещаю — не моё право :)
Если хочешь использовать на продакшене — готовься к тому что 70% системы придётся переписывать. Пробывал добиться от него более-менее вменяемой работы, может копал не глубоко — но от использования отказался.
С радостью прочитаю и оценю сервис созданный на нём, не прощаюсь :)
С радостью прочитаю и оценю сервис созданный на нём, не прощаюсь :)
Странно, что ни разу не прозвучало слово Comet
НЛО прилетело и опубликовало эту надпись здесь
Соединение так или иначе один фиг закрывается и его надо периодически переоткрывать.
НЛО прилетело и опубликовало эту надпись здесь
Да, закрывает. Автор, просьба от не знающих perl — сделайте из него comet: ))
Не надо. В данном случае закрытие соединения — это плюс, потому что позволяет упрятать мультиплексор, например, за nginx. А комет вам придётся выставлять наружу в голом виде.
В общем то основным свойством серверов comet является как раз способность держать огромное число подключений и тратить на это дело минимум ресурсов. nginx, как мне кажется, здесь вообще не в тему — нечего тут кешировать или проксировать.
Вместо nginx подставьте любой балансер, который скрывает весь парк машин за одним видимым снаружи веб-адресом. А для комета (в классическом виде) придётся прокручивать отдельную дырку, чтобы он гордо торчал своим comet.host.com:123245.
В общем, лёгкость включения в любую имеющуюся систему, мне кажется, вполне компенсирует небольшое неудобство с «ручным» возобновлением соединения. Тем более, что правильно принимать постоянный комет-поток на клиенте — это тоже ещё научиться нужно. А тут всё стандартно, один запрос на одно сообщение.
В общем, лёгкость включения в любую имеющуюся систему, мне кажется, вполне компенсирует небольшое неудобство с «ручным» возобновлением соединения. Тем более, что правильно принимать постоянный комет-поток на клиенте — это тоже ещё научиться нужно. А тут всё стандартно, один запрос на одно сообщение.
НЛО прилетело и опубликовало эту надпись здесь
nginx для проксирования портов с демона на стандартный 80
НЛО прилетело и опубликовало эту надпись здесь
Мультиплексор ищет строчку identifier=* в любом месте передаваемых данных.как-то не айс.
Ну, это некоторый компромисс между красотой и независимостью от протокола.
Зато протокол может быть совершенно любым: при желании можно прикрутить мультиплексор к SMTP или POP, к примеру. :-)
Зато протокол может быть совершенно любым: при желании можно прикрутить мультиплексор к SMTP или POP, к примеру. :-)
В если ответ клиенту содержит строчку identifier=?
В Eserv'е (отечественный pop3/smtp/imap/http/итд сервер) что-то похожее есть. При реализации общих папок в IMAP используется (например, если один пользователь удалил сообщение, то у всех остальных юзеров, подключенных к той же папке, проходит об этом извещение, и их IMAP-клиенты соответственно меняют вид списка сообщений). То же самое в чат-серверах (в Eserv/4 plugin'ы, реализующие IRC и XMPP). В HTTP-сервере это (подписку на извещения между подключениями) тоже можно использовать, используется в частности в веб-мониторинге логов. На одно соединение расходуется порядка 20-100кб, т.е. может держать одновременно очень много. Насчет «сотен тысяч одновременно» — не знаю, я лично не пробовал.
Это не тот, что на moikrug.ru работает?
Ух ты, даже в голову не приходило использовать такой способ для уменьшения нагрузки! Решение опять таки лежит на поверхности, а даже мысли не приходило заставлять клиента ждать ответа от сервера, таким образом удерживая соединение :) Спасибо!
Интересная штука.А, допустим, отправка данных группе подключений не предусмотрена, как я понимаю?
НЛО прилетело и опубликовало эту надпись здесь
Пока не реализована, однако это сделать достаточно несложно: можно разрешить синтаксис вида identifier=abc,def,ght,… — на досуге сделаю.
дык, это решается уже на уровне вашего протокола, или нет?
Я тут недавно удивлялся, почему о Comet на хабре никто не пишет? И вот оно!
НЛО прилетело и опубликовало эту надпись здесь
Ну это же тонкость. А фактически ключ здесь в передаче сообщения клиенту, в момент когда оно произошло.
не в каждом браузере comet посылает больше одного сообщения за соединение. Следовательно, количество сообщений за соединение не является определяющим фактором
НЛО прилетело и опубликовало эту надпись здесь
авторы комета говорят, что он кроссбраузерный, и называют кометом даже то, что работает в ие. Вы неправы. А это — комет.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
По сути не хватает простенькой JS библиотечки для работы с сервером — чтобы само переподключалось и дергало обработчик по событию: ) Для совсем ленивых чтобы.
НЛО прилетело и опубликовало эту надпись здесь
Ага. На досуге выложу некоторый вариант.
На самом деле, там не только разрыв соединения нужно обрабатывать, но и ошибки в передаче данных (мало ли, дисконнект приключится внезапный в середине ответа), а также «лежание» сервера, чтобы он не долбился бесконечно при смерти сервера.
На самом деле, там не только разрыв соединения нужно обрабатывать, но и ошибки в передаче данных (мало ли, дисконнект приключится внезапный в середине ответа), а также «лежание» сервера, чтобы он не долбился бесконечно при смерти сервера.
Очень интересует сравнение такой технологии с простым Аяксом, при работе на php. Может у кого линк есть или кто опытом может поделится.
А что сравнивать? Тот же аякс. Вы посылаете через XMLHttpRequest с клиента запрос серверу, а сервер в ближайшие 300 секунд должен вам выдать ответ с данными. Если сервер за 300 секунд ничего вам не отвечает устанавливаете соединение повторно. Если сервер ответил, обрабатываете ответ и опять же устанавливаете соединение заново. При этом у вас как бы есть постоянное соединение с сервером. На деле все как обычно. Клиент инициирует обмен данными, затем «забывает» об этом и снова вспоминает когда сервер поймет что ему есть что отдать клиенту. Так как реального постоянного соединения нет, после каждого ответа сервера вы повторяете запрос.
Интересует сколько таких висячих соединений может выдержать сервер и сколько может выдержать тот же сервер клиентов, посылающих запрос обычным аяксом каждые Х секунд.
Сервер может выдержать почти неограниченное число соединений (я проверял на 300 тыс. год назад). На каждой паре слушающий_IP: слушающий_порт может быть не более 65536 соединений (по числу портов; на самом деле, меньше, т.к. часть портов уже используется), но никто же не запрещает добавить 10 ip-адресов или 10 слушающих портов (кстати, насчет увеличения числа слушающий_порт не уверен; поправьте меня, если я ошибся). Кроме того, есть еще ulimit -n (лимит на число открытых файлов в системе), у меня не получилось выставить его больше 1 млн для одного процесса. Ну и есть еще разные лимиты внутри системы, которые можно подкручивать (обычно лимиты OpenVZ: TCPSNDBUF какой-нибудь и т.д.) Нужно заметить, что, если какой-то из лимитов оказываются превышенными, мультиплексор не всегда адекватно об этом сообщает, так что, если у вас это произошло (проводите нагрузочное тестирование вначале!), проверьте первым делом лимиты.
Я никак не могу понять — причем тут слушающий порт и 65535? Мы же используем ОДИН порт!
Это правило логично ложится на исходящие соединения.
Поправьте меня, если я ошибаюсь. Но я встречаю эту тему в связи со своими изысканиями по Comet постоянно, и все мои знания активно протестуют.
Это правило логично ложится на исходящие соединения.
Поправьте меня, если я ошибаюсь. Но я встречаю эту тему в связи со своими изысканиями по Comet постоянно, и все мои знания активно протестуют.
TCP-соединение характеризуется парой (ip1:port1) < — (ip2:port2). В нашем случае (ip1:port1) = (1.2.3.4:8088). Соответственно, если ip2 зафиксирован, то port2 может меняться только в диапазоне 0..65535 (на самом деле меньше, ну да не важно). Поэтому на 1 слушающий сокет не может быть больше 65536 коннектов (на самом деле немного меньше). Это так?
Если да, то увеличить число коннектов можно, добавив вариабельности либо в ip1, либо в port1.
Если да, то увеличить число коннектов можно, добавив вариабельности либо в ip1, либо в port1.
Интересное решение, как бы замена nginx и php, что бы всё это дело не подвисло от кучи запросов.
Спасибо! Обязательно подключим к текущему проекту.
Спасибо! Обязательно подключим к текущему проекту.
Дмитрий, спасибо, очень компактное и интересное решение. Немного смущает только «мультиплексор ищет строчку identifier=* в любом месте передаваемых данных». Мало ли что там в данных может быть, уж лучше закрепить конкретный заголовок.
Было бы удобно (и, думаю, не сильно бы усложнило код), если бы клиент мог иметь одновременно НЕСКОЛЬКО идентификаторов. Например, localhost:8088/?identifier=1z2y3x&identifier=1z2y3y&identifier=1z2y3z. И клиенту бы дставлялись сообщения, адресованные ЛЮБОМУ из его идентификаторов. Это бы позволило легко реализовать групповую рассылку в сочетании с персональной. Например, в чате юзер имеет собственный id и id комнаты чата. На первый посылаются сообщения, видимые только ему, на второй — сообщения, видимые всем в этой комнате.
Было бы удобно (и, думаю, не сильно бы усложнило код), если бы клиент мог иметь одновременно НЕСКОЛЬКО идентификаторов. Например, localhost:8088/?identifier=1z2y3x&identifier=1z2y3y&identifier=1z2y3z. И клиенту бы дставлялись сообщения, адресованные ЛЮБОМУ из его идентификаторов. Это бы позволило легко реализовать групповую рассылку в сочетании с персональной. Например, в чате юзер имеет собственный id и id комнаты чата. На первый посылаются сообщения, видимые только ему, на второй — сообщения, видимые всем в этой комнате.
И сразу ещё одно предложение: дополнить линию IN командой на получение текущей статистики демона, как минимум, числа установленных соединений, числа онлайн/оффлайн клиентов. Чтобы можно было его подключать к мониторингу.
Он ищет самое первое упоминание строчки identifier=*. Поэтому, если в IN-линию вы будете посылать ответы с заголовком, включающим identifier (а именно так и приходится делать), то никаких проблем нет, и данные могут быть любыми.
Что касается статистики, то ее можно смотреть в лог-файле сейчас. Если сделать tail -n1 /var/log/multiplexor, то вы как раз и получите такую статистику.
Что касается статистики, то ее можно смотреть в лог-файле сейчас. Если сделать tail -n1 /var/log/multiplexor, то вы как раз и получите такую статистику.
erlang, flash sockets (+ js прослойка)
Пару лет назад реализовывал подобный мультиплексор на Java. Благо там реализация синхронной очереди делается в пару десятков строк, достаточно эффективно и надежно. Несколько сотен запросов в секунду не создают тормозов.
Хочу обратить внимание на один достаточно не очевидный момент:
Представим себе страницу с чатом, которая получает новые сообщения при помощи ajax, как написано выше,
т.е. потом сообщений проходит через мультиплексор, который сгружает их в клиентские очереди, откуда их выгребают при помощи функции getData(), как описано выше.
При F5 на этой странице имеем реальную возможность потерять сообщение!
(Ладно бы это какой-нибудь чат, у меня стабильно терялось init сообщение :)
Дело в том, что живой XmlHttpRequest заблокированный на сервере не умирает в момент релоада страницы,
и следующее сообщение он вычитает из очереди и доставит, правда уже в никуда, так как его контекста уже нет.
Хочу обратить внимание на один достаточно не очевидный момент:
Представим себе страницу с чатом, которая получает новые сообщения при помощи ajax, как написано выше,
т.е. потом сообщений проходит через мультиплексор, который сгружает их в клиентские очереди, откуда их выгребают при помощи функции getData(), как описано выше.
При F5 на этой странице имеем реальную возможность потерять сообщение!
(Ладно бы это какой-нибудь чат, у меня стабильно терялось init сообщение :)
Дело в том, что живой XmlHttpRequest заблокированный на сервере не умирает в момент релоада страницы,
и следующее сообщение он вычитает из очереди и доставит, правда уже в никуда, так как его контекста уже нет.
Так как здесь используется метод «запрос — отложенный ответ», то может быть надо в каждом запросе делать подтверждение принятых данных?
Средствами AJAX этого не добиться: когда ответ уходит клиенту, клиент уже не имеет возможности сказать серверу, принял он его или нет. Но вообще, конечно, никто не мешает сделать отдельный AJAX-запрос на сервер, в котором сообщить, что данные приняты, и снова их пересылать не нужно.
На самом деле можно придумать множество методов, чтобы доставить все нужные данные.
Я просто рассказывал про достаточно не очевидный момент с зомби-XHR, возможно это сэкономит кому-нибудь кучу времени.
Я просто рассказывал про достаточно не очевидный момент с зомби-XHR, возможно это сэкономит кому-нибудь кучу времени.
НЛО прилетело и опубликовало эту надпись здесь
У меня было вообще забавно. Схема такая — страница при загрузке шлет серверу «я тут», а сервер регистрит её и начинает в ответ слать данные (у юзера машинка по карте начинает ездить). Все было зашибись пока не пришлось добавить один маленький инит-пакетик перед потоком данных. Выглядит всё здорово — сервер получает «я тут», высылает «инит», его видно в tcpdump, он проходит по логам XHR, но на страницу не попадает, сцуко!
Пришлось вставить reset_queue(), который очищает клиентскую очередь пакетов на сервере и засылает туда для начала «nop», а потом уже «инит» и далее по списку.
«nop» пакет вообще полезен, у меня сервер с интервалом в несколько секунд высылает клиенту «nop» (там еще и серверное время вставлено на всякий случай), а на клиенте поставлен таймаут на XHR побольше, чем на сервере, чтобы ни там ни сям не клинило и всякие NAT'ы не протухали.
Пришлось вставить reset_queue(), который очищает клиентскую очередь пакетов на сервере и засылает туда для начала «nop», а потом уже «инит» и далее по списку.
«nop» пакет вообще полезен, у меня сервер с интервалом в несколько секунд высылает клиенту «nop» (там еще и серверное время вставлено на всякий случай), а на клиенте поставлен таймаут на XHR побольше, чем на сервере, чтобы ни там ни сям не клинило и всякие NAT'ы не протухали.
А что произойдёт, если во время передачи клиенту данных соединение разорвётся? Будет ли повтор, и сможет ли клиент обработать такой разрыв?
Кстати для питонистов:
www.olivepeak.com/blog/posts/read/simple-http-pubsub-server-with-twisted
Как обычно профит в адаптации под себя.
www.olivepeak.com/blog/posts/read/simple-http-pubsub-server-with-twisted
Как обычно профит в адаптации под себя.
Да, это же wave 0_о!
НЛО прилетело и опубликовало эту надпись здесь
На том же DkLab'e в форуме есть другая интересная реализация, думаю это как раз то что принято называть comet: forum.dklab.ru/viewtopic.php?t=33589
«Идея основана на наличии скрытого
«Идея основана на наличии скрытого
Есть модуль для Nginx, реализующий эту функциональность: wiki.nginx.org/NginxHttpPushModule
Дима, спасибо за идею
мы, пока идем первым путем,
перепишем все на Си, если получится — дам знать.
мы, пока идем первым путем,
перепишем все на Си, если получится — дам знать.
Дмитрий,
и все же я не до конца понял преимущества технологии Комет,
в первом случае, мы пуулим каждые 10 сек, да нагрузка на сервер есть, но если у нас сидит 20 000 пользователей, то эта нагрузка размывается на 2 000 запросов в сек. Запросы отдаются мгновенно, если использовать соответствующие технологии, напрмер мемкешед. Да, от трафика никуда не уйти, но трафик будет не такой уж и большой, по 128-512 байт на пустое сообщение. Не на много больше, чем во втором случае. Оплата трафика для провайдера, как правило по входящему трафику, или по соотношению, которое не должно превышать.
Во втором случае, я должен держать 20 000 соединений, но ОСь имеет конечный предел на кол-во одновременно подключенных соединений. Игорь Сысоев говорил, что ось можно подточить до 100 000 соединений, но реально это 20-30 К.
и все же я не до конца понял преимущества технологии Комет,
в первом случае, мы пуулим каждые 10 сек, да нагрузка на сервер есть, но если у нас сидит 20 000 пользователей, то эта нагрузка размывается на 2 000 запросов в сек. Запросы отдаются мгновенно, если использовать соответствующие технологии, напрмер мемкешед. Да, от трафика никуда не уйти, но трафик будет не такой уж и большой, по 128-512 байт на пустое сообщение. Не на много больше, чем во втором случае. Оплата трафика для провайдера, как правило по входящему трафику, или по соотношению, которое не должно превышать.
Во втором случае, я должен держать 20 000 соединений, но ОСь имеет конечный предел на кол-во одновременно подключенных соединений. Игорь Сысоев говорил, что ось можно подточить до 100 000 соединений, но реально это 20-30 К.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
dklab_multiplexor: постоянное Javascript-соединение с сервером в условиях сотен тысяч онлайн-клиентов