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

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



p.s^ очевидно, главная моя проблема — в недопонимании механизмов работы с сокетами.
  • Вопрос задан
  • 4200 просмотров
Решения вопроса 1
CKOPOBAPKuH
@CKOPOBAPKuH
судя по вашим ответам проблема сейчас не в языке, а в архитектуре и понимании того, как это будет работать.
при небольшой нагрузке (а у вас именно такая ситуация, во всяком случае сейчас, правильно?) разница между языками только в удобстве.
удобнее всего это, на мой взгляд, делать в node.js.
алгоритм:
если подконнектился клиент, запомним его в массив (хэш, сет или как оно называется, не важно). если клиент дисконнектится, удаляем из массива. если клиент что-то послал, то принимаем сообщение, пробегаем по массиву и всем клиентам, которые есть в массиве, отдаём это сообщение. всё.
после этого дописываем обработку исключений и ошибок.

на пхп точно так же, только обрабатывать сокеты чуть сложнее.
Ответ написан
Пригласить эксперта
Ответы на вопрос 6
@shsmad
вы изобрели IRC :)
Ответ написан
Комментировать
Дело, конечно, хозяйское, но я бы не делал через сокеты. А сделал бы через обычный Web service. Все же Apache (или другой Web сервер) лучше будет поддерживать большое количество одновременных клиентов и прочее.
А на скриптовом языке будет сделана достаточно минимальная обработка запросов и отдача сообщений остальным, кто на этот момент залогинился в систему.
Ответ написан
@rPman
PHP не очень пригоден (точнее не предполагает подобного использования, но формально ничто этому не мешает) для использования как постоянно запущенной службы, вместо режима частых и коротких запусков

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

p.s. Сильно не копал, возможно есть куча готовых фреймворков или даже расширений PHP, добавляющих событийный функционал.
Ответ написан
Alexx_ps
@Alexx_ps
Возьмите готовое решение. Как вариант, оупенсорсное, если хотите сами поковыряться, заодно узнаете, как там backend устроен.
Ответ написан
SolarSoul
@SolarSoul
pushmodule.slact.net/ — как раз отличная штука для всяких чатов (это модуль для Nginx реализующий http-push). Обработкой соединений, очередями и тд занимается nginx — он уж поверьте умеет это делать хорошо ))))
А для приложение — простой интерфейс позволяющий подписываться на каналы или отправлять сообщения в них.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы