В Redis хранить т.к. она как раз в оперативной памяти. Насчет того что соединение отвалиться и остальное - это понятное дело, поэтому и хранить я собирался это списком - user_id -> socket_id.
А насчет основного потока - а что делать если инстанса больше одного? У каждого инстанса свои клиенты и уже не прокатит их найти socket_id по user_id. Только если задействовать MQ.
Тимур Шемсединов: 1. В принципе, актуально не актуально - без разницы, тут лишь проблема будет в том что если вытелетел - то все юзеры дисконнектнулись, а значит они в offline уже, и наличие записи в таблице будет означать что они в сети. А так, при каждом новом коннекте все равно же будет новый id.
2. Хм, а если сделать просто массив с socket.id клиентов?
3. Этим же занимается socket.io-adapter. Он обеспечивает доставку по socket.id, насколько я знаю
Тимур Шемсединов: Общая задача в том, чтобы какому-либо пользователю который online - отправить сообщение, но чтобы отправить юзеру сообщение - нужно знать его socket.id. Socket.id создается каждый раз новый, при подключении.
Поэтому я и предложил хранить его как user_id => socket_id в общем виде как онлайн юзеры
Тимур Шемсединов: Между процессами сообщения передает socket-io.redis-adapter. Мне для отправки лишь нужно знать socket.id для отправки сообщения выбранному клиенту
Но ведь Redis и работает в памяти, поэтому вот на него и подумал. А хранить в памяти инстанса Ноды - нужно будет еще и между собой их связывать.
Если даже не Redis, может быть Memcache? Он работает только в памяти.
Просто даже вот пример, у нас есть комната, в ней есть clients[usersid], т.к. в socket.io есть возможность посылать выбранному клиенту по его socket.id мы просто будем циклом проходить по всем userID, искать этот userID в нашей memory базе и брать оттуда socket.id соответственно
NetBear: TURN сервер же можно поднять на этом связывающем сервере для обхода. WebRTC т.к. он P2P, И естественно большее количество звонков происходит внутри одной локальной сети, но возможно и из другой, где нужно будет задействовать уже стриминг
Локальные сети полностью изолированы, поэтому нужно что-то вроде прокси.
Клиенты будут как телефоны, так и браузер. В основном думаю телефоны, там можно качество передаваемого видео уменьшить, каналы оптоволокно.
Но, как использовать прокси в приложение? Это же надо самим устройством коннектится к прокси, тут и проблемка.
Клиенты будут подключены к WebSocket'ам на этом связывающем сервере, поэтому сигнальный сервер тут не играет роли
@AMar4enko:
1. vkInit - инициализурется, после VK.loadParams(document.location.href);
2. socketInit - из VK сервиса вызывает getParams и получает нужные данные для коннекта, т.е. viewer_id, access_token и подключается
3. getData - Если подключение к socket прошло успешно, получаем данные user'a - количество сообщений, логин, и остальные данные, которые в любой момент могут поменяться, и тут конснтанта не подойдет, в данный момент она хранится просто как объект в методе getData - data = { user: {name: '', etc} }
4. После того как все сервисы удалены из очереди, происходит stateManager.init.clean, который очищает очередь и задает переменной $rootScope.loaders.init.active = false;
@AMar4enko: ибо цепочка мне нужна, например чтобы получить данные для коннекта к сокетам - нужно инициализировать вк и достать из него данные, после некоторые из этих данных мы отправляем при подключение к сокетам, а уже после подключения запрашиваем все данные юзера
@AMar4enko: т.е. все инит функции вынести в провайдер чтобы можно было его использовать на этом моменте и там получить данные? Просто данные юзера у меня не в константах хранятся
Т.е. этот stateManager сейчас как менеджмент панель сервисами, и через него управляется этот загрузчик. А хотелось бы в контроллере управлять им, т.е. его отображением. а бизнес-логику оставить в сервисе
Т.е. вот у нас будет отображаться на тот момент когда инициализация происходит, т.е. два элемента зависят от этой переменной на отображение. И вот как правильнее сделать чтобы контролировать этот загрузчик, через сервис как-то не очень вижу правильным, но и с контролллером проблемы которые описал в самом вопросе.
Неправильно поняли меня, это загрузочный экран первоначальной инициализации, т.е. авторизация и всякие другие процессы. Вы говорите про спиннер который будет обслуживать переходы между роутами и что-то вроде этого. Вроде все понятно объяснил что мне нужно
А насчет основного потока - а что делать если инстанса больше одного? У каждого инстанса свои клиенты и уже не прокатит их найти socket_id по user_id. Только если задействовать MQ.