Socket.io: Ajout de la prise en charge des caractères génériques pour les événements

D'accord.

Émetteur d'événement2

+1
Cela nous permettrait de créer des filtres et que pas pour tous les événements.

• une autre dépendance
• doit être reflété côté client (code ?)
• le fourre-tout doit-il être appelé avant un événement particulier ? ou dans l'ordre de définition ? éclaircissements nécessaires
• uniquement le comportement de synchronisation - ne serait-il pas préférable d'introduire des filtres _async_ personnalisés pour les événements ?

+1

uniquement le comportement de synchronisation - ne serait-il pas préférable d'introduire des filtres asynchrones personnalisés pour les événements ?
@dvv

Je suis assez intéressé par cette idée.

certains des choix EE2 ne sont pas ce que je considère comme idéaux mais je +1 l'idée générale de cela, même si seul "*" est pris en charge

vraiment fourre-tout : manager.on("event", function(client, event, data) {} -- permettra également de réduire le nombre de fermetures

je ne me souviens d'aucune résistance à l'ajout d'un écouteur fourre-tout, le seul débat dont je me souviens était de savoir si nous utilisions ou non "*" ou si nous utilisions un autre nom de méthode comme .addGlobalListener()

+1
Moi aussi, j'aurais besoin d'un moyen d'intercepter tous les événements et de demander au gestionnaire spécifique de les examiner, une fois que j'ai fini de les traiter. Cela serait nécessaire principalement à des fins de journalisation. L'enregistreur Socket.io ne se connecte actuellement qu'à la console, et de manière très auto-juste.
L'approche dvv -s est vraiment à mon goût.
En fait, ce serait peut-être une bonne idée de nous faire relayer l'événement à n'importe quel gestionnaire spécifique, et nous n'obtiendrons que tous les événements, comme décrit par dvv.

S'il vous plaît, faites bouger ce problème :)
J'adorerais voir cette fonctionnalité implémentée.

Bon, ok, je viens d'ajouter EE2 à une branche dans mon fork : https://github.com/einaros/socket.io/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

La succursale est à : https://github.com/einaros/socket.io/commits/ee2

Les pensées sont les bienvenues.

si EE2 se débarrasse des noms de méthodes étranges et ajoute .on('*') je donnerais +1 à cela

Je suis un -1 sur EE2

Cela ajoute plus de poids au code, nous devons également le prendre en charge côté client. Ce qui signifie que nous devrions expédier une bibliothèque supplémentaire de 11,8 Ko (minifiée ~3,5 Ko). Mais avec le marché mobile à venir, j'aimerais économiser autant d'octets que possible.

S'il ne s'agit vraiment que d'avoir un caractère générique/attraper tous les écouteurs.. Alors cela devrait être fait en remplaçant la fonction d'émission existante qui fait juste un appel supplémentaire à un écouteur all . Ce serait comme un changement de 3 - 5 LOC (hors commentaires ;)). Et devrait être caché derrière un verrou de préférence car il influence les performances. EventEmitting est un chemin de code chaud et doit toujours être aussi optimal et rapide que possible. L'ajout de caractères génériques dégradera les performances.

le fourre-tout est certainement la partie la plus importante, il est assez facile d'activer l'événement après cela si nécessaire

Ne vous souciez pas vraiment des caractères génériques, ou EE2, mais un moyen d'intercepter tous les événements est un must.

si EE2 ... ajoute .on('*') je lui donnerais +1

TJ t'es fou frère...

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

C'est du README de EE2. Naturellement, le "foo". est facultatif.

si EE2 se débarrasse des noms de méthodes étranges

Je suis d'accord.

@pyrotechnick l'EE2 .on('*') n'est pas un iirc fourre-tout

* n'est pas un fourre-tout dans le sens où il capture aveuglément tous les événements, mais il capture effectivement tous les événements puisque le modèle * correspond à tous les canaux.

C'est inefficace; mais cela fonctionne comme prévu.

Je me trompais. Tu as raison...

