I'm writing some 'shield' code in my node websocket server, so that if the client tries to send events which are out of state, the socket is disconnected.
But since socket.io handles their native events (like 'connecting', 'disconnected' etc) similar to user defined events, I'm having a hard time differentiating between them in my generic handler
Is there a way to programatically retrieve a list of all built-in events from socket.io?
I want to avoid hardcoding this list.
After some digging, find out there is internal list of packet names, and is easily accessible:
var io = require('socket.io');
var events = io.parser.packets;
It has a bit more than just three usual events, but can be usefull anyway.
Related
I have a dasboard that is making socket request every five seconds, sometimes, some users start getting data from other user socket request, but at the begging everything is working fine.
I have tried with sticky-session, diferrent socket instance, personalized socket event names.
if someone unsderstand my problem and i have a solution, i would be grateful.
Sockets are, by definition, separate from each other. I suspect the issue is that you're emitting to a namespace rather than to a particular socket.
io.of('someNamespace').emit('data');
vs
io.of('someNamespace').on('connection', (socket) => {
socket.emit('data');
});
In the first example we're sending data to all sockets in the namespace. In the second we're only sending data to a particular socket. The difference is in where you're emitting the data.
I have two node.js applications running side by side on my server and I wan't to send server-side messages between them in a light weight manner using native node.js (v0.10.33) module net
I intend the first application to send messages to the second. I see the console log listening...,
In the first application:
var push='';
var net=require('net');
var server=net.createServer(function(p){
p.on('error',function(err){console.log(err);});
push=p;
setInterval(function(){push.write(JSON.stringify({'f':'ping','data':'stay alive'}));},1000);
});
server.listen(8008,function(){console.log('listening...')});
//a real message might be sent later in the application (this example would need a setTimeout)
push.write(JSON.stringify({'f':'msg','data':'Hello World'}));
In the second application I see the console log open
var net=require('net');
var pull=new net.Socket();
pull.connect(8008,'127.0.0.1',function(){console.log('open');
pull.on('data',function(_){
_=JSON.parse(_);
if(_.f==='ping'){console.log('!!!ping!!!');}
else{console.log(_.data);}
});
pull.on('error',function(err){console.log('pull: '+err);});
});
I do not see any other activity though (no pings, and later after the open event, no hello world) and no errors.
If I inspect with console.dir(pull) I don't see events for accepting data ie: ondata or onmessage
What is wrong?
Unfortunately, I must point out that this messaging scheme is fundamentally broken. You're using TCP, which provides a stream of bytes, not messages.
Despite the fact that TCP sends its data over IP packets, TCP is not a packet protocol. A TCP socket is simply a stream of data. Thus, it is incorrect to view the data event as a logical message. In other words, one socket.write on one end does not equate to a single data event on the other. A single data event might contain multiple messages, a single message, or only part of a message.
The good news is this is a problem already solved many times over. I'd recommend either:
Using a library meant for passing JSON messages over TCP.
Using something like redis as a pub-sub messaging solution (this option makes your app much easier to scale)
If you know that your two apps will always run on the same machine, you should use node's built-in IPC mechanism.
I need to list all connected clients in sails/socket, any easy way to do it?
I don't know if the best way is to use database or just get a list of users connected to the sails/socket.
Thanks in advance.
When possible, it's best to use the built-in pubsub methods that Sails adds to models for you, documented here. Failing that, you can access low-level socket methods in v0.9.8 via sails.io, so it would be:
var sockets = sails.io.sockets.clients();
to get an array of socket objects.
In v0.10 it will be:
var sockets = sails.sockets.subscribers();
to get an array of socket IDs, which you can use with the other sails.sockets methods to publish messages and do other magic.
In socket.io for node.js you create events using:
socket.on('my event', function (data) {...});
In my case I may need to use a lot of different events (close to a 100), so I'm wondering if each of these events creates a separate listener for each client socket and would take more resources than just having a single event that receives an object that contains and identifier on which I can use switch for the events I require. Which option would be better?
They will not create new sockets for each event, you can send as many events as you want. When the socket packet goes down the wire, the event name is just a text property.
If you use your own event-name system, then you will probably just be rewriting the one already there.
There should not be an issue having over 100 events for a socket.io connection.
Each even does not create a new connection, so there should not be a "too many connections" issue.
I know it's possible to emit events to all connections using io.sockets.emit('some event'), but can I also globally bind events to all present and future connections? Would probably look like
io.sockets.on('feedTheDog', function (data) {
// Someone told me to feed the dog..
});
Also, can I remove event listeners with .removeAllListeners() with Socket.IO?
I also don't think you can bind events to future connections, but yes, you can use removeAllListeners with socket.io. They ported node's event emitter to the browser, so it's exactly the same api there. Here's the code for it: https://github.com/LearnBoost/socket.io-client/blob/master/lib/events.js
You can use socket.io-events and attach middleware functions to handle messages for all socket connections, without actually attaching a handler to a socket.