Socket IO - Как иметь несколько пользователей-администраторов в нескольких частных комнатах по нескольким URL-адресам
Я искал долго и далеко. Обычно я знаком со стеком LAMP, поэтому извиняюсь - я изучаю Node, поскольку пытаюсь создать функцию чата - аналогично тому, как будет работать Intercom / drift.
Меня заставили поверить, что Socket.io - хороший способ решить эту проблему, и у меня возникли небольшие проблемы. Базовый обзор выглядит примерно так:
- Пользователи могут использовать мой сервис, чтобы на их веб-сайтах была включена функция живого чата (у каждого из них есть уникальный ключ API)
- Они могут добавить чат на любое количество веб-страниц / доменов (через тег скрипта).
- Чат должен быть приватным между любым конечным пользователем веб-сайта и администратором тега скрипта (владельцем ключа API, используемого для включения скрипта на страницу).
У меня проблемы с этим.
Должен ли я создавать динамические пространства имен для каждого URL-адреса или это комната?
Допустим, я создаю динамическую комнату на стороне клиента, которая уникальна, например, используемая в https://stackoverflow.com/a/19150254/1173155.
// client side code
var dynamicRoomName = API_KEY + "_" + fullURL + "_" + expressSessionId;
var socket = io.connect();
socket.emit('create room', dynamicRoomName);
// server side code
io.sockets.on('connection', function(socket) {
socket.on('create room', function(room) {
socket.join(room);
});
});
Единственный человек, который может видеть этот чат, кроме конечного пользователя, - это администратор этого ключа API, который я не знаю, как реализовать.
Я понимаю, что мне, вероятно, понадобится какая-то БД, чтобы отслеживать чаты / комнаты и т. д. Есть ли какой-нибудь хороший ресурс о том, как научиться реализовывать подобные вещи?
Помощь очень ценится!
Просто собираюсь немного расширить это, возможно, для моей же пользы, пока работаю над проблемой.
- Админов может быть много (уникальные API)
- Администраторы несут ответственность только за свои собственные чаты - они не могут видеть чаты, которые не принадлежат их ключу API.
- Многие пользователи могут общаться с одним администратором (приватно)
- Весь чат 1 к 1
- Таким образом, конечный пользователь и пользователь-администратор будут использовать разных клиентов.
- Администратор может находиться в многочисленных чатах с отдельными пользователями.
- Обычно пользователи общаются в одном чате с одним администратором.
- Администраторы не могут создавать чаты (только принимать входящие), но, конечно, могут отвечать
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 1
Я не думаю, что вы хотите использовать пространство имен, потому что тогда ваш сервер должен будет предварительно прослушивать на сервере все возможные пространства имен, чтобы услышать соединение с ним. Это кажется непрактичным и неэффективным. Есть несколько различных возможных схем. Вот один из них, который, на мой взгляд, довольно просто реализовать.
- Вы создаете одно пространство имен для этого чата администратора.
- Ваш сервер слушает это пространство имен и принимает к нему входящие соединения.
- Клиент подключается к этому пространству имен, когда хочет поговорить с администратором.
- Затем клиент отправляет сообщение
initiateChatс API_KEY в качестве данных. - Сервер закодирован так, чтобы не принимать никаких других сообщений, пока
initiateChatне будет получен с действительным API_KEY. - Когда сервер получает сообщение
initiateChat, он ищет API_KEY в вашей базе данных и, если он находит его в базе данных и этот пользователь в настоящее время находится в сети, он запускает сеанс чата с ними. Если они в настоящее время недоступны, он отправляет клиенту сообщение, указывающее, что они в данный момент не в сети. - Теперь сокет открыт для сообщений, связанных с чатом.
- Вы можете использовать динамически создаваемое имя комнаты, чтобы отслеживать две конечные точки, если хотите, и присоединить оба сокета к этой комнате.
- Если пользователь-администратор может участвовать в нескольких чатах с одним и тем же сокетом, вам нужно будет убедиться, что сообщения чата, которые он отправляет, помечены, к какому чату они принадлежат, чтобы вы знали, в какое имя комнаты отправлять сообщение на вашем сервере.
@ QuỳnhNguyễn - Не понимаю, что ты имеешь в виду. Для прослушивания пространства имен требуется наличие на сервере io.of("someNamespace").on("connection", ....). Итак, вы не можете прослушивать пространство имен, имя которого вы не знаете, и вам нужно прослушивать отдельно каждое пространство имен. Пространство имен, вероятно, не подходит для чего-то, чего много. В своем ответе я описал лучший способ принимать подключения к множеству различных потенциальных чатов. Вы прочитали и поняли то, что я предложил в своем ответе?
Я имею в виду, что это динамическое пространство имен, сэр. Как сервер SocketIO может добавить еще одно пространство имен для нового администратора во время его работы?
@ QuỳnhNguyễn - В прошлый раз я скажу это. Использование пространства имен socket.io для решения вашей конкретной проблемы - НЕПРАВИЛЬНЫЙ инструмент для работы.
Да, я читал ваш рабочий процесс, но я изучаю, как мы можем обрабатывать SocketIO Server, когда у нас есть еще один admin -> нам нужно создать еще одно пространство имен.
@ QuỳnhNguyễn - Не думаю, что вы поняли мое предложение. Он отлично работает с несколькими администраторами. Когда вы получаете сообщение initiateChat на сервере, вы просто используете логику своего сервера, чтобы определить, к какому администратору он должен подключиться, на основе переданного API_KEY. Это намного проще, чем пытаться создать множество слушателей пространства имен.
@ jfriend00 большое спасибо за это, я поработаю над этим и посмотрю, смогу ли я это реализовать. По пунктам 8 и 9: Как вы думаете, я мог бы использовать идентификаторы сеанса пользователя для уникальных имен комнат - поскольку они в значительной степени произвольны? У меня возникли проблемы с передачей идентификатора сеанса экспресс-сеанса в сокет ввода-вывода в данный момент
@shanehoban - Вам не нужно использовать идентификатор сеанса. Вы можете просто ввести новый уникальный идентификатор для названия комнаты. Это может быть просто случайное число плюс текущая дата и время, преобразованное в строку. Затем вы сообщаете об этом администратору, и они включают его в свои сообщения, чтобы вы знали, в какой чат они отправляют. Для конечного пользователя, если он может одновременно находиться только в одном чате, вы можете просто установить chatID в его объекте сокета, чтобы в любое время, когда он отправляет сообщение, вы знали, в какую комнату его отправить.
@ jfriend00 Потрясающе, звучит правильно, спасибо за миллион!
@shanehoban - К вашему сведению, это простая небольшая библиотека для генерации уникальных идентификаторов: npmjs.com/package/really-unique-id. Он объединяет случайное число, дату, время и счетчик, поэтому идентификаторы всегда уникальны.
Как сервер SocketIO может прослушивать динамическое пространство имен, сэр?