Правильно ли я понимаю, что средствами редиски без доп. приблуды, которая будет следить за таймерами и рассылать уведомлялки об удалении (пусть даже через тот же редис), мне не обойтись?
Cr3w, это не играет роли на самом деле, сервисы в большей степени - это набор из примерно 4 node-приложений, каждый экземпляр которых просто запускается на своем файле настроек... и в этих настройках указывается помимо параметров работы экземпляра (базы, условия, в общем много чего) и массив IP-шников, с которых можно подключаться к управлению этим процессом...
Можно, конечно, лезть в код, добавлять туда авторизацию, но тогда придется дорабатывать и сервисы, которые с этими службами работают в автоматизированном режиме (собирают и обрабатывают отчеты, архивация и т.д.)...
Хммм... как-то заморочно получается, но с другой стороны, можно будет убрать на самих сервисах все фильтры, и делать их только на уровне iptables аля "ты туда ходи, а туда не ходи"
АртемЪ, если юзер 1 не подменит свой адрес, проблем никаких нет... а если подменит, то сможет получить доступы к сервисам юзера 2...
к сожалению сами сервисы такие, что могут делать ограничения только на базе IP-шников подключаемых юзеров
А зачем вы выдаёте клиентам сетевые конфиги, если можно пушить их с сервера
Никакие сетевые настройки в конфигах и не присутсвуют, они пушатся с сервера, но это ведь не исключает возможности добавить самостоятельно в свой конфиг своих директив.
А узнать базовые значения, как выше написали, не сложно банальным ipconfig /all после подключения с исходным конфигом...
Вот я юзеру 1 назначил на сервере адрес 10.0.0.1 и у него свои доступы по сервисам, а у другого 10.0.0.2 и у него другие доступы... Вот юзер 1 возьмет в своем конфиге вставит директивы для назначения адреса 10.0.0.2 и вот как бы это пресечь...
Кстати, если интересно, да, я немного "изобрел велосипед" для своей архитектуры - в плане документоориентированной базы в памяти, но только с рядом небольших фишек, которых нет ни в мемкеше, ни в редисе ни в какой-либо иной системе (по крайней мере я не нашел)...
Что-то типа чата, собственно говоря и вышло, с задокументированным протоколом - реализация функция непосредственного хранения/удаления данных из памяти + уведомления об изменении данных всех/определенных клиентов, синхронизации данных и много всяких мелочей. Система на тестах легко удержала примерно 1000 одновременных соединений с учетом довольно активной работы с данными как со стороны клиентов, так и широковещательных уведомлений/данных от сервера.
ЗЫ. Под понятием "глобальной" я подразумеваю в конкретном посте либо реальную переменную глобального типа, либо свойство класса-оболочки чат-сервера - в зависимости от способа реализации кода =)
если ты используешь в качестве сокет-либы ws, то достаточно использовать следующий подход:
- socketPhp - это сокет приема данных от PHP
- socketClient - сокет приема клиентских соединений
1. заводим глобальную переменную usersPhp = {};
2. приходит информация в socketPhp c id + token + userinfo => пишем usersPhp[token] = {id: id, info: userinfo, timeout: (new Date().getTimeout() + 3600000)};
3. приходит коннект на socketClient с передачей токена:
- проверяем по пришедшему токену: if(typeof usersPhp[token] !== 'undefined'){...}
- если элемент есть, то прямо объекту самого соединения добавляем свойство: client._user = {id: usersPhp[token].id, info:usersPhp[token].info, token: token}
- удаляем элемент массива: usersPhp[token] = ''; delete usersPhp[token];
4. собственно при приходе в сокет любых данных на входе ты имеешь объект этого соединения, и в нем можешь обратиться к новому свойству client._user
ну а для поиска конкретного соединения (а соответственно и данных юзера) можно просто создать метод/функцию поиска, аля clientById/clientByToken - который будет среди коннектов искать нужный и вызвращать его в качестве результата
ну и чтобы не копились устаревшие данные в памяти, запусти setInterval(...) который будет чистить устаревшие строки из массива usersPhp
В первом приближении дел минут на 10-15, думаю, не больше...
Но такой подход по сути устраняет лишнее звено мемкеш/база, а это в свою очередь не только ускоряет работу, т.к. не требуется обращаться из ноды к внешним системам, но и убирает из системы критически-значимый узел, от которого зависит работа системы, к тому же общее потребление памяти комплексом тоже будет меньше =)
Ну прямо "базой" я бы не называл... Все-таки база - это более широкое понятие, тем более что прямо ХРАНИТЬ ключи в ноде тебе не нужно =)
- авторизация на пыхе => отправка в ноду нового токена
- нода приняла и сунула в какой-то свой массив с таймером очистки секунд через 30-60
- клиент подключился к сокету с передачей токена => нода по этому ключу авторизовала юзера, привязала минимальный блок данных к сокету (ЗЫ. объекты сокет-клиентов позволяют добавлять "налету" свойства и оперировать ими как угодно, сохраняя их состояние на протяжении всего существования соединения)
- клиент отключился => сокет закрыл соединение и очистил объект (соответственно память от ненужных данных юзера)
Я так понял суть вопроса:
- есть некий сервис, который предоставляет из себя чат-сервер на ноде, от открывает сокет для внешних соединений авторизованных пользователей с помощью токена
- есть сскрипт авторизации на пыхе, который принимает "логин-пароль", авторизует и генерит некий токен, который собственно и используется чат-клиентом для соединения и идентификации на чат-сервере (нода)
- принимая соединение чат-сервер должен проверить что это за токен и получить данные юзера для своих нужд...
Если я все верно понял, то никаких доп. демонов не нужно делать. Ничего не мешает на сервисе чат-сервера открыть еще один сокет для ПРЯМОГО приема данных юзера вместе с токеном от пхп-скрипта авторизации. В таком случае при коннекте клиента не нужно никуда больше лезть, эти данные УЖЕ прилетели от пыха прямо в сервис через сокет.
Честно говоря, я бы воспользовался не мемкешем, а банально внутренней прямой связью... Технически есть разные варианты, но в голову навскидку приходит самый простой:
- в ноде вешаем на 127.0.0.1 еще один сервер-сокет с разрешением коннекта только с локалхоста
- пых при работе с данными юзера после записи данных в бд коннектится на этот сокет и простым упакованным приготовленным JSON-пакетом кидает в этот сокет инфу по юзеру/любым его изменениям/входу/бану и т.д.
- нода получает эти данные что называется realtime вообще без каких-либо дозапросов к БД и т.п.
У меня на принципах взаимодействия через сокеты работает целый комплекс инструментов, каждый из которых выполняет конкретную узкую задачу и его можно расширять такими "кубиками" до бесконечности...
К слову, тогда сразу уйдут издержки не только на коннекты/запросы и т.п. что сразу бросается в глаза, но и на обработку данных, выделение только нужных, их структуризацию...