{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

Je préfère presque ce comportement en ce qui concerne les caractères génériques.

Quand je pense à tous ces événements génériques/"espaces de noms", cela me rend un peu triste; JavaScript a déjà un moyen fantastique de faire correspondre les modèles - ils vivent dans // ou sont construits avec RegExp . Est-ce juste trop lent ?

Puis-je à nouveau attribuer +1 à l'importance de cela. J'aimerais voir cela dans une prochaine version.

Quelqu'un a posté une solution ici : http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Cela ne fonctionne pas car je n'arrive toujours pas à me connecter à l'événement. Dans mon application, le serveur ne connaît pas le nom de la salle du client. Je veux donc pouvoir répondre à tous les messages pour n'importe quelle pièce et idéalement connaître le nom de la pièce sur laquelle le message a été envoyé.

Ajoutez la prise en charge des expressions régulières pour les événements. De cette façon, des plages de verbes et de noms peuvent être détectées.

+1

+1

+1

+1

+1

Je serais friand d'une méthode super globale qui gère tout

io.set('global_listener', function(espace de noms, événement, arguments, émettre){
// faire quelque chose en fonction de l'événement et des arguments de l'espace de noms
// Je peux ou non appeler émet() pour appeler des écouteurs d'événement liés à cet espace de noms et à cet événement
});

io.set('global_authorization', function(namespace, handshakeData, callback){
// basé sur l'espace de noms et handshakeData accepte ou non la connexion
});

J'avais besoin d'un émetteur prenant en charge les fourre-tout a. la. socket.on("*") , a travaillé sur le client et était toujours léger. J'ai donc pris l'émetteur de @visionmedia de UI Kit et je l'ai un peu étendu. Peut-être que ce serait un ajustement décent pour cela. Donc, pour ce que ça vaut. Je vais juste laisser ça ici : https://github.com/HenrikJoreteg/wildemitter

@HenrikJoreteg
Nous pourrions ajouter '*' prêt à l' emploi à
De plus, cet émetteur va alimenter le prochain socket.io. Il inclut un off raccourci vers removeListener ce qui est sympa :D

oh, génial !

+1

++

+1

+1

+1

+1

+=1

+1

+1

+1

+1

Quelqu'un a-t-il déjà travaillé dans ce sens ? N'importe quel type de piste ?

J'ai une _sorte de_ solution qui a assez bien fonctionné pour les besoins pour lesquels nous en avions besoin, mais ce n'est pas une solution générique complète... plutôt une implémentation de '*'

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

+1

+1

+1

+1

+1

+1

Je déteste laisser un commentaire qui n'apporte rien de significatif, mais cela est demandé depuis 2 ans maintenant, et tout ce qui est constructif a déjà été dit. Donc...

+1

Ce serait assez facile à ajouter dans l'espace utilisateur, je ne vois pas la nécessité de l'avoir dans la base de code principale. Si je peux aider avec des crochets pour faciliter l'extension de la fonctionnalité d'émetteur d'événements sans trop de correctifs, je le ferai avec plaisir.

Comment cela serait-il mis en œuvre dans l'espace utilisateur ? Toutes les solutions que j'ai vues impliquent de bifurquer la base de code, et certaines personnes se sont liées à différentes bibliothèques.

Dans mon cas, j'ai seulement besoin d'un simple "attraper absolument tout dans une seule fonction", mais la prise en charge de RegEx ne semble pas (pour un gars qui n'a pas regardé la source de trop près) trop difficile, et serait certainement incroyablement utile . J'utilise des expressions régulières dans mes routes Express.JS tout le temps ; ce serait bien de pouvoir faire la même chose dans socket.io.

La couche de transport / le protocole resterait inchangé. Vous remplaceriez simplement « emit » aux deux extrémités pour ne pas simplement faire une recherche de carte, mais une recherche plus complète (basée sur les expressions régulières).

Suggestions de mise en œuvre rapide :

• Remplacez on pour maintenir une structure de données spéciale pour les expressions régulières lorsque '*' est trouvé dans le nom de l'événement
• Remplacez emit pour faire d'abord le cas rapide (recherche de carte régulière), puis passez par les écouteurs '*' et voyez s'ils correspondent.

Évidemment, cela ne nécessite pas de fourchette. Ce que je voulais dire par crochets, c'est que nous pouvons potentiellement trouver une solution pour ne pas nécessiter le patch singe, mais étant donné que ces 2 méthodes sont assez simples, je ne considère pas cela comme un gros problème.

Juste par curiosité, ne pourrions-nous pas simplement remplacer le socket.Manager.prototype.onClientMessage de l'espace utilisateur ?

Je l'ai fait et j'ai très bien fonctionné, dans le nœud, aucune modification du module socket.io. Pas très joli et susceptible de casser mais au moins vous évitez de bifurquer.

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

Ne pourrait-on pas simplement ajouter process.EventEmitter = require('eventemitter2').EventEmitter2 quelque part avant que socket.io ne soit requis ? Cela semble fonctionner pour moi...

L'ouverture du prototype n'est certainement pas une solution pour l'utilisateur. Je comprends que ne pas vouloir implémenter la prise en charge complète des regex ou autre chose qu'un simple socket.on('*') irait un long chemin.

Ce billet a maintenant 2 ans.

Existe-t-il des plans pour y remédier, car il s'agit clairement d'une fonctionnalité utile ?

Si la réponse est non, j'aimerais l'ajouter moi-même.
Mais je préférerais ne le faire que s'il est probable qu'il soit fusionné en amont.

Des développeurs peuvent-ils répondre à cela s'il vous plaît?

D'accord avec presque tous les commentaires, les trucs fantaisistes peuvent être plus ou moins discutables, mais un fourre-tout serait bien. Les utilisateurs peuvent le faire eux-mêmes, mais une procédure prédéfinie serait plus propre.

C'est dommage que cela n'existe pas.

Il existe, voir le lien que quelqu'un a posté plus tôt
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Je l'utilise et ça marche très bien :)

+1

Faire un patch singe vers quelque chose de simple comme ça me semble être quelque chose comme une mauvaise pratique, cependant, je pense qu'aucune grande implémentation ne devrait être utilisée, quelque chose de simple comme Backbone.Events sera suffisant pour la plupart des développeurs dans ce problème, Je pense. (bien que Backbone n'utilise pas "*", mais "all" pour l'événement global, en passant le nom de l'événement appelé à l'origine, ce qui est la meilleure chose à faire). (c'est juste une suggestion, cependant) =)

