I am wondering how I can send out a message to sockets on an interval, currently I am doing:
io.on('connection', function(socket){
setInterval(function () {
socket.emit('message', variable);
}, 100);
...
Each user then has an interval emitting messages every 100ms. Is there a better way of doing this?
I am also confused about how emit works: I was under the impression it sent the message to all sockets, but if I only start this interval for the first socket that connects and not the following sockets only the first socket receives the message?
Use io.emit to emit to all connected sockets. You can still do this in an interval as well.
// Only needed if you have to do something with a specific socket
io.on('connection', handleSocket);
setInterval(() => {
io.emit('message', variable);
}, 100);
just don`t forget to call clearInterval() finction when the socket connection is close.
Related
Please, read to the end, help me!
I'm developing a multiroom game using SocketIO, with a client-side (React) and a server-side (Node). I'm having a problem on handling this situation:
Consider that at least two clients are inside a Room, after have joining it with socket.join(roomId) (at server-side).
Situation 1: When a player leaves the room manually (clicking a button in the page), the client-side does socket.emit("playerLeaving", someVar) to the server-side listener socket.on("playerLeaving", doStuff) that do some important things with the database (let's call it X listener). Then this listener fires back an event to the other client sockets in that room, with io.sockets.in(roomID).emit("playerLeft", someVar). No problem here.
Situation 2: Instead of manually leaving that room, that user just close the tab/browser, which fires a "disconnect" event do the server-side. Event in that case, the server must do the same procedure that he did on 1st situation, inside that X listener, so I just tried to emit this event socket.emit("playerLeaving", roomID) from inside the "disconnect" handler at server-side, so the X listener would receive it, do his stuffs, and broadcast to the other players that someone has left that room.
THE PROBLEM: the "disconnect" handler (at server-side) emits to X listener (also server-side), but this one doesn't receives it. Summin up, when a player in a room closes the tab/browser, the server isn't handling it correctly and consequently the other players in that room doesn't even get to know about that.
MY CODE:
SERVER-SIDE:
io.sockets.on('connection', (socket) => {
socket.on("playerJoiningRoom", (roomID) => {
socket.join(roomID); // to sign socket to a room
// .... some code
io.broadcast.to(roomID).emit("someoneJoined", someVar); // this works fine
})
// X-listener
socket.on("playerLeaving", (someVar) => {
// ... do stuff in database
io.sockets.in(roomID).emit("playerLeft", otherVar);
}
socket.on("disconnect", () => {
// ...some code here
// then, emit to the listener above
// example: socket.emit("playerLeaving", someVar);
});
})
}
CLIENT-SIDE
function socketEnteredRoom(socket, roomID) {
// notify server
socket.emit("playerJoiningRoom", roomID);
// listen to other players joining the room
socket.on("someoneJoined", someVar);
// listen to other players leaving the room. This listener works when some player leave manually (leave button), but don't work when a player closes tab/browser
socket.on("someoneLeft", someVar);
}
// when player wants to exit room
function handlerExitRoom() {
socket.emit("playerLeaving", someVar);
}
Waiting for your help! Thank you!
(sorry if this is a repeated question, but I couldn't find a answer that worked)
I'm not sure since I can't see your full code, but a common issue is people try to emit to rooms their socket is in in disconnect but the socket is no longer in any rooms at this point. Try changing to disconnect to disconnecting.
Try this,
//server-side
socket.on("disconnect", () => {
io.emit("playerLeaving", someVar);
});
//client-side
socket.emit("disconnect", () => {
});
When I write data to a TCP socket in Node, which is not closed but the client on the other side is not connected anymore (because of network failure for example), how do I know?
The socket's error event doesn't fire in this case for me. If I'm right, TCP gives up sending data, if there is absolutely no ACK packets from the other side, doesn't it? Or am I misunderstanding something?
As explained in the Nodejs Net documentation.
Socket events are close, connect, data, drain, end, error, lookup, and timeout.
Since you're not getting an error event, try listening to the end event which is emitted when the other end of the socket sends a FIN packet.
socket.on('end', () => console.log('socket has ended'))
Alternatively, if you expect a network failure or other unpredictable network edge cases on their end; you can always set a timeout and handle it that way.
socket.setTimeout(60000) // 60 seconds
socket.on('timeout', () => {
console.warn('socket has timed out')
socket.write('socket has timed out')
socket.end()
})
close event listeners are passed a hadError arg that indicates if the socket was closed because of a transmission error. For example:
socket.on('close', hadError => {
if (hadError) {
// Handle transmission error here
}
});
So I don't want to fetch from the server socket.emit until I need it. Because everything is not prepared fully until then. How do I have socket.emit sit quietly until I am ready for it?
Server
io.sockets.on('connection', function (socket) {
socket.on('adduser', function(player){
........
}
socket.emit('getQ', socket.Ques[0].question);
]
Client
var retrieveQ = function (){
socket.on('getQ', function(quesPick){
quesObj = quesPick;
})
The client is retrieveQ much later on its not suppose to be done at start, yet socket is emitting almost right away and giving me errors because socket.Ques is not made until later on.
Simple, emit getQ on response to a client request after client socket connects. Something like this:
io.sockets.on('connection', function (socket) {
socket.on('adduser', function(player){
........
}
socket.on('askGetQ', function(zzz){
socket.emit('getQ', socket.Ques[0].question);
}
}
On the client do:
io.on('connection', function(socket){
socket.emit('getQ', 'something');
});
node.js is an event driven environment. So, sometime in the future there will be some sort of event on your server that will cause you to want to send this .emit(). At that point, you need to be able to find the appropriate socket object and then use it to send the .emit().
Since you haven't said exactly what event you want to use to send this emit, we can't really help more specifically. If you care to explain that, we could probably offer specific code.
On the client you should do:
const chat = io.connect('http://localhost/chat')
chat.on('connect', function () {
chat.emit('getQ', socket.Ques[0].question);
});
A net.Socket object in NodeJS is a Readable Stream, however one note in the docs got me concerned:
For the Net.Socket 'data' event, the docs say
Note that the data will be lost if there is no listener when a Socket emits a 'data' event.
That seems to imply a Socket is returned to the calling script in "flowing-mode" and already un-paused? However, for a generic Readable Stream, the documentation for the 'data' event says
If you attach a data event listener, then it will switch the stream into flowing mode, and data will be passed to your handler as soon as it is available.
That "If" seems to imply if you wait a bit to bind to the 'data' event, the stream will wait for you, and if you intentionally want to miss the 'data' events, the example in the resume() method seems to indicate you must call the resume() method to start the flow of data.
My concern is that when working with a net.Server, when you receive a net.Socket as part of a 'connection' event, is it imperative that you start handling the 'data' events right away since it's already opened? Meaning if I do:
var s = new net.Server();
s.on('connection', function(socket) {
// Do some lengthy setup process here, blocking execution for a few seconds...
socket.on('data', function(d) { console.log(d); });
});
s.listen(8080);
Meaning not bind to the 'data' event right away, I could lose data? So is this a more robust way to handle incoming connections if you have a lengthy setup required for each one?
var s = new net.Server();
s.on('connection', function(socket) {
socket.pause(); // Not ready for you yet!
// Do some lengthy setup process here, blocking execution for a few seconds...
socket.on('data', function(d) { console.log(d); });
socket.resume(); // Okay, go!
});
s.listen(8080);
Anyone have experience working with listening on raw socket streams to know if this data loss is an issue?
I'm hoping this is an instance where the Net.Socket documentation wasn't updated since v0.10, since the stream documentation has a section that mentions 'data' events started emitting right away in versions prior to 0.10. Were TCP sockets properly updated to not start emitting 'data' packets right away, and the documentation not updated appropriately?
Yes, this is the docs flaw. Here is an example:
var net = require('net')
var server = net.createServer(onConnection)
function onConnection (socket) {
console.log('onConnection')
setTimeout(startReading, 1000)
function startReading () {
socket.on('data', read)
socket.on('end', stopReading)
}
function stopReading () {
socket.removeListener('data', read)
socket.removeListener('end', stopReading)
}
}
function read (data) {
console.log('Received: ' + data.toString('utf8'))
}
server.listen(1234, onListening)
function onListening () {
console.log('onListening')
net.connect(1234, onConnect)
}
function onConnect () {
console.log('onConnect')
this.write('1')
this.write('2')
this.write('3')
this.write('4')
this.write('5')
this.write('6')
}
All the data is received. If you explicitly resume() socket, you will lose it.
Also, if you do your "lengthy" setup in a blocking manner (which you shouldn't) you can't lose any IO as it has no chance to be processed, so no events will be emitted.
I'm making simple online game which based on Web.
the game uses Socket.io for netwoking each other.
but I encountered the problem.
think about following situation .
I ran Socket.io server.
one player making the room , and other player join the room.
they played game some time ..
but one player so angry and close the game tab.
in this situation , how can I get the event which one client have been closed the browser in server-side ?
according to googling , peoples say like this : "use browser-close event like onBeforeUnload"
but I know that All browser don't support onBeforeUnload event. so i want solution about
checking the client disconnection event in SERVER SIDE.
in Socket.io ( nodeJS ) server-side console , when client's connection closed , the console say like following :
debug - discarding transport
My nodeJS version is 0.4.10 and Socket.io version is 0.8.7. and both are running on Linux.
Anyone can help please ?
shortend codes are here :
var io = require ( "socket.io" ).listen ( 3335 );
io.sockets.on ( "connection" , function ( socket )
{
socket.on ( "req_create_room" , function ( roomId )
{
var socketInstance = io
.of ( "/" + roomId )
.on ( "connection" , function ( sock )
{
sock.on ( "disconnect" , function ()
{
// i want this socket data always displayed...
// but first-connected-client doesn't fire this event ..
console.log ( sock );
}
});
});
});
Update: I created a blog post for this solution. Any feedback is welcome!
I recommend using the 'sync disconnect on unload' option for Socket IO. I was having similar problems, and this really helped me out.
On the client:
var socket = io.connect(<your_url>, {
'sync disconnect on unload': true });
No need to wire in any unload or beforeunload events. Tried this out in several browsers, and its worked perfectly so far.
There's an event disconnect which fires whenever a socket.io connection dies (note that you need this, because you may still have a wep page open, but what if your internet connection dies?). Try this:
var io = require('socket.io').listen(80);
io.sockets.on('connection', function (socket) {
socket.on('disconnect', function () {
io.sockets.emit('user disconnected');
});
});
at your server. Taken from Socket.IO website.
//EDIT
So I looked at your code and did some tests at my place. I obtained the very same results as you and here's my explanation. You are trying to make Socket.IO very dynamic by dynamically forcing it to listen to different urls (which are added at runtime). But when the first connection is made, at that moment the server does not listen to the other url. It seems that exactly at that point (when connection is accepted) the disconnect handler is set for the first connection and it is not updated later (note that Socket.IO does not create new connections when you call io.connect many times at the client side). All in all this seems to be a bug! Or perhaps there is some fancy explanation why this behaviour should be as it is but I do not know it.
Let me tell you some other things. First of all this dynamical creation of listeners does not seem to be a good way. In my opinion you should do the following: store the existing rooms and use one url for all of them. Hold the ID of a room and when you emit for example message event from client add the ID of a room to the data and handle this with one message handler at the server. I think you get the idea. Push the dynamic part into the data, not urls. But I might be wrong, at least that's my opinion.
Another thing is that the code you wrote seems to be bad. Note that running .on('connection', handler) many times will make it fire many times. Handlers stack one onto another, they do not replace each other. So this is how I would implement this:
var io = require("socket.io").listen(app);
var roomIds = [];
function update_listeners(id) {
io.of("/"+id).on("connection", function(socket) {
console.log("I'm in room " + id);
socket.on("disconnect", function(s) {
console.log("Disconnected from " + roomId);
});
});
}
var test = io.sockets.on("connection", function(socket) {
console.log("I'm in global connection handler");
socket.on("req_create_room", function(data) {
if (roomIds.indexOf(data.roomId) == -1 ) {
roomIds.push(data.roomId);
update_listeners(data.roomId);
}
test.emit("room_created", {ok:true});
});
socket.on("disconnect", function(s) {
console.log("Disconnected from global handler");
});
});
Keep in mind that the problem with creating connections before the listeners are defined will still occure.