I had hard time debugging a problem with my NodeJS' code today.
I have problems when I open two connections to the same unix socket (reasons though); and for unknown reasons, sometimes it works fine throughout; and sometimes I don't get back any data, but connect is fired for only one of them.
I'm still trying to debug, but I deep dived into documentation and faced another question. As NodeJS Docs (12.x LTS) states: (about net.Socket)
# Event: 'connect'
Added in: v0.1.90
Emitted when a socket connection is successfully established. See net.createConnection().
# Event: 'ready'
Added in: v9.11.0
Emitted when a socket is ready to be used. Triggered immediately after 'connect'.
(https://nodejs.org/docs/latest-v12.x/api/net.html)
I wondered if that is where I should look for error:
what does immediately mean? Does it mean synchronously? If so, is there any difference between ready and connect?
is there any point for one using ready instead of connect for doing after-connection-established/opened tasks?
what is the difference between the two?
Thanks!
This event is emitted from net for consistency across different APIs. See the original commit here:
https://github.com/nodejs/node/commit/1c8149417a5dec9b2af056f306822b8a22a09706
It was created to make developers' life easier when working with fs and net code, so that they don't have to remember all the intricate details of a given stream implementation.
In practice, the Node.js socket code does this:
self.emit('connect');
self.emit('ready');
Related
I use net.connect to make socket connection, I wonder how to detect it when a connection has failed?
It seems this doesn't work
//this will return a net.Socket and automatically connect
var client = net.connect({port:22000, host:'10.123.9.163'});
//doesn't trigger a error event even if connection fails
client.on('error', (err)=>{console.log('something wrong')});
//now an error event is emitted reasonably
client.write('hello');
when I run this piece of code, the connection should fail, and it indeed fails because when I write some data, an error occurs. But, I can not detect the connection failure. How can I do that?
=====Ready to close======
God damn it, I think I have just make a mistake. In fact the connection succeeded but due to some security strategy the server close the connection, I find out by doing a telnet. After trying other port which should definitely fail, the error event is emitted, everything go normal as expected. So, I am gonna close this question in case of misleading other people, and also thank you guys for helping me :)
The easiest and most portable way is to simply implement a 'ping-pong' check where both sides send some kind of 'ping' request every so often. If n outstanding ping requests go unanswered after some period of time, then consider the connection dead. This kind of algorithm is basically what OpenSSH uses for example (although it's not enabled by default).
How can one prevent Pusher from automatically pushing all the piled up messages to the client after the client eventually goes online after being offline, i.e. after the client re-establishes the connection?
After exchanging messages with a Pusher support enginner, the issue became more clear.
The connection may still be opened even when the laptop gets asleep (this behaviour varies among computers). Thus, after waking up, it may still be connected. (This is exactly what happened in my case so that everything looked like Pusher pushed the accumulated messages.)
However, the default activity timeout is 120s, and the time to wait for a pong response before closing the connection is 30s. So, allowing it around three minutes would make the client disconnect completely, and the behaviour I encountered would not take place.
Pusher doesn't presently buffer messages to be delivered upon reconnection. So the functionality described in the questions isn't something an application needs to consider right now.
Future releases may contains something called Event Buffer which will offer this functionality. Documentation will be released around that time to detail how to avoid receiving buffered events.
I've got problem connecting Flash client to Node.js server.
Short story:
For a first time I'm building a Node.js server that should be used by both web client (WebSocket) as well as a Flash client (Socket). The web client, of course, works like a charm, but I can't get over the Flash one. I get SECURITY_ERROR. After a day of research I think it's because of the policy file not being loaded. Ideas (primus on top of engine.io) ?
Long story:
I'm using Primus as I thought I'll need it because I have both web sockets and flash sockets to handle. Not sure if this is accurate? :)
I'm using Engine.io as a 'transformer/transporter' - the main framework that the layer uses. I won't discuss the standard web client (using Chrome and primus-client), as it's easy to setup.
I'm using simple and standard Sockets in AS3:
_socket = new Socket();
_socket.addEventListener(Event.CONNECT, onSocketConnect);
//...
_socket.addEventListener(SecurityErrorEvent.SECURITY_ERROR, onSecurityError);
_socket.addEventListener(IOErrorEvent.IO_ERROR, onIOError);
_socket.connect('localhost', '1337);
When building it within Flash IDE, it goes to the onSocketConnect function, but if I try to write anything to the socked - I get disconnected. If I run this from the web browser, I get into the onSecurityError method.
I must say that I don't get any traces in the node console!
primus.on('connection', function connection(spark) {
console.log('new connection'); // never gets logged!
As I know, security error is thrown when there is error with the policy file, so I started searching for a solution for that.
I've read a lot of things online, and most common solution was simple usage of socket.io and so called FlashSocket.IO. I tried implementing it, but it's so old, that some of the code is a kind of missing and I finally got some errors from the hurlant library - I couldn't get it working.
I also saw some node package called policy, which runs separate server to server the policy file.
I tried adding a transport array with flashsocket in it - no change. I also can't understand why all of the samples are using transports - I've searched and both index.js and primus.js are using transport (why there are two separate files, Jesus?!)
I could try using only engine.io without primus, but I don't know if this would be of any help. All the posts and samples I've found are pretty old - please help me with any up to date solution or at least some explanation what needs to be done - seems like a whole new universe to me :)
Thanks in advance!
Edit:
Thanks to the The_asMan, I figured out it has something to do with the handshake. I've tried this simple example (despite the fact it's so old) - it worked perfectly for the Flash client! Of course I cannot connect web sockets to it, as the handshake is not proper - it has some kind of protocol for it.
So I guess I just have to understand how to get the <policy-file-request/> in node - I'll be able to return the policy file. But I don't know how to get it - I don't receive any kind of data nor connect handler...
You have a cross domain policy issue.
I answered it all here.
AS3 - Flash/AIR Socket Communication writeUTFBytes only works once
just an idea:
On some operating systems, flush() is called automatically between execution frames, but on other operating systems, such as Windows, the data is never sent unless you call flush() explicitly. To ensure your application behaves reliably across all operating systems, it is a good practice to call the flush() method after writing each message (or related group of data) to the socket.
In the Node.JS docs for HTTP (v0.8.20), under ServerRequest, I see events for data and end. I do not see an event for error.
Normally, if there was an interruption while receiving data, I could detect it by looking at error. But will that work for postdata?
How can I be sure whether have received the entire postdata, and that it was not truncated due to network failure?
I have not confirmed this with actual running code, but just looking at the manual, http.ServerRequest is a Readable Stream and that has Event: 'error' documented.
there's been a recent issue on this: https://github.com/joyent/node/pull/4775
in general, you should always listen for and handle errors from any streams and eventemitters
I'm connecting a socket asynchronously (O_NONBLOCK + connect). POSIX standard specifies that after socket has been connected is should signal the event by making the file descriptor for the socket ready for writing. It doesn't seem to say anything about failures during async connect.
When testing it on Linux, it seems that sometimes I'm getting POLLOUT and sometimes POLLERR in this situation. Is there any pattern in the behaviour? Can I make it report the errors in a single way? Does POSIX say something I have overlooked?
D. J. Bernstein has some stuff that looks like it might be relevant: http://cr.yp.to/docs/connect.html. In particular he suggests several different ways to get errors out.
The UNIX Socket FAQ has a section on Connect with timeout, that includes getting the error from a failed connection using getsockopt