geddy with socket.io error - node.js

I'm doing a realtime app with geddy framework (the basic chat example). But I get and error when the client tries to establish the connection.
here's the server-side code (on the init.js file):
var io = require('socket.io').listen(geddy.server);
io.sockets.on('connection', function (socket) {
console.log("Good!");
socket.emit('new', { message: 'world' });
socket.on('newMessage', function (data) {
console.log(data);
});
});
and the client-side code:
$(document).ready(function(){
startSockets();
});
function startSockets(){
var socket = io.connect('http://localhost:4004');
socket.on('new', function (data) {
alert(data);
//socket.emit('newMessage', { my: 'data' });
});
}
When I try to connect to localhost:4004/ I get the next warn:
debug - setting request GET /socket.io/1/websocket/G_GapksVv1J4iBZIUVe3
debug - set heartbeat interval for client G_GapksVv1J4iBZIUVe3
debug - websocket writing 7:::1+0
warn - client not handshaken client should reconnect
info - transport end (error)
debug - set close timeout for client G_GapksVv1J4iBZIUVe3
debug - cleared close timeout for client G_GapksVv1J4iBZIUVe3
debug - cleared heartbeat interval for client G_GapksVv1J4iBZIUVe3
debug - discarding transport
besides Chrome console gives this error:
WebSocket is closed before the connection is established.
I don't know what can cause these. Any ideas?

The problem is that Socket.io needs to connect to the server after it's started, and the server doesn't start until after the code in init.js has run. The current (hacky) solution in the existing built-in RT code (as of Geddy v0.11) is to put this sort of code in an after_start.js file in the config directory, which Geddy runs after the server starts up. This should work as a workaround in this case too, where you're wiring up Socket.io to the server yourself.
This is obviously not ideal, and a major goal for v0.12 is fixing up the RT integration so it's much more usable and useful. If you have input into how you think this should look, definitely hit us up in IRC (#geddy on Freenode.net), or on the mailing list (https://groups.google.com/group/geddyjs).

Related

Socket.io 1.3.7 not cleaning up on client disconnect

