[ Поиск ] - [ Пользователи ] - [ Календарь ]
Полная Версия: Вебскеты и php
acerrusm
Привет!

Решил встроить в проект уведомление пользователей при новом сообщении, но без перезагрузки страницы. Бэкенд написан на php (symfony), а фронтенд на Angular.

В инете прочитал, что для этих целей нужно использовать вебсокеты, с которыми я ранее не сталкивался.

Прочитал про Ratchet. Круто, все работает на php, но: эта технология не поддерживает SSL, одна ошибка и сокет сервер ляжет, трудно скейлить горизонтально.

Прочитал про Socket.io. Тут нужен nodejs сервер, но я так и не понял как php должен передавать на nodejs сообщение, а тот в свою очередь клиенту. Везде пишут про elephant io, но разработчик проекта пишет, что проект больше не поддерживается.

У кого есть опыт с вебсокетами поделитесь инфой пожалуйста.
AllesKlar
Просто ради одного уведомления пользователя городить такое?
Если бы нужно было пушить разные данные в разных ситуациях, то да.
А так на много проще по таймеру аяксом опрашивать сервер. Дешево и сердито smile.gif

Конечно, если сама технология интересна - то вперед.
Вот тут простенько всё, как раз для начала самое то в примерах и с картинками smile.gif :
https://habrahabr.ru/post/209864/

_____________
[продано копирайтерам]
acerrusm
AllesKlar, спасибо за статью! А можно пару примеров когда стоит использовать сокеты?
AllesKlar
Цитата (acerrusm @ 8.03.2018 - 21:58)
когда стоит использовать сокеты?

Ну, например, совместное использование данных. Чтобы у моем ГУЕ было видно, что ты прямо вот сейчас правишь текст, который у меня так же открыт (гугля-докс smile.gif )

_____________
[продано копирайтерам]
Эли4ка
Цитата
но я так и не понял как php должен передавать на nodejs сообщение, а тот в свою очередь клиенту.

Id по ссылке, почему не?
vagrand
acerrusm
Специально для таких целей придумали push сообщения. Если вкратце, то они работают по следующему алгоритму:
1. На клиентской части происходит регистрация на сервере push сообщений, получается ID и сохраняется в вашей базе с привязкой к нужному пользователю.
2. Когда на сервере происходит какое-то событие, то ваш сервер отсылает сообщение push серверу, а уже тот дергает ваш клиент.
Все довольны и не надо дергать сервер через ajax или держать постоянное соединение через сокеты.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
AllesKlar
Цитата (vagrand @ 9.03.2018 - 07:34)
2. Когда на сервере происходит какое-то событие, то ваш сервер отсылает сообщение push серверу, а уже тот дергает ваш клиент.
Все довольны и не надо дергать сервер через ajax или держать постоянное соединение через сокеты.

эээ.. а как сервер дергает клиента, если соединение разорвано?
За что он его дергает?
Клиент - это мой браузер.

_____________
[продано копирайтерам]
Эли4ка
AllesKlar, браузер подписан, нет?
acerrusm
Цитата
Id по ссылке, почему не?

Эли4ка, не совсем понятно что ты имеешь в виду. Можно по-подробнее?

Цитата
На стороне node.js можно использовать socket.io-redi

Santehnick, Redis в данном случве будет выступать некого медиатора между php и socket.io, верно?

Цитата
Специально для таких целей придумали push сообщения. Если вкратце, то они работают по следующему алгоритму:
1. На клиентской части происходит регистрация на сервере push сообщений, получается ID и сохраняется в вашей базе с привязкой к нужному пользователю.
2. Когда на сервере происходит какое-то событие, то ваш сервер отсылает сообщение push серверу, а уже тот дергает ваш клиент.

vagrand, я в принципе так и понял: сначала юзер авторизируется, сервер генерит jwt токен, сохраняет его в базе и передает клиенту. Клиент сохраняет токен в local storage, и пытается создать соединение отправляя при этом токен в заголовке для авторизации.

Теперь такой вопрос: нужно авторизировать пользователя только при создании сокет соединения, или при каждом чихе тоже отправлять токен для сверки?
Почитал статью которую дал AllesKlar. Запустил у себя миничат и при разборе понял, что заголовки отправляются только при соединении. При отправлении сообщения, никаких заголовков нет. То есть, если мне нужно сверять токен при каждом передвижении юзера, мне придется передавать токен уже не в заголовке.

Тема для меня новая, так что заранее извиняюсь если вопросы не ясные)
acerrusm
Автор статьи от AllesKlar пишет, что сам сейчас пользуется Workerman и рекомендует к рассмотрению Swoole. Я так понимаю без разницы какой технологией пользоваться, главное что бы она выполняла твои требования (вроде ssh, authentication) и была написана на языке программирования которым ты владеешь, что бы можно было поковыряться в исходниках. А весь этот хайп вокруг socket.io, это просто хайп и сейчас просто им модно пользоваться. smile.gif
Эли4ка
Цитата
Эли4ка, не совсем понятно что ты имеешь в виду. Можно по-подробнее?
vagrand
AllesKlar
Цитата
эээ.. а как сервер дергает клиента, если соединение разорвано?


А ему не нужно никакого соединения. Это функционал браузера. Все современные браузеры поддерживают push уведомления.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
vagrand
acerrusm
Цитата
vagrand, я в принципе так и понял: сначала юзер авторизируется, сервер генерит jwt токен, сохраняет его в базе и передает клиенту. Клиент сохраняет токен в local storage, и пытается создать соединение отправляя при этом токен в заголовке для авторизации.


Вы к сожалению поняли не правильно. Клиент посылает запрос к серверу push уведомлений для регистрации на нем. В ответ он получает уникальный id и прочие параметры для доступа. Эти параметры нужно затем сохранить на вашем сервере привязав к текущему юзеру. Затем, когда на сервере произойдет нужное событие, вы прямо с сервера отправете сообщение на сервер push уведомлениц, а уже он дернет нужный браузер.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
acerrusm
vagrand, если речь идет про это, то не мне это не совсем подходит — нужно спрашивать у пользователя разрешение, ну и как пишут - технология экспериментальная.
vagrand
acerrusm
Да, про это. Решать само собой вам, я лишь подсказал оптимальный для сообщений вариант.

_____________
Senior PHP developer: PHP5, MySQL, JavaScript, CakePHP, Yii/Yii2, Zend Framework, Smarty, XML/Xslt, JQuery, Jquery Mobile, Bootstrap, ExtJS, HTML, HTML5, CSS, Linux, SVN, Git, Memcached, Redis, MongoDB, Zend Guard, Ioncube, FFMpeg, PayPal, Webmoney, Qiwi, Facebook API, Vkontakte Api, Google API, Twitter Api, Steam Api.
Junior Android Developer: Android SDK, многопоточность, работа с HTTP запросами, JSON, SQLite, фрагменты.
Быстрый ответ:

 Графические смайлики |  Показывать подпись
Здесь расположена полная версия этой страницы.
Invision Power Board © 2001-2024 Invision Power Services, Inc.