Personnellement +1 à la manière RegExp, cela donne plus de Javascript et moins de console par rapport au caractère générique "*" .

Mais à l'instar des dernières voix, une fonction fourre-tout semble plus adaptée.

Je ne sais pas s'il s'agit réellement d'un problème de socket.io.

Une API gelée à blâmer IMO.

:+1:

Au cas où quelqu'un lit ce fil et cherche toujours un moyen d'utiliser des événements génériques sur 0.9.x et 1.0.0 : https://www.npmjs.org/package/socketio-wildcard

Merveilleux @geoah !

@guille hehe, ce n'est pas à moi je viens de tomber dessus. merci pour tout votre travail acharné d'ailleurs ^_^

Hier soir, j'ai créé un middleware pour socket.io.

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

+1
Ce serait bien de réduire la surcharge de création de nouveaux écouteurs lorsque les données seront toujours gérées de la même manière.
@geoah Merci pour le middleware, j'ai fait exactement ce dont j'avais besoin !

Si le middleware fonctionne correctement, socket.io devrait rester tel quel.

C'est l'une de ces choses qui, personnellement, me semblent parfaitement logiques dans le cadre de socket.io lui-même. Je ne vois aucun argument pour le laisser de côté, sauf "ce n'est pas comme ça que les choses sont faites ici", ce qui n'est jamais un très bon argument.

L'argument est que nous essayons de travailler comme le nœud EventEmitter , et que le nœud ne l'a pas, il deviendrait donc un "socket.io-ism". Il y a eu de longues discussions dans Node sur son ajout et cela n'a pas abouti.

@chevex Bien que ce soit aussi mon sentiment à l'origine, le nouveau support de middleware le rend assez facile à ajouter par vous-même. En regardant socketio-wildcard comme exemple, il est très simple à importer et à utiliser ; ça finira probablement par être comme express.js où il y a quelques morceaux de middleware que j'inclus presque toujours.

Ce sont de bien meilleurs arguments. Je suppose que vous ne voudriez pas que EventEmitter se comporte différemment du nœud par défaut. Et @ DanH42, je suppose également que vous avez raison de dire que l'augmenter avec un middleware est plus logique pour ceux qui en ont besoin. Je retire ma déclaration :)

Si seul l'EventEmitter du nœud prenait en charge les caractères génériques prêts à l'emploi.

:+1:

Je vois que j'ai raté ce problème, j'ai commencé un nouveau problème sur le transfert d'événements :
https://github.com/Automattic/socket.io/issues/1715
Il comprend deux façons de gérer tous les événements de socket.io 1.0 sans altérer sa source.

Je veux juste ça pour le débogage. Je n'ai pas le droit d'ajouter ou de modifier des bibliothèques dans notre projet. :sanglot:

+1
Parfois, il faut connaître tous les événements qui se propagent !

+1

• 1

J'ai fini par utiliser le module socketio-wildcard de

Merci Matt ! J'ai été submergé mais j'espère avoir un week-end pour en faire
améliorations

Envoyé de mon iPhone

Le 6 janvier 2015, à 8h30, Matt Fletcher [email protected] a écrit :

J'ai fini par utiliser @NathanGRomano https://github.com/NathanGRomano 's
module socketio-events https://www.npmjs.com/package/socket.io-events ; ce
semble la méthode la plus transparente (en utilisant un middleware) et fonctionne assez
bien pour moi. Mais [image: :+1:] pour l'avoir intégré au noyau !

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/Automattic/socket.io/issues/434#issuecomment-68864750 .

+1

+1

+++++++

+1 serait utile pour le débogage.

S'il s'agit de quelqu'un qui travaille juste là-dessus, j'aimerais essayer. J'en aurai besoin pour apprendre la base de code socket.io, et je vais probablement passer du temps à regarder d'autres implémentations de ce type. Que pensez-vous des modèles de regex? Trop lent? Bien sûr, je ne vais pas perdre mon temps si ce n'est pas quelque chose qui serait envisagé pour une fusion (je me fiche que mon implémentation soit rejetée, mais s'il n'y a pas d'intérêt alors pourquoi s'embêter, non ?). Un mainteneur peut-il conseiller?

J'ai écrit une bibliothèque socket.io-events. J'ai été submergé par le travail et le besoin
pour le toucher à nouveau. Je voudrais soutenir les remerciements avec elle

Le samedi 25 juillet 2015, John Manko [email protected] a écrit :

S'il s'agit simplement de quelqu'un qui travaille là-dessus, j'aimerais lui donner un
tirer. J'en aurai besoin pour apprendre la base de code socket.io, et je vais probablement
passer du temps à examiner d'autres implémentations de ce type. Quels sont vos
réflexions sur les modèles de regex? Trop lent? Bien sûr, je ne vais pas perdre mon
temps si ce n'est pas quelque chose qui serait considéré pour une fusion (je ne
attention si ma mise en œuvre est rejetée, mais s'il n'y a pas d'intérêt alors pourquoi
dérange, non?). Un mainteneur peut-il conseiller?

-
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/socketio/socket.io/issues/434#issuecomment-124901706 .

+1

+1 ce problème dure depuis 5 ans. Pourquoi la prise en charge des caractères génériques n'a-t-elle pas encore été ajoutée ?

+1

+1

+1

+1

+666

+1

Les gars, sérieusement. Tout le monde veut cette fonctionnalité - je pense qu'ils l'obtiennent. Arrêtons tous avec les plus-un, s'il vous plaît ? Je préfère recevoir un e-mail de mise à jour lorsqu'il y a des progrès réels avec le problème.

Cela dit, il est utile de savoir que de nombreuses personnes sont intéressées.
Je pense qu'idéalement GitHub devrait avoir un système de vote ?

