Socket.io: Adicionar suporte curinga para eventos

concordou.

EventEmitter2

+1
Isso nos permitiria criar filtros e o que não para todos os eventos.

• outra dependência
• deve ser refletido no lado do cliente (código?)
• deve catchall ser chamado antes de um evento específico? ou na ordem de definição? esclarecimento necessário
• apenas sincronizar o comportamento - não seria melhor introduzir filtros _async_ personalizados para eventos?

+1

apenas o comportamento de sincronização - não seria melhor introduzir filtros assíncronos personalizados para eventos?
@dvv

Estou bastante interessado nesta ideia.

algumas das escolhas EE2 não são o que eu consideraria ideais, mas eu +1 a ideia geral disso, mesmo se apenas "*" for compatível

verdadeiramente abrangente: manager.on("event", function(client, event, data) {} - também permitirá reduzir o número de fechamentos

não me lembro de nenhuma resistência em apenas adicionar um ouvinte genérico, o único debate de que me lembro é se usamos ou não "*" ou se escolhemos outro nome de método como .addGlobalListener ()

+1
Eu também precisaria de uma maneira de interceptar todos os eventos e ter o manipulador específico para dar uma olhada neles, apenas depois de terminar de processá-los. Principalmente para fins de registro, isso seria necessário. O logger do Socket.io atualmente só se loga no console, e de uma maneira muito correta.
A abordagem dvv -s é realmente do meu agrado.
Na verdade, talvez seja uma boa idéia retransmitirmos o evento para qualquer manipulador específico, e apenas obteremos todos os eventos, conforme descrito por dvv.

Por favor, coloque este problema em ação :)
Adoraria ver esse recurso implementado.

Bem, ok, acabei de adicionar EE2 a um branch em meu fork: https://github.com/einaros/socket.io/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

A filial está em: https://github.com/einaros/socket.io/commits/ee2

Os pensamentos são muito bem-vindos.

se EE2 se livrar dos nomes de métodos estranhos e adicionar .on('*') eu marcaria com +1

Eu sou -1 em EE2

Isso adiciona mais inchaço ao código, também precisamos oferecer suporte no lado do cliente. O que significa que teríamos que enviar uma biblioteca extra de 11,8 KB (minimizada ~ 3,5 kb). Mas, com o mercado móvel que se aproxima, gostaria de economizar o máximo de bytes possível.

Se isso for realmente apenas para ter um curinga / capturar todos os ouvintes ... Então, isso deve ser feito substituindo a função emit existente que apenas faz uma chamada extra para um ouvinte all . Isso seria como uma mudança de 3 - 5 LOC (excluindo comentários;)). E deve ser escondido atrás de um bloqueio de preferência, pois influencia o desempenho. EventEmitting é um caminho de código quente e deve ser sempre o mais ideal e rápido possível. Adicionar curingas prejudicará o desempenho.

catch-all é definitivamente a parte mais importante, é fácil o suficiente para ativar o evento depois disso, se necessário

Realmente não me importo com curingas, ou EE2, mas uma maneira de interceptar todos os eventos é uma obrigação.

se EE2 ... adiciona .on ('*') Eu marcaria com +1

TJ seu mano doido ...

server.on('foo.*', function(value1, value2) {
  console.log(this.event, value1, value2);
});

Isso é do README do EE2. Naturalmente, o "foo". é opcional.

se EE2 se livrar dos nomes de métodos estranhos

Eu concordo.

@pyrotechnick o EE2 .on('*') não é um iirc pega-tudo

* não é pega-tudo no sentido de que captura cegamente todos os eventos, mas efetivamente captura todos os eventos, uma vez que o padrão * corresponde a todos os canais.

É ineficiente; mas funciona conforme o esperado.

Eu estava errado. Você tem razão...

{EventEmitter2} = require 'eventemitter2'

emitter = new EventEmitter2 wildcard: on

emitter.on '*', ->
  console.log <strong i="6">@event</strong>, arguments...

emitter.emit 'foo'
emitter.emit 'foo.bar'

isabel:hydrogen pyrotechnick$ coffee test.coffee 
foo

Eu quase prefiro esse comportamento quando se trata de curingas.

Quando eu penso sobre todas essas coisas de curingas / eventos com espaço de nomes, fico triste; JavaScript já tem uma maneira fantástica de combinar padrões - eles vivem em // ou são construídos com RegExp . Isso é muito lento?

Posso marcar com +1 a importância disso novamente. Eu adoraria ver isso em um próximo lançamento.

Alguém postou uma solução aqui: http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Isso não funciona porque ainda não consigo me conectar ao evento. No meu aplicativo o servidor não sabe o nome da sala do cliente. Portanto, quero ser capaz de responder a todas as mensagens de qualquer sala e, de preferência, descobrir o nome da sala para a qual a mensagem foi enviada.

Adicione suporte a expressões regulares para eventos .. desta forma, intervalos de verbos e substantivos podem ser capturados.

+1

+1

+1

+1

+1

Eu adoraria um método super global que tratasse de tudo

io.set ('global_listener', function (namespace, event, args, emit) {
// faz algo com base em argumentos e eventos de namespace
// Posso ou não chamar emit () para chamar ouvintes de eventos vinculados a esse namespace e aquele evento
});

io.set ('global_authorization', function (namespace, handshakeData, callback) {
// com base no namespace e handshakeData aceita ou não a conexão
});

Eu precisava de um emissor que suportasse catch-alls a. la. socket.on("*") trabalhava no cliente e ainda era leve. Então peguei o emissor da @visionmedia do UI Kit e o estendi um pouco. Talvez fosse um ajuste decente para isso. Então, vale a pena. Vou deixar aqui: https://github.com/HenrikJoreteg/wildemitter

@HenrikJoreteg
Podemos adicionar '*' pronto para uso em https://github.com/component/emitter.
Além disso, esse emissor irá alimentar o próximo socket.io. Inclui um off atalho para removeListener que é bom: D

oh, incrível!

+1

++

+1

+1

+1

+1

+ = 1

+1

+1

+1

+1

Alguém já trabalhou nisso? Qualquer tipo de trilha?

Eu tenho um _tipo de_ solução que funcionou bem o suficiente para os propósitos para os quais precisávamos, mas não é uma solução curinga completa ... mais como uma implementação de '*'

https://github.com/Attorney-Fee/socket.io

+1

+1

+1

+1

+1

+1

Odeio deixar um comentário que não contribui com nada de significativo, mas isso já é solicitado há 2 anos, e tudo de construtivo já foi dito. Então...

+1

Isso seria bastante fácil de adicionar no espaço do usuário, não vejo a necessidade de tê-lo na base de código principal. Se eu puder ajudar com quaisquer ganchos para tornar mais fácil estender a funcionalidade do emissor de evento sem muitos macacos patching, terei prazer em fazê-lo.

Como isso seria implementado no userland? Todas as soluções que vi envolvem a bifurcação da base de código, e algumas pessoas criaram links para bibliotecas diferentes.

No meu caso, só preciso de um simples e claro "pegar absolutamente tudo em uma função", mas o suporte RegEx não parece (para um cara que não olhou a fonte muito de perto) muito difícil e certamente seria incrivelmente útil . Eu uso expressões regulares em minhas rotas Express.JS o tempo todo; seria bom poder fazer o mesmo no socket.io.

A camada / protocolo de transporte permaneceria inalterado. Você simplesmente substituiria 'emit' em ambas as extremidades para não simplesmente fazer uma pesquisa no mapa, mas uma pesquisa mais abrangente (baseada em regexp).

Sugestões de implementação rápida:

• Substitua on para manter uma estrutura de dados especial para as expressões regulares quando '*' for encontrado no nome do evento
• Substitua emit para primeiro fazer o caso rápido (pesquisa de mapa normal), depois vá até os ouvintes '*' e veja se eles correspondem.

Obviamente, isso não requer um garfo. O que quero dizer com ganchos é que podemos potencialmente encontrar uma solução para não exigir o patch de macaco, mas considerando que esses 2 são métodos bastante simples, não considero isso um grande problema.

Só por curiosidade, não poderíamos simplesmente substituir o socket.Manager.prototype.onClientMessage do userland?

Eu fiz isso e funcionou bem, no nó, sem alterações no módulo socket.io. Não muito bonito e com probabilidade de quebrar, mas pelo menos você evita bifurcação.

https://gist.github.com/lmjabreu/5714985

Não se poderia simplesmente adicionar process.EventEmitter = require('eventemitter2').EventEmitter2 algum lugar antes que o socket.io seja necessário? Isso parece funcionar para mim...

Abrir o protótipo definitivamente não é uma solução para o usuário. Eu entendo que não querer implementar suporte completo a regex ou qualquer coisa que não seja um simples socket.on ('*') seria uma grande ajuda.

Este bilhete já tem 2 anos.

Existem planos para lidar com isso, já que é um recurso claramente útil?

Se a resposta for não, eu gostaria de bifurcar e adicionar eu mesmo.
Mas eu preferiria fazer isso apenas se houver probabilidade de ser mesclado de volta ao upsteam.

Algum desenvolvedor pode responder isso, por favor?

De acordo com quase todos os comentários, coisas sofisticadas podem ser mais ou menos discutíveis, mas um pega-tudo seria bom. Os usuários podem fazer isso sozinhos, mas um procedimento predefinido seria mais limpo.

É uma pena que isso não exista.

Ele existe, veja o link que alguém postou anteriormente
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Estou usando isso e funciona muito bem :)

+1

Fazer monkey patching para algo simples como isso parece, para mim, algo como uma prática ruim, no entanto, acho que nenhuma grande implementação deve ser usada, algo simples como Backbone.Events será suficiente para a maioria dos desenvolvedores neste problema, Eu penso. (embora o Backbone não use "*", mas "all" para o evento global, passando o nome do evento originalmente chamado, que é a melhor coisa a se fazer). (é apenas uma sugestão, no entanto) =)

Pessoalmente, +1 no modo RegExp, parece mais Javascript e menos console quando comparado com o curinga "*" .

Mas, como as vozes mais recentes, uma função pega-tudo parece mais adequada.

Não tenho certeza se este é realmente um problema de socket.io.

Uma API congelada para culpar IMO.

: +1:

Caso alguém leia este tópico e ainda esteja procurando uma maneira de usar eventos curinga em 0.9.xe 1.0.0: https://www.npmjs.org/package/socketio-wildcard

Maravilhoso @geoah !

@guille hehe, não é meu. Acabei de topar com ele. obrigado por todo o seu trabalho árduo btw ^ _ ^

Produzi um middleware para socket.io na noite passada.

https://www.npmjs.org/package/socket.io-events

+1
Seria bom reduzir a sobrecarga da criação de novos ouvintes quando os dados sempre serão tratados da mesma forma.
@geoah Obrigado pelo middleware, fiz exatamente o que eu precisava!

Se o middleware funcionar bem, o socket.io deve permanecer como está.

Essa é uma das coisas que eu pessoalmente acho que faz todo o sentido como parte do próprio socket.io. Não vejo nenhum argumento para deixá-lo de fora, exceto "não é assim que as coisas são feitas por aqui", o que nunca é um argumento muito bom.

O argumento é que tentamos trabalhar como o nó EventEmitter , e o nó não tem isso, então se tornaria um "socket.io-ismo". Houve extensas discussões no Node sobre como adicioná-lo, mas ele não foi aprovado.

@chevex Embora originalmente essa fosse a minha

Esses são argumentos muito melhores. Eu acho que você não gostaria que o EventEmitter se comportasse de maneira diferente do nó por padrão. E @ DanH42 também suponho que você esteja certo ao dizer que aumentá-lo com middleware faz mais sentido para quem precisa. Retiro minha declaração :)

Se apenas o EventEmitter do nó suportasse curingas prontos para uso.

: +1:

Vejo que perdi esses problemas, comecei um novo problema de encaminhamento de eventos:
https://github.com/Automattic/socket.io/issues/1715
Inclui duas maneiras de lidar com todos os eventos do socket.io 1.0 sem alterar sua fonte.

Eu só quero isso para depuração. Não tenho autoridade para adicionar ou modificar bibliotecas em nosso projeto. :soluço:

+1
Às vezes, você precisa saber todos os eventos que estão se propagando!

+1

• 1

Acabei usando o módulo socketio-wildcard de

Obrigado Matt! Tenho estado atolado, mas espero ter um fim de semana para fazer alguns
melhorias

Enviado do meu iPhone

Em 6 de janeiro de 2015, às 8h30, Matt Fletcher [email protected] escreveu:

Acabei usando @NathanGRomano https://github.com/NathanGRomano's
módulo socketio-events https://www.npmjs.com/package/socket.io-events ; isto
parece o método mais transparente (usando middleware) e funciona bastante
bem para mim. Mas [imagem:: +1:] para colocar isso no núcleo!

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750.

+1

+1

++++++

+1 seria útil para depuração.

Se for uma questão de alguém apenas trabalhando nisso, gostaria de tentar. Precisarei de alguns para aprender a base de código socket.io e provavelmente passarei algum tempo examinando outras implementações desse tipo. O que você acha dos padrões regex? Muito devagar? Claro, não vou perder meu tempo se não for algo que seria considerado para uma fusão (não me importo se minha implementação for rejeitada, mas se não houver interesse, então por que se preocupar, certo?). Um mantenedor pode aconselhar?

