Проектирование backend'а для чата?

Question

[Макс Кузнецов]

Есть задача сделать что-то наподобие чата. Например, есть сотня участников, имеющих возможность соединяться с сервером через сокеты (интересует не веб и comet, а именно сокеты). Когда один из них отсылает сообщение на сервер, оно пересылается остальным. Столкнулся с тем, что не знаю как правильно спроектировать серверную часть (желательно на php). Нужны ли отдельные потоки на прослушивание и на запись в сокет? Будет ли вся эта система работать на одном порте? Помогите разобраться! Объясните хотя бы схематично.



p.s^ очевидно, главная моя проблема — в недопонимании механизмов работы с сокетами.

Answer 1

[CKOPOBAPKuH]

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

на пхп точно так же, только обрабатывать сокеты чуть сложнее.

Comments

[CKOPOBAPKuH]

а, да, забыл. алгоритм начинается конечно же со слов «слушаем порт».

[CKOPOBAPKuH]

если будете делать на php, смотрите в сторону pecl-libevent. стандартный select в пхп не обрабатывает более 1024 сокетов одновременно, если только не залезть в исходники пхп и не поменять константу

[Макс Кузнецов]

Спасибо, то, что нужно! Последний вопрос — главный процесс должен висеть демоном, правильно я понимаю?

p.s^ уже давно порываюсь изучить и прикрутить node.js — описание возможностей очень соблазнительное, но сроки поджимают и нужно сделать «лишь бы быстрее» и «лишь бы было для начала что-то».

[CKOPOBAPKuH]

да, верно. лишь бы быстрее это как раз node.js. ну, или phpDaemon, если разберётесь. мне с node.js проще было, но это уже давно было, сейчас, кажется, phpdaemon сильно улучшился.

[Макс Кузнецов]

Я немного поковырял phpDaemon, но не разобрался. Показалось, что документации маловато. Дело в том, что участники чата будут выходить в инет с мобильников, соответственно использование вебсокетов, комета, аякса и вообще какого-либо яваскрипта исключено. Нужны именно сокеты, а по ним-то как раз в phpDaemon'e информации мало. В итоге решил вспомнить и подучить java — в ней потоки проще организовать. А node.js воспользуюсь позже, для переписывания веб-части проекта;)

[CKOPOBAPKuH]

ну, дело ваше. зачем тогда спрашивать, если всё равно java и энтерпрайз?
в node.js ваша задача решается из коробки примерно за 10-15 строк. в phpdaemon — наверное, чуть больше. оба вариант — голые сокеты. не вебсокеты, не комет, не аякс, ни хттп.
потоки для решения вашей задачи вам не нужны. всё это можно делать в одном потоке. не только можно, но и нужно, потому что много потоков нужно будет ещё и синхронизировать.

[Макс Кузнецов]

Посмотрел видео по node.js от его создателя — да, вы были правы, идеальный инструмент для моей задачи. Большое спасибо!;)

Answer 2

[shsmad]

вы изобрели IRC :)

Answer 3

[Алекс Бунин]

Дело, конечно, хозяйское, но я бы не делал через сокеты. А сделал бы через обычный Web service. Все же Apache (или другой Web сервер) лучше будет поддерживать большое количество одновременных клиентов и прочее.
А на скриптовом языке будет сделана достаточно минимальная обработка запросов и отдача сообщений остальным, кто на этот момент залогинился в систему.

Comments

[Макс Кузнецов]

Можно поподробнее, как реализовать эту схему? Обращаться к скриптам как к обычным веб-страницам? Тогда запросы с сервера будет сложно реализовать (опять-таки comet): клиенты могут заходить в чат с мобильников.

[Алекс Бунин]

Реальное время с точностью до долей секунд вроде не нужно, поэтому можно сделать обычным коннектом раз в пару-тройку секунд. Что-то типа читалки rss, когда сообщения будут просто ждать клиента.
Если клиент отвалился, то всегда можно подсоединиться обратно и получить свои сообщения, историю и прочее.
Можно общаться как xml или даже json, что бы проще парсить на мобильных платформах.
В этой схеме удобно то, что не надо даже заморачиваться по поводу сокетов и прочего низкоуровнего программирования. Клиент сидит на линии и по авторизации (куки, например) отдавать сообщения, которые предназначены лично для него (или общие если там будут общие чаты).

Answer 4

[rPman]

PHP не очень пригоден (точнее не предполагает подобного использования, но формально ничто этому не мешает) для использования как постоянно запущенной службы, вместо режима частых и коротких запусков

Соответственно, можно использовать асинхронные сокеты (см. socket_set_nonblock и socket_set_option, первый же пример в гугле) в php и серверную часть запускать в виде одного процесса (со всеми вытекающими проблемами из-за потенциальных багов в коде, точнее прервутся все соединения, если упадет это приложение), либо на каждое соединение запускать по процессу, с обычными сокетами, но тогда добро пожаловать в мир semaphore и shared memory (конечно, можно и без них, используя типичный LAMP подход, когда за синхронизацию отвечает БД с транзакциями, но производительность будет ужасная и вас засмеют за говнокод).

p.s. Сильно не копал, возможно есть куча готовых фреймворков или даже расширений PHP, добавляющих событийный функционал.

Comments

[Макс Кузнецов]

Да, вроде phpDaemon должен решать поставленную задачу, но никак не могу с ним совладать.
Т.е. все-таки правильно будет вешать на определенный порт слушающего демона и создавать по процессу на каждое соединение? а когда будет нужно что-то отправить клиенту, то придется создавать отдельный подпроцесс?

p.s^ а на чём бы вы это делали? Опыта в других языках откровенно мало, но java, думаю, сумею подучить до нужного уровня. Намного ли проще будет реализовать это все на java?

Answer 5

[Alexander]

Возьмите готовое решение. Как вариант, оупенсорсное, если хотите сами поковыряться, заодно узнаете, как там backend устроен.

Comments

[Vladimir Gorobets]

Если не сложно, приведите пожалуйста пример т.к. данный вопрос тоже интересует.

[Макс Кузнецов]

мне бы «схему аль чертеж» — написал бы и сам. А пример подходящего опенсорсного проекта можно?

[Alexander]

Не, чатами никогда не увлекался, надо гуглить. Но в принципе любой классический PHPшный скрипт можно найти в сети.

Answer 6

[SolarSoul]

Не нужно велосипедов)
Jabber/XMPP сервер на Erlang

Comments

[Макс Кузнецов]

erlang настолько для меня далёк, что этот способ подойдет лишь в самом крайнем случае. Но спасибо!

Answer 7

[Виталий Перетятько]

pushmodule.slact.net/ — как раз отличная штука для всяких чатов (это модуль для Nginx реализующий http-push). Обработкой соединений, очередями и тд занимается nginx — он уж поверьте умеет это делать хорошо ))))
А для приложение — простой интерфейс позволяющий подписываться на каналы или отправлять сообщения в них.