Un système de vote serait formidable, mais ne semble pas susceptible de se produire de si tôt.

Je suppose que le problème est qu'une solution a été publiée plusieurs fois maintenant, mais défile hors de vue à cause de tous les commentaires +1.

Le module socketio-wildcard a bien fonctionné pour moi (il est vrai que je n'ai pas encore mis à jour le dernier nœud).
Ce serait utile si quelqu'un pouvait expliquer pourquoi cette lib ne convient pas ?

Oui, socketio-wildcard fonctionne parfaitement bien, mais c'est toujours une dépendance supplémentaire qui est si simple qu'il serait bien d'être introduit dans le noyau et de mettre fin à tout ce fil de discussion une fois pour toutes. De plus, cela supprime toute confusion quant au meilleur module externe à utiliser (souvent du même nom). Convenez également que ce serait bien si GitHub avait un système de vote, si seulement il y avait un moyen de voter dessus... !

Je suis peut-être stupide, mais je n'ai aucune idée de comment configurer socketio-wildcard avec des objets clients IO. Cela devrait sérieusement, _sérieusement_ être inclus dans le noyau. Si les mainteneurs de socket.io ne veulent pas le faire, quelqu'un devrait simplement bifurquer ce projet et nous pourrions tous y aller, car c'est tout simplement ridicule et honnêtement, je n'ai aucune confiance en socket.io maintenant.

Je comprends que les responsables ne sont pas obligés d'accepter toutes les propositions, mais ceci ? Cela me déconcerte totalement. Marche à suivre.

@n2liquid, il n'est pas aussi clair que cela devrait être dans le noyau, mais la discussion est la bienvenue. Par exemple, aucun autre émetteur d'événements Node ne se comporte de cette façon, même si une discussion a également eu lieu à ce moment-là.

@rauchg

ce n'est pas aussi clair que cela devrait être dans le noyau, mais la discussion est la bienvenue

Pourrions-nous avoir une discussion à ce sujet alors?

Je peux comprendre votre point selon lequel ce type d'émetteur n'est pas nécessairement courant dans le monde des nœuds, mais cela dépend de ce que vous essayez d'atteindre....
L'idée est-elle d'adhérer strictement aux conventions, ou de fournir une bibliothèque vraiment utile ?

Il semble clair que de nombreux utilisateurs de socket.io trébuchent vraiment sans que cette fonctionnalité ne soit dans le noyau, et il semble raisonnable pour un utilisateur de s'attendre à ce qu'il le soit.

Ou pour le dire autrement, quels sont les arguments pour NE PAS fournir cette fonctionnalité dans socket.io ?
Même si l'implémentation n'est pas « correcte pour les manuels », il en résulterait un moyen standard d'implémenter ces gestionnaires « attrape » dans socket.io, plutôt que des personnes ayant recours à de nombreuses bibliothèques et méthodes différentes.
Diriger les gens vers une bibliothèque tierce ou une solution de contournement ne fait que fragmenter les choses et le rend encore plus fragile en essayant de maintenir une base de code qui utilise socket.io

Je préférerais de loin qu'il y ait un moyen formel de gérer les paquets fourre-tout, et puis s'il doit être modifié plus tard, au moins il peut y avoir une procédure de migration recommandée, plutôt que de simplement laisser l'utilisateur trouver son propre itinéraire à travers le désert

@rauchg Je pense qu'un moyen sympa d'implémenter cela serait d'avoir une fonction socket.use(function(data,next){..}) qui intercepte tous les événements sur le socket, et passe une fonction next() qui passe le contrôle du catchall aux catchalls suivants ou aux gestionnaires d'événements par défaut .

C'est ainsi que j'utilise socket.io en ce moment, car j'avais besoin d'un moyen de limiter le nombre d'événements par minute, ce qui, je pense, est un cas d'utilisation courant. Merci d'avoir lu mes 2 cents.

J'aime le plus la solution de @ Michael77 . Cela ne touche pas les interfaces ou l'implémentation de l'émetteur d'événements et permet même plus de choses que ce que nous demandons ici (par exemple, l' implémentation de la limitation des messages de

Je sais qu'il existe une fonction middleware / use dans socket.io, mais elle n'est pas utilisable sur la bibliothèque cliente et je ne sais pas si elle sert le même objectif.

@carpii, il y a toujours de bonnes raisons de _pas_ prendre en charge quelque chose : ajouter de la complexité, réduire la familiarité. Cette fonctionnalité coche les deux.

J'aime beaucoup l'idée socket.use , en plus de laquelle on pourrait facilement implémenter l'extension wildcard sur le client.

Merci @carpii @Michael77 @n2liquid pour vos commentaires sur ce sujet.

@rauchg , je suis désolé d'avoir dit ces mauvaises choses à propos de socket.io. Je passais une mauvaise journée. Merci pour ce projet ; ce n'est peut-être pas parfait (encore), mais c'est certainement très utile.

Aussi : https://github.com/hden/socketio-wildcard/issues/13

Les commentaires de @n2liquid _all_ sont les bienvenus - merci (et à @hden pour cette solution rapide sur socket.io-wildcard ).

scoketio-wildcard semble être une solution parfaitement valable. Je me suis également retrouvé à vouloir obtenir le nom de l'événement dans le rappel, afin de pouvoir envelopper l'écouteur de socket et propager les événements via le wrapper, plutôt que d'exposer directement le socket au reste de mon application. Je crois comprendre que cela nécessiterait Event Emitter 2 si je voulais le faire avec un caractère générique. Est-ce juste une bêtise à faire, mieux vaut exposer directement le socket ? Quelque chose basé sur l'écoute de 'newListener' dans le wrapper (mais vous ne savez pas comment déclencher un événement de socket, uniquement comment enregistrer l'événement de socket en fonction des fonctions d'appel enregistrant un nouvel événement dans le wrapper) ? Quelqu'un d'autre souhaite-t-il pouvoir accéder au nom de l'événement dans le rappel ?

@akotlar Le nom de l'événement est disponible dans le rappel si vous utilisez scoketio-wildcard.

Ah merci! Il peut être utile de le spécifier dans le fichier readme socket.io-wildcard.

comment ça va?
+1 pour on("*", function () { pour le client et le serveur

+1 jusqu'au bout

@alexey-sh @emin93 Si vous voudriez bien lire le document de https://github.com/hden/socketio-wildcard , oui, il est possible de le faire à la fois pour le client et le serveur.

@hden Merci et oui j'ai vu ça et je l'utilise déjà. Mais c'est une dépendance supplémentaire et rien ne s'oppose à son intégration directement dans le noyau Socket.IO, c'est pourquoi il obtient un +1 de ma part.

Il peut être géré dans la logique de l'application en utilisant un nom d'événement pour tous les événements :

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

+1 même si le problème est clos.

+💯 boum !

+1 !!!!

Veuillez utiliser socket.use .

Existe-t-il un moyen de se connecter au mécanisme PING/PONG de engine.io en utilisant socket.use() ?

J'ai un problème où de nombreux utilisateurs perdent la connexion, et malgré une connexion étendue sur le serveur, il est simplement indiqué qu'ils se sont déconnectés en raison du délai d'expiration du ping.

J'aimerais enregistrer les paquets PING/PONG, mais il semble que socket.use() ne puisse se connecter qu'aux messages d'événement utilisateur de haut niveau, et non au protocole sous-jacent de engine.io

+1

+1

+1 depuis 2011 ? Ils ne le font pas. :(

Encore une fois, socket.use été ajouté d'ailleurs : https://socket.io/docs/server-api/#socket -use-fn

@darrachequesne Je ne vois pas en quoi une méthode côté serveur aide avec cette requête (qui est pour le client).

Plus à ce sujet ? Puisque socket.use est uniquement pour le serveur, pourquoi ce ticket est-il fermé ?

Je ne comprends pas socket.use . Comment remplacer

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

avec quelque chose comme

// 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

J'ai trouvé une petite solution de contournement - répertoriant toutes les possibilités :

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