Команду из за рубежа нанимать будем

вот лучше команде задавать вопрос. речь не в инструменте а в владении им

Команду из за рубежа нанимать будем

Узбекистан? ?

Запад

Если у вас бабло есть, наймите консультанта

Архитектурного специалиста

Спасибо за совет.

шо тут творилось

опять пхп?

Пхп

Топ

Господа, нужен ваш совет

Вопрос для сокет-гуру

коннекшн в бд хранить?

зачем коннекшн хранить?

Чтобы между рестартами процесса его из базы поднимать? ?

зачем коннекшн хранить?

Понадобиться хранить же вроде :D

При входе на залогенную страницу, чекается есть ли подключение, если нет - создаётся. Но сервер должен же знать кто есть кто, то есть хранить соединение

Чтобы между рестартами процесса его из базы поднимать? ?

из какой базы? мы же про вебсокеты

из какой базы? мы же про вебсокеты

Я не так вопрос прочитал, и он показался мне очень смешным ☺️

Если хранить в редисе, то встанет проблема актуальности соединения

То есть, придётся чистить часто

коннекшн в бд хранить?

Что бы это могло значить? Как ты себе это представляешь?

В редисе думаю хранить

В редисе думаю хранить

а понимаешь что ты хранишь то?

Что бы это могло значить? Как ты себе это представляешь?

Соединение в бд хранить

Соединение в бд хранить

Что значит хранить соединение? Объясни как ты это понимаешь.

Чтобы достать в нужное время и послать сообщение

Ну типа подключается юзер

Его ws пишется в бд

Его ws пишется в бд

Как?

ws.on("connection", (Conn) => {})

Conn хранить

Я с мобилы, примерно написал

И можно взять conn другого юзера и послать что-то

Conn хранить

Ты представляешь что такое соединение? Его нельзя хранить в бд. Ты можешь деражть соединение открытым или закрыть его и при необходимости открыть его заново.

Если мне надо тебе в чате что-то написать, как я найду тебя?

То есть, надо же знать к кого какой коннекшн

WS соединение постоянно открытое висит. Просто добавляй соединения в массив клиентов и держи их там. В чём проблема? При обрыве/переподключении по сессии/токену определяешь пользователя.

WS соединение постоянно открытое висит. Просто добавляй соединения в массив клиентов и держи их там. В чём проблема? При обрыве/переподключении по сессии/токену определяешь пользователя.

Так почему нельзя хранить в редисе?

Так почему нельзя хранить в редисе?

Разберись что такое соединение (открытый сокет) и вопросы отпадут.

Я думал юзать редис для масштабируемости

Ибо массив не поделишь между дубликатами

Дубликатами одного микросервиса

Ибо массив не поделишь между дубликатами

Соединение ты тоже не передашь между серверами.

Соединение ты тоже не передашь между серверами.

Хмм, как в этом случае послать юзеру сообщение?

То есть, два разных автономных микросервиса должны знать о всех активных юзера

Хмм, как в этом случае послать юзеру сообщение?

1. Сервер прослушивает порт 2. Клиент подключается к порту Образована двусторонняя связь. Шли сообщения в обе стороны. Если соединение оборвалось его нужно заново создавать. Его нельзя сохранить/передать и т.д.

Да я знаю

Речь не об этом, реализовать массив соединений не варик

Ибо надо на два сервера один массив

То есть, два разных автономных микросервиса должны знать о всех активных юзера

Знать они могут, по идентификатору (любому), а передавать само подключение нельзя.

Знать они могут, по идентификатору (любому), а передавать само подключение нельзя.

Я понял что нельзя, но какой выход из ситуации?

Ибо надо на два сервера один массив

Ты не сможешь с одним соединением клиента общаться с разных серверов.

Я понял что нельзя, но какой выход из ситуации?

Менять логику приложения. Ты совсем не туда забрёл :)

Не ну теоретически, что мешает пробросить открытый сокет другому процессу?

fileno и вперед

Не ну теоретически, что мешает пробросить открытый сокет другому процессу?

Ничего не мешает. Но в такой ситуации нет смысла шарить что-то.

Если линукс

Он хочет чтобы два разных узла общались с клиентом по одному сокету...

Он хочет чтобы два разных узла общались с клиентом по одному сокету...

Нет

У меня есть 2 сервера, автономных

Ибо надо на два сервера один массив

А это что?

Они дублируют функционал друг друга, для лоад балансинга

Они дублируют функционал друг друга, для лоад балансинга

Так я же сказал по идентификатору. А ты говоришь об одном соединении.

Если я подключился к первому, а ты ко второму, как я тебе сообщение пошлю

Если я подключился к первому, а ты ко второму, как я тебе сообщение пошлю

Через бэкэнд.

Так я же сказал по идентификатору. А ты говоришь об одном соединении.

Идентификатор является sid

А вот это уже архитектурный вопрос

Тебе нужно иметь id процесса

Ну или соединения

И держать его в редисе, например, ну или где тебе угодно

То есть всё-таки можно держать соединение в редисе?

Тебе нужно иметь id процесса

Как это? У него два сервера же.

Когда ты хочешь отправить сообщение, выгребаешь идентификатор процесса, находишь на каком сервере он живет

Как это? У него два сервера же.

Да хоть 10

Не системный идентификатор, делаешь какой-нибудь uuid

У меня есть идентификатор, с этим проблем нет

И куда-нибудь складываешь. Что, например, uid такой-то подключен к такому-то серверу

Единственная проблема, единая точка хранения соединений

Надо отправить сообщение, пинаешь сервер, дальше твоя логика

Единственная проблема, единая точка хранения соединений

Тебе не надо хранить соединения

Тебе надо хранить метаданные

Ещё раз, это получится простой форвард через нутро сервера. Он изначально совсем не это хотел. Он хотел разделить/иметь копию одного массива подключений на двух серверах.

Тебе не надо хранить соединения

+

Че только не сделают чтобы не писать на эрланге)

Че только не сделают чтобы не писать на эрланге)

Эрланг умеет переносить активные соединения с сервера на сервер? ?

Ещё раз, это получится простой форвард через нутро сервера. Он изначально совсем не это хотел. Он хотел разделить/иметь копию одного массива подключений на двух серверах.

Пофиг, в любом случае нужна точка синхронизации

Эрланг умеет переносить активные соединения с сервера на сервер? ?

Эрланг умеет работать как одно приложение независимо от топологии

Пофиг, в любом случае нужна точка синхронизации

Так я ему про это и толкую с самого начала. Кто-то должен заниматься обработкой всех балансировщиков.

Это его таксказать фишка

Так я ему про это и толкую с самого начала. Кто-то должен заниматься обработкой всех балансировщиков.

Аа, я кажись понял

Типа сделать 2 дубликата

может вам просто нужно узнать по вебсокету кто это - это можно. http://iostreamer.me/ws/node.js/jwt/2016/05/08/websockets_authentication.html как скейлить вебсокеты(это для socket.io) - https://socket.io/docs/using-multiple-nodes/ все это делается в пару строк. в помощь https://github.com/socketio/socket.io-redis https://github.com/socketio/socket.io-emitter

И третий, типа посредника между дубликатами