Eu escrevi uma biblioteca socket.io-events. Tenho estado atolado de trabalho e necessidade
para tocá-lo novamente. Gostaria de apoiar os agradecimentos com isso

No sábado, 25 de julho de 2015, John Manko [email protected] escreveu:

Se for uma questão de alguém apenas trabalhando nisso, gostaria de dar um
tomada. Vou precisar de alguns para aprender a base de código socket.io, e provavelmente
passe algum tempo examinando outras implementações desse tipo. Quais são seus
pensamentos sobre padrões regex? Muito devagar? Claro, eu não vou desperdiçar meu
tempo, se não for algo que seria considerado para uma fusão (eu não
me importo se minha implementação for rejeitada, mas se não houver interesse, então por que
incomoda, certo?). Um mantenedor pode aconselhar?

-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/socketio/socket.io/issues/434#issuecomment -124901706.

+1

+1 esta edição está acontecendo há 5 anos. Por que o suporte a curinga não foi adicionado, novamente?

+1

+1

+1

+1

+666

+1

Caras, sério. Todo mundo quer esse recurso - acho que eles conseguiram. Vamos todos parar com os mais-uns, por favor? Prefiro receber um e-mail de atualização quando houver algum progresso real com o problema.

Dito isso, é útil saber que muitas pessoas estão interessadas.
Acho que o ideal é que o GitHub tenha um sistema de votação.

Um sistema de votação seria ótimo, mas não parece provável que aconteça tão cedo.

Acho que o problema é que uma solução foi postada muitas vezes agora, mas rola para fora de vista por causa de todos os comentários +1.

O módulo socketio-wildcard tem funcionado bem para mim (admito que ainda não atualizei para o nó mais recente).
Seria útil se alguém pudesse explicar por que essa biblioteca não é adequada?

Sim, socketio-wildcard funciona perfeitamente bem, mas ainda é uma dependência extra que é tão simples que seria bom ser introduzido no core e encerrar todo este tópico de problema de uma vez por todas. Além disso, elimina qualquer espaço para confusão sobre qual é o melhor módulo externo a ser usado (muitas vezes com nome semelhante). Também concordo que seria bom se o GitHub tivesse um sistema de votação, se ao menos houvesse uma maneira de votar nele ...!

Posso ser burro, mas não tenho ideia de como configurar socketio-wildcard com objetos de cliente IO. Isso deve ser sério, _seriamente_ ser incluído no núcleo. Se os mantenedores do socket.io não quiserem fazer isso, alguém deveria apenas fazer um fork deste projeto e todos nós poderíamos mudar para lá, porque isso é simplesmente ridículo e eu honestamente não tenho confiança no socket.io agora.

Eu entendo que os mantenedores não precisam aceitar todas as propostas, mas isso? Isso me deixa totalmente perplexo. Muito bem.

@ n2liquid não está tão claro se isso deveria estar no núcleo, mas a discussão é bem-vinda. Por exemplo, nenhum outro emissor de evento do Node se comporta dessa maneira, embora uma discussão também tenha ocorrido lá.

@rauchg

não é tão claro que isso deveria estar no centro, mas a discussão é bem-vinda

Podemos ter uma discussão sobre isso então?

Posso entender seu ponto de que esse tipo de emissor não é necessariamente comum no mundo dos nós, mas depende do que você está tentando alcançar ....
A ideia é seguir estritamente as convenções ou fornecer uma biblioteca realmente útil?

Parece claro que muitos usuários de socket.io estão realmente tropeçando sem que esse recurso esteja no núcleo, e parece razoável para um usuário esperar que assim seja.

Ou, em outras palavras, quais são os argumentos para NÃO fornecer esse recurso no socket.io?
Mesmo que a implementação não seja 'correta como o livro-texto', resultaria em uma maneira padrão de implementar esses manipuladores 'catchall' no socket.io, em vez de as pessoas precisarem recorrer a várias bibliotecas e métodos diferentes.
Direcionar pessoas para uma biblioteca ou solução alternativa apenas fragmenta as coisas e torna ainda mais frágil tentando manter uma base de código que usa socket.io

Eu preferiria que houvesse uma maneira formal de lidar com pacotes genéricos e, se precisar ser alterado posteriormente, pelo menos pode haver um procedimento de migração recomendado, em vez de apenas deixar que o usuário encontre sua própria rota através da selva

@rauchg Acho que uma maneira legal de implementar isso seria ter uma função socket.use(function(data,next){..}) que captura todos os eventos no soquete e é passada uma função next () que passa o controle do catchall para os catchalls subsequentes ou manipuladores de eventos padrão .

