quartos socket.io ou namespacing?

Estou investigando nodejs / socket.io para bate-papo em tempo real e preciso de alguns conselhos para implementar salas.

Qual é o melhor, usando o espaço para nome ou o recurso de sala para isolar completamente os grupos de conversas?

qual é a diferença técnica real entre salas e espaço para nome?

Existe alguma diferença no uso de recursos?

É isso que namespaces e salas têm em comum (socket.io v0.9.8 - observe que a v1.0 envolvia uma reescrita completa, para que as coisas pudessem ter mudado):

• Os namespaces ( io.of ('/ nsp') ) e as salas ( socket.join ('room') ) são criados no lado do servidor
• Vários namespaces e várias salas compartilham a mesma conexão (WebSocket)
• O servidor transmitirá mensagens pela conexão apenas para os clientes que se conectaram a / ingressaram em um nsp / room, ou seja, não é apenas a filtragem do lado do cliente

As diferenças :

• os namespaces são conectados pelo cliente usando io.connect(urlAndNsp)(o cliente será adicionado a esse namespace apenas se ele já existir no servidor)
• as salas podem ser unidas apenas no lado do servidor (embora seja fácil criar uma API no lado do servidor para permitir a associação de clientes)
• namespaces podem ser protegidos por autorização
• A autorização não está disponível em salas , mas a autorização personalizada pode ser adicionada à API fácil de criar acima mencionada no servidor, caso se pretenda usar salas
• salas fazem parte de um espaço para nome (por padrão, para o espaço para nome 'global')
• namespaces sempre estão enraizados no escopo global

Para não confundir o conceito com o nome (sala ou espaço para nome), usarei o compartimento para me referir ao conceito e os outros dois nomes para as implementações do conceito. Então, se você

• precisam de autorização por compartimento , os namespaces podem ser a rota mais fácil a seguir
• se você quiser compartimentos hierarquicamente em camadas (no máximo 2 camadas), use uma combinação de namespace / ambiente
• se o aplicativo do lado do cliente consistir em partes diferentes que (elas não se importam com os compartimentos, mas) precisem ser separadas umas das outras, use espaços para nome.

Um exemplo para o último seria um aplicativo cliente grande, onde diferentes módulos, talvez desenvolvidos separadamente (por exemplo, terceiros), cada um usando o socket.io de forma independente, estão sendo usados ​​no mesmo aplicativo e desejam compartilhar uma única conexão de rede.

Não tendo realmente comparado isso, parece-me que você só precisa de compartimentos simples em seu projeto para separar e agrupar mensagens; qualquer um deles está bem.

Não tenho certeza se isso responde à sua pergunta, mas a pesquisa que levou a essa resposta pelo menos me ajudou a entender melhor.

É uma pergunta antiga, mas depois de fazer algumas pesquisas sobre o assunto, acho que a resposta aceita não é clara em um ponto importante. De acordo com o próprio Guillermo Rauch ( consulte o link ): embora seja teoricamente possível criar espaços para nome dinamicamente em um aplicativo em execução, você os utiliza principalmente como seções separadas predefinidas do aplicativo. Se, por outro lado, você precisar criar compartimentos ad hoc, dinamicamente, para acomodar grupos de usuários / conexões, é melhor usar salas.

Depende do que você quer fazer.

A principal diferença é que salas são mais difíceis de implementar. Você deve criar um método para ingressar nas salas com cada página recarregada.

Com espaços para nome, você só precisa escrever var example = io.connect('http://localhost/example');no seu cliente javascript e o cliente é automaticamente adicionado aos espaços para nome.

Exemplo de utilização:

• quartos: bate-papo privado.
• namespaces: o bate-papo da página.

As salas e os espaços de nomes segmentam a comunicação e agrupam soquetes individuais.

Uma transmissão para uma sala ou para um espaço para nome não alcançará todos, apenas os membros.

A diferença entre namespaces e salas é a seguinte:

• Namespaces: são gerenciados no front-end, o que significa que o usuário, ou um invasor, ingressa no front-end e a associação e desconexão são gerenciadas aqui.
• Salas: são gerenciadas no back-end, ou seja, o servidor atribui salas de ingresso e saída.

A diferença é principalmente quem os gerencia

Para decidir o que usar, você deve decidir se a segmentação deve ser gerenciada no front-end ou no back-end

Os namespaces permitem criar objetos com o mesmo nome, mas eles seriam separados, pois viverão em diferentes namespaces, também conhecidos como escopos.

Esse é o mesmo processo de pensamento que você deve ter com os namespaces do Socket.IO. Se você estiver construindo um aplicativo da web modular Node, convém colocar um namespace nos diferentes módulos. Se você olhar novamente para o código do namespace, verá que conseguimos ouvir os mesmos eventos exatos em diferentes namespaces. No Socket.IO, o evento de conexão na conexão padrão e o evento de conexão em um espaço para nome / xxx são diferentes. Por exemplo, se você tivesse um sistema de bate-papo e comentários em seu site e desejasse que ambos fossem em tempo real, você poderia colocar um espaço para nome em cada um. Isso permite que você crie um aplicativo Socket.IO inteiro que viva apenas em seu próprio contexto.

Isso também seria verdade se você estivesse criando algo a ser empacotado e instalado. Você não pode saber se alguém já está usando determinados eventos no espaço para nome padrão; portanto, você deve criar o seu próprio e ouvir lá. Isso permite que você não pise nos dedos dos pés de qualquer desenvolvedor que use seu pacote.

Os espaços para nome nos permitem criar conexões em diferentes contextos. Podemos comparar isso com salas, o que nos permite agrupar conexões. Em seguida, também podemos ter a mesma conexão em outras salas.

Os espaços para nome permitem criar contextos diferentes para o Socket.IO trabalhar. As salas permitem agrupar conexões de clientes dentro desses contextos.