I have a node.js script which allows a client to connect and receive some realtime data from an external script.
I have just upgraded node.js & socket.io to the current versions (from <0.9) and am trying to get to grips with what happens when a client quits, times out or disconnects from the server.
Here is my current node.js script;
var options = {
allowUpgrades: true,
pingTimeout: 50000,
pingInterval: 25000,
cookie: 'k1'
};
var io = require('socket.io')(8002, options);
cp = require('child_process');
var tail = cp.spawn('test-scripts/k1.rb');
//On connection do the code below//
io.on('connection', function(socket) {
console.log('************ new client connected ****************', io.engine.clientsCount);
//Read from mongodb//
var connection_string = '127.0.0.1:27017/k1-test';
var mongojs = require('mongojs');
var db = mongojs(connection_string, ['k1']);
var k1 = db.collection('k1');
db.k1.find({}, {'_id': 0, "data.time":0}).forEach(function(err, doc) {
if (err) throw err;
if (doc) { socket.emit('k1', doc); }
});
//Run Ruby script & Listen to STDOUT//
tail.stdout.on('data', function(chunk) {
var closer = chunk.toString()
var sampArray = closer.split('\n');
for (var i = 0; i < sampArray.length; i++) {
try {
var newObj = JSON.parse(sampArray[i]);
// DO SOCKET //
socket.emit('k1', newObj);
} catch (err) {}
}
});
socket.on('disconnect', function(){
console.log('****************** user disconnected *******************', socket.id, io.engine.clientsCount);
socket.disconnect();
});
});
In the old version of socket.io when a client exits I get the following logged in debug;
info - transport end (undefined)
debug - set close timeout for client Owb_B6I0ZEIXf6vOF_b-
debug - cleared close timeout for client Owb_B6I0ZEIXf6vOF_b-
debug - cleared heartbeat interval for client Owb_B6I0ZEIXf6vOF_b-
debug - discarding transport
then everything goes quite and all is well.
With the new (1.3.7) version of socket.io when a client exits I get the following logged in debug;
socket.io:client client close with reason transport close +2s
socket.io:socket closing socket - reason transport close +1ms
socket.io:client ignoring remove for -0BK2XTmK98svWTNAAAA +1ms
****************** user disconnected ******************* -0BK2XTmK98svWTNAAAA
note the line socket.io:client ignoring remove for -0BK2XTmK98svWTNAAAA
but after that and with no other clients connected to the server I'm still seeing it trying to write data to a client that already left. (in the example below this is what I get after I've had 2 clients connected, both of which have since disconnected.
socket.io:client ignoring packet write {"type":2,"data":["k1",{"item":"switch2","datapoint":{"type":"SWITCH","state":"0"}}],"nsp":"/"} +1ms
socket.io:client ignoring packet write {"type":2,"data":["k1",{"item":"switch2","datapoint":{"type":"SWITCH","state":"0"}}],"nsp":"/"} +3ms
I'm trying to stop this apparently new behaviour so that once a client has disconnected and the server is idle its not still trying to send data out.
I've been playing about with socket.disconnect and delete socket["id"] but I'm still left with the same thing.
I tried with io.close() which sort of worked - it booted any clients who where actually connected and made them re-connect but still left the server sitting there trying to send updates to the client that had left.
Am I missing something obvious, or has there been a change in the way this is done with the new version of socket.io? There is nothing in the migration doc about this. The only other result I found was this bug report from June 2014 which has been marked as closed. From my reading of it - it appears to be the same problem I'm having but with the current version.
Update: I've done some more testing and added io.engine.clientsCount to both instances of console.log to track what it's doing. It appears when I connect 1 client it gives me 1 (as expected) and when I close that client it changes to 0 (as expected) this leads me to believe that the client connection has been closed and engine.io know this. So why am I still seeing all the 'ignoring packet write' lines and more with every client who has disconnected.
Update 2: I've updated the code above to include the parser section and the DB section - this represents the full node script as there was a thought that I may need to clean up my own clients. I have tried adding the following code to the script in the hope it would but alas not :(
In the connection event I added clients[socket.id] = socket; and the disconnection event I added delete clients[socket.id]; but it didn't change anything (that I could see)
Update 3: Answer thanks to #robertklep It was an 'event handler leak' that I was actually looking for. Having found that I also found this post.
My guess is that the newer socket.io is just showing you (by way of debug messages) a situation that was already happening in the old socket.io, where it just wasn't being logged.
I think the main issue is this setup:
var tail = cp.spawn('test-scripts/k1.rb');
io.on('connection', function(socket) {
...
tail.stdout.on('data', function(chunk) { ... });
...
});
This adds a new handler for each incoming connection. However, these won't miraculously disappear once the socket is disconnected, so they keep on trying to push new data through the socket (whether it's disconnected or not). It's basically an event handler leak, as they aren't getting cleaned up.
To clean up the handlers, you need to keep a reference to the handler function and remove it as a listener in the disconnect event handler:
var handler = function(chunk) { ... }:
tail.stdout.on('data', handler)
socket.on('disconnect', function() {
tail.stdout.removeListener('data', handler);
});
There's also a (slight) chance that you will get ignored packet writes from your MongoDB code, if the socket is closed before the forEach() has finished, but that may be acceptable (since the amount of data is finite).
PS: eventually, you should consider moving the processing code (what handler is doing) to outside the socket code, as it's now being run for each connected socket. You can create a separate event emitter instance that will emit the processed data, and subscribe to that from each new socket connection (and unsubscribe again when they disconnect), so they only have to pass the processed data to the clients.
This is most probably due to your connection is established via polling transport, which is sooo painful for developer. The reason is that this transport uses timeout to determine if the client is here or not.
The behavior you see is due to the client has left but next polling session opening moment has not come yet, and due to it server still thinks that client "it out there".
I have tried to "fight" this problem in many ways (like adding a custom onbeforeunload event on client side to force disconnect) but they all just do not work in 100% cases when polling is used as transport.

Error connecting mariadb - node.js?

I am using MariaDB in my node.js application. I am having the following code
var nodeMaria = require('node-mariadb');
var connection = nodeMaria.createConnection({
driverType: nodeMaria.DRIVER_TYPE_HANDLER_SOCKET,
host:'localhost',
port:9998
});
connection.on('error', function(err){
console.log(err);
process.exit(1);
});
connection.on('connect', function(){
console.log("mariadb connected");
});
Problem
After connecting the db, It is logging "mariadb connected".
After that Application is breaking without throwing any error.
Note: I had handled the error in connection connection.on('erorr',function(){});
Any help will be great.
If the application is closing, it doesn't necessarily mean that an error has occurred with connecting to MariaDB.
In fact, if there isn't anything keeping a node application explicitly open, it just closes after execution of the code.
What keeps a node application open? Event listeners. If you have an event listener listening for events, the node application doesn't close after finishing code execution. For example, if you have a http.listen command, which starts the web server and starts listening for incoming HTTP connections.

socket.io client connection cannot be made on the 2nd time

