Как сделать мгновенную доставку сообщений (Чат) как в ВК?

Question

[Ilya Pavlov]

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

Answer 1

[Евгений Самойленко]

Гуглите:
long polling
websocket

у вк лонг пулл

Answer 2

[Александр Таратин]

www.google.com/search?q=websocket&oq=websocke&sour...
или
https://www.google.com/search?q=websocket&oq=webso...
или
https://www.google.com/search?q=websocket&oq=webso...

Answer 3

[Александр Зеленин]

Вместо long polling, лучше все же, сокеты использовать. (если того позволяют ограничения проекта)
Например: socket.io

Comments

[Сергей Протько]

справедливости ради стоит сказать что socket.io имеют фэлбэк в long pooling так что проблемы нету вообще.

[Александр Зеленин]

Имеют, если его настроить :-) При несколько кривой реализации получается что его нет (лично сталкивался).

Answer 4

[Радость моя]

Поддерживаю @Zav лучше всего nodejs (+socket.io) + SSE (server sent events)

вот тут есть сравнение методов пула и ссе

habrahabr.ru/post/120429

Comments

[Сергей Протько]

ну на счет "лучше всего node.js" вопрос спорный. Скорее "проще всего" так как для php придется еще libev ставить экстеншен и т.д. что бы хоть чуть чуть догнать по производительности node.js. А систему аунтефикации через pub/sub делать все-равно придется (или нет, зависит от задачи).

Если загоняться по поводу производительности, лучше всего написать чатик на go воспользовавшись каким gorillatoolkit.

[Александр Зеленин]

Аутентифицация, в случае socketio, происходит всего 1 раз, на момент подключения. После этого повторных проверок не требуется.

[Сергей Протько]

@Zav это понятно, но это не исключает необходимости создавать такой механизм в случае если основное приложение написано на php. ДА и в любом случае через zeromq какой это стоит делать что бы не блокировать работу сервера и обслуживание новых соединений/текущих соединений и не тратить его ресурсы на всякие там обращения к базе, хэширования паролей и верефикации. node.js все же за всей своей "асинхронностью при работе с IO" все такой же однопоточный и если хэш пароля сервер считает 0,1 секунду, то на эту самую 0,1 секунды сервер замирает. И уж темболее не стоит дублировать реализацию логики.

[Александр Зеленин]

@Fesor да ладно тебе, хеши считаются миллисекунды. С учетом того, что нода может запускаться по количеству ядер, пусть их будет 16, и ресурсы тратятся на установку подключения, то для подключения 50 000 пользователей затратится пара секунд. Не многие сайты могут похвастаться таким одновременным онлайном. Использование очередей тут, как бы, вообще не причем. Они оправданны только при разнесении логики на разные сервера и взаимодействия их друг с другом, либо для выполнения ресурсоёмких задач в очереди (неожиданно). Вообще, в случае если основное приложение на PHP, я бы посмотрел в сторону сокетов реализованых на PHP, что бы не мешать технологии.

[Сергей Протько]

@Zav у меня хеширование пароля с солью в sha512 в пару тысяч итераций на сервере занимает где-то 0,05 секунды и больше. Причем это делается специально, что бы усложнить подбор паролей если база утечет. При таком раскладе "подбирать" придется реально долго. Пример надуманный, соглашусь. В большинстве случаев это не критично.

Но если у вас приложение написано не на node.js все-равно придется организовывать шину данных на очередях.

[Александр Зеленин]

@Fesor хороший подход, уважаю, но 1) приложений, требующих такого уровня безопастности вообще мало. 2) Сейчас, благодоря "вкладу" биткоина дешифровать можно таки шустро и 3) Если вход через сторонний сервис типа гугла или контакта, то всё еще пробще.

Answer 5

[Сергей Протько]

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

Да, это называется pooling, потому придумали long pooling при котором опрос сервера происходит один раз, и ждет пока не придут какие-то данные, или соединение оборвется по таймауту. А потом снова. Это позволяет уменьшить количество запросов с 1-ого в секунду до 1 скажем в пол минуты или итого меньше. Зависит от web сервера, keep alive-ов всяких и т.д. Так же делей доставки невилируется так как мы ждем до момента получения данных.

Самым же продуктивным способом является установление постоянного соединения с сервером и двусторонних обмен данным. это позволяют сделать websockets. Одно но, если браузер пользователя не поддерживает websockets нужно делать фэлбэк в long pooling. Так же пользователь может сидеть за HTTP проксями (например, как добрая половина пользователей вконтактика, с работы) которые не понимают ничего кроме старого доброго HTTP 1.1 и режут все websocket соединения.

Для php есть ratchet.

Comments

[Александр Зеленин]

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

[Сергей Протько]

@Zav я имел в виду что нам вообще не нужно делать запросы в цикле. Мы ждем либо таймаута (от 10 секунд и больше) либо данных (хоть раз 10 милисекунд).

[Александр Зеленин]

Я понял что ты имел ввиду, потому и поправил. Перечитай что написал в ответе сам.

[Сергей Протько]

@Zav то есть сложно сказать как частно у нас будет клиент бомбить запросами сервер, но не будет холостых запросов. Или их просто будет в пару десятков раз меньше.

[Александр Зеленин]

Я не понимаю к чему эта дискуссия.

[Сергей Протько]

@Zav я только сейчас опечатку увидел. Поправил.

Answer 6

[Виктор]

Да слать каждую секунду это не то что нужно. Хотя бы по тому что данные в таком случаи будут приходить раз в секунду и не чаще.

Для того что бы клиент получил данные мгновенно надо держать с ним постоянно открытое соединение. Для php это затруднительно в плане ресурсов сервера, по этому используют комет сервер. Он как правило заточен на поддержание огромного количества открытых соединений.

Если у вас нет опыта работы с чем nо кроме php вам имеет смысл ознакомится с технологией на примере работы с комет сервисом предлагаемым по Saas модели, это быстрее чем разобратся в node.js и socket.io

Вот несколько comet сервисов.
[Ru] comet-server.ru/menu_id/10

[En] pusher.com/pricing
[En] https://www.tambur.io/pricing