É assim que estou usando o socket.io agora, porque precisava de uma maneira de limitar a quantidade de eventos que chegam por / minuto, o que acredito ser um caso de uso comum. Obrigado por ler meus 2 centavos.

Gosto mais da solução de @Michael77 . Ele não afeta as interfaces ou implementação do emissor de evento e até permite mais coisas do que estamos pedindo aqui (por exemplo, a implementação de limitação de mensagem de @Michael77 e quem sabe o que mais).

Eu sei que há uma função de middleware / use no socket.io, mas não pode ser usada na biblioteca do cliente e não tenho certeza se serve para o mesmo propósito.

@carpii sempre há grandes razões para _não_ apoiar algo: adicionar complexidade, reduzir familiaridade. Este recurso desmarca ambos.

Eu gosto muito da ideia socket.use , além da qual pode-se facilmente implementar a extensão curinga no cliente.

Obrigado @carpii @ Michael77 @ n2liquid por seus comentários sobre este btw.

@rauchg , lamento ter dito aquelas coisas ruins sobre socket.io. Eu estava tendo um dia ruim. Obrigado por este projeto; pode não ser perfeito (ainda), mas com certeza é muito útil.

Além disso: https://github.com/hden/socketio-wildcard/issues/13

@ n2liquid _todos_ os comentários são bem-vindos - obrigado (e a @hden por essa solução rápida no socket.io-wildcard ).

scoketio-wildcard parece uma solução perfeitamente válida. Também desejei obter o nome do evento no retorno de chamada, para que pudesse envolver o ouvinte do soquete e propagar eventos através do invólucro, em vez de expor diretamente o soquete para o resto do meu aplicativo. Meu entendimento é que isso exigiria o Emissor de evento 2 se eu quisesse fazer isso com um curinga. Isso é apenas algo bobo de se fazer, melhor expor diretamente o soquete? Algo baseado na escuta de 'newListener' no invólucro (mas não sabe como disparar no evento de soquete, apenas como registrar o evento de soquete com base nas funções de chamada que registram um novo evento no invólucro)? Alguém mais interessado em acessar o nome do evento no retorno de chamada?

@akotlar O nome do evento está disponível no retorno de chamada se você estiver usando o scoketio-wildcard.

Ah, obrigado! Pode ser útil especificar isso no leiame socket.io-wildcard.

como está indo?
+1 para on("*", function () { para cliente e servidor

+1 em todo o caminho

@ alexey-sh @ emin93 Se você pudesse ler o documento em https://github.com/hden/socketio-wildcard , sim, é possível fazer isso tanto para o cliente quanto para o servidor.

@hden Obrigado e sim, eu vi isso e já estou usando. Mas é uma dependência extra e nada fala contra integrá-lo diretamente no núcleo Socket.IO, é por isso que ele recebe um +1 de mim.

Ele pode ser tratado na lógica do aplicativo usando um nome de evento para todos os eventos:

socket.emit('public-event', {'type': 'login', ...});
socket.emit('public-event', {'type': 'logout', ...});

1 mesmo que o problema esteja encerrado.

+ 💯 bang!

+1 !!!!

Use socket.use .

Existe uma maneira de conectar no mecanismo PING / PONG do engine.io usando socket.use ()?

Estou tendo um problema em que muitos usuários estão perdendo a conexão e, apesar do extenso logon no servidor, apenas informa que eles desconectaram devido ao tempo limite de ping.

Gostaria de registrar os pacotes PING / PONG, mas parece que socket.use () só pode se conectar às mensagens de evento de usuário de alto nível, e não ao protocolo subjacente de engine.io

+1

+1

+1 desde 2011? Eles não estão fazendo isso. :(

Novamente, socket.use foi adicionado para esse assunto: https://socket.io/docs/server-api/#socket -use-fn

@darrachequesne Não vejo como um método no lado do servidor ajuda com essa solicitação (que é para o cliente).

Mais alguma coisa sobre isso? Já que socket.use é apenas para o servidor, por que este tíquete está fechado?

Não entendo socket.use . Como substituir

// Server
io.in('room1').emit('backend', data_out);
io.in('room1').emit('frontend', data_out);

com algo como

// Server
io.in('room1').emit('*end', data_out);  // not working code - proper regex would be nice

ou

// Client
socket.on('*end', function(data){  // not working code - proper regex would be nice

Encontrou uma pequena solução alternativa - listando todas as possibilidades:

// Client
var lala = function(data){ 
    // example
}
socket.on('backend', lala);
socket.on('frontend', lala);