Currently, I am implementing an API using nodejs express, then it needs to connect to socket.io and send event.
The API is located in socket.io-client (client), and it connects to socket.io (server)
1st API call: success
The connection is made for the 1st call of the API, message is sent and socket can be disconnected, with the 'disconnect' callback is invoked both on client and server side.
2nd API call: failure
When the API is invoked the 2nd time, the connection to server cannot be made, 'client' callback on client side is not called.
3rd API call: success
Then I tried to restart the client side, keeping other things unchanged. The API is called again, and the connection to socket.io is made successfully and everything is fine.
Can anyone explain the logistics behind this?
Updated
client.js
App.getByUserId(message.to_id, function(error, app) {
var socket = io.connect('http://127.0.0.1:9002');
socket.on('connect', function(){
console.log("client connect socket id:" + socket.id);
console.log("appkey:" + app.private_token);
socket.emit('appkey.check',{appkey: app.private_token, uuid: message.to_id.uuid}, function(data){
socket.emit("forceDisconnect");
socket = null;
});
});
You just hit one of Socket.IO's many "features" or "bugs" depending how you see this. Socket.IO tries to be smart and re-use connections (which causes a lot of connection issues actually) The way around this is use the force new connection option in your io.connect:
io.connect('http://127.0.0.1:9002', { 'force new connection': true });
What you could also do is use https://github.com/primus/primus which wraps Socket.IO if you use the socket.io transformer. Internally, it completely removes the use of the io.connect and uses the much more lower level io.Socket constructor to create more stable connections that you would get with a stock socket.io.
With socket 1.0+, you have to use this for forcing new connection.
io.connect(SERVER_IP, { 'forceNew': true });

Socket.io and modern browsers aren't working

I'm having some weird issues with socket.io and modern browsers. Surprisingly, with IE9 works fine because fallbacks to flashsocket which appears to work better.
In my server (with express)
var io = socketio.listen(server.listen(8080));
io.configure('production', function(){
console.log("Server in production mode");
io.enable('browser client minification'); // send minified client
io.enable('browser client etag'); // apply etag caching logic based on version number
io.enable('browser client gzip'); // gzip the file
io.set('log level', 1); // reduce logging
io.set('transports', [ // enable all transports (optional if you want flashsocket)
'websocket'
, 'flashsocket'
, 'htmlfile'
, 'xhr-polling'
, 'jsonp-polling'
]);
});
On the browser I can see in the Network tab (on Chrome) that a websocket is stablished and get in 101 Switching Protocols in Pending mode. After that, appears xhr-polling and jsonp-polling (what happend to flashsocket ? )
The worst part is that info don't go back and forth. I have this on connection:
io.sockets.on('connection', function (socket) {
// If someone new comes, it will notified of the current status of the application
console.log('Someone connected');
app.sendCurrentStatus(socket.id);
io.sockets.emit('currentStatus', {'connected': true);
});
And on client:
socket.on('currentStatus', function (data){ console.log(data) });
However I only be able to see that log when I turn off the server which is launched with:
NODE_ENV=production node server.js
What am I doing wrong?
Finally, after really banging my head against a wall, I decided to test in several environments to see if it was a Firewall issue since the machine is behind several ones.
It turned out that no one but me had the problem so I checked the Antivirus (Trend Micro) and after disabling, Chrome/Firefox were able to make their magic.
Moral of the story
Besides what it says here - Socket.IO and firewall software - whenever you face an issue that nobody in the internet seems to have (ie, not logged on github nor the socket.io group) it's probably caused by your Antivirus. They are evil. Sometimes.
You should just be having the socketio listen on the app itself.
Also, I have never need to do all of the server side configuration with the socket that you are doing - socket.io should work out of the box on most browsers without doing that. I would try first without configuring.
Also, on the server, you should emit from the socket that is passed to the callback function rather than doing io.sockets.on.
var io = socketio.listen(app);
io.sockets.on('connection', function (socket) {
// If someone new comes, it will notified of the current status of the application
console.log('Someone connected');
app.sendCurrentStatus(socket.id);
socket.emit('currentStatus', {'connected': true);
});
on the client, you need to connect first:
var socket = io.connect();
socket.on('currentStatus', function (data){ console.log(data) });
If you want to see an example of two way communication using socket.io, check out my Nodio application.
The server side:
https://github.com/oveddan/Nodio/blob/master/lib/Utils.js
And the client side:
https://github.com/oveddan/Nodio/blob/master/public/javascripts/Instruments.js

Socket.IO is not triggering the connect event

I'm trying to setup a Socket.IO server, and right now, connecting doesn't seem to be working the way it does in the Wiki. I'm connecting to a server using the namespace /client, and I'm successfully seeing the connection made in the debug log, but the connection message is never display (and the other contents are never getting attached).
Server-side
var clients = io
.of('/client')
.on('connect', function (socket) {
// This is never getting run
console.log('Client connected');
});
Client side
var socket = io.connect('http://localhost:8082/client');
Why, in the above code, am I not getting the 'Client connected' message in my console?
So, turns out this is a very simple issue, as I suspected. The client uses the connect event, but the server uses connection.
The code should look like:
var clients = io
.of('/client')
.on('connection', function (socket) {
// This is never getting run
console.log('Client connected');
});

Resources