@nanerihttps://github.com/samacs/simple_html_dom/blob/mas... - вот тут у нас происходит ошибка. Вообще самое простое решение которое можно применить - распечатать стак трейс (цепочка вызовов) которые привели к ошибке. так вы сможете проследить что кто вызывал и почему так получилось.
@uranus235 по ip вы определяете endpoint (оконечная точка, компьютер пользователя), вам нужно как-то потом это новое соединение к пользователю привязать. У вас на одном компе и с одного ip может быть несколько соединений и несколько пользователей. Просто когда клиент устанавливает соединение, он отправляет сразу и какието данные, типа свой токен выданный ему при авторизации.
Вообще забудьте про ip, его знает соединение и операционная система, вам знать что куда отправляется не нужно. Как организовывать аунтефикацию соединений и привязку их к пользователям вашего приложения/сайта решать вам. Фишка ratchet в том что он берет на себя отслеживание состояний соединений и т.д. вам только события эти разруливать нужно. скажем новое соединение было открыто - вызывается ивент onConnect к примеру, в него передается новоиспеченное соединение. Грубо говоря мы можем положить его сначала в список не авторизованных соединений и добавить для секьюрности таймстамп когда это дело было получено (затем можно будет просроченные соединения удалять, если от клиента не поступило никакой инфы скажем за 10 секунд).
при onMessage для соединения, которое еще небыло авторизовано, мы ожидаем получать данные для аунтефикации пользователя. Проверяем, если все хорошо - переносим из списка не авторизованных в список авторизованных с привязкой к id пользователя. Теперь пользователь онлайн, мы можем ему чего отправлять и все такое. Если же не все ок и что-то пошло не так - закрываем соединение (можем перед этим еще и ошибку какую послать). Клиент должен это дело уже сам разруливать.
Дебажте, посмотрите что происходит до и после вызова. вы кинули небольшой кусок кода и хотите готового решения? Увы никак, нужно дебажить, учитесь это делать сами.
@uranus235 вопервых, когда вы открываете соединение. вам извесны IP. Во вторых, давайте обрисуем простенький чатик, статей по которым уже просто тьма.
У нас есть наш скрипт, который принимает соединения и держит их в массивчике
userid => connection.
У нас есть так же цикл который постоянно мониторит соединения на предмет наличия данных для чтения. Например соединение для пользователя Bob имеет что-то на чтение. Считываем. Bob (а точнее клиент который Bob использует) прислал сообщение для пользователя Nick: {"message": "Hi, Nick", "sendTo": 154}
где 154 id ника.
можем записать сообщение в базу (или отправить в очередь что бы не грузить довольно чувствительный к затупам и блокировкам скрипт) и проверить, есть ли у нас соединение для пользователя с id 154 - есть - отправляем. Нет, забиваем - обрабатываем следующее соединение.
ratchet реализует основные вещи для удобной работы с websockets.
@uranus235 можно но зачем? Писать очередной велосипед? Если собираетесь выкатываться в продакшен - лучше взять ReactPHP + ratchet. Он по надежнее phpdeamon да и у последнего несколько другое предназначение.
И вообще, мне казалось развернуть ratchet проще чем разбираться с phpdeamon.
@uranus235 работа с сокетами - такая же как и работа с сокетами везде. У вас есть соединение - составляете массив оных с id пользователя к примеру в качестве ключа. То есть когда приходит новое соединение, производим аунтефикацию оного (то есть выясняем кто к нам стучится), и добавляем в массивчик. отправлять принимать - в рамках соединения идет, можно разруливать через stream_select например (в зависимости от реализации) какие соединения содержат данные для чтения а какие нет а какие отвалились.
@vdem в нескольких классах - лучше инджектить в конструктор инатанс хэлпера или сделать трейт. Вообще проще было бы функции использовать, если бы в PHP было хоть какое-то подобие модулей и поддерживалась автозагрузка оных. Пока это единственное оправдание использования статических классов.
@omaxphp это по сути рефлексия кода. До появления late static binding без константы __CLASS__ вообще тяжко обходиться было к примеру. Ну и удобно в вашем случае. С учетом того что появилось это дело в версии 4,3 PHP сейчас это не особо актуально.
С другой стороны я бы пользовался константами класса и хэшмэпой константа => алиас так как считаю такой подход более лаконичным. Хотя все от задачи зависит пожалуй.
@vdem а зачем вам класс хэлпер? Что за мода вообще пошла на каждую функцию вспомогательную класс хэлпер заводить? Этот метод нужен только в одном классе. так что этому методу самое место сисдеть в лике приватных методов и помогать редьюсить дублирование кода.
