Espruino WiFi connect callback before connection established

I have been doing some testing on net.connect and find it runs the callback before the connection is established (deliberately erroneous hostname and port in code). I can't then run a registered error event handler. This is counter to the documents that indicate that the callback is executed after the TCP connection is established. I would appreciate some validation that I am not doing anything wrong?

There is also no way I can see to change the connect timeout, however if I use the AT commands I can catch the error.

Output:

**** STARTING ****
WiFi Connected!
["AT+CIPSTART=0,\"TTCP\",\"weeso\",1888\­r\n"
net client before callback {"type":0,"opt":{"host":"weeso","port":1­888},"sckt":1}
net client callback {"type":0,"opt":{"host":"weeso","port":1­888},"sckt":1,"conn":true}
net client disconnected {"type":0,"opt":{"host":"weeso","port":1­888},"conn":true} *** {"type":0,"opt":{"host":"weeso","port":1­888},"conn":true}
net client disconnected {"type":0,"opt":{"host":"weeso","port":1­888},"conn":true} *** undefined
net closed, had_error: false

Code:

var wifi = require("EspruinoWiFi");

function onInit() {
  console.log("**** STARTING ****");
  wifi.connect(WIFI_NAME, WIFI_OPTIONS, function (err) {
    if (err) {
      console.log("WiFi Connection error: " + err);
      return;
    }
    console.log("WiFi Connected!");
    wifi.at.debug();
    var at = wifi.at;
    //at.cmd('AT+CIPSTART=0,"TCP","weeso",18­88\r\n', 10000, (cb) => {
    //  console.log('AT cb '+cb);
    //});

    var client = require("net").connect({host: "weeso", port: 1888}, function (skt) {
      console.log('net client callback ' + JSON.stringify(skt));
      //client.write('Hello');
      client.on('error', function (err) {
        console.log("net error ");
        console.log("Error: " + JSON.stringify(err));
      });
      client.on('data', function (data) {
        console.log("net > " + JSON.stringify(data));
      });
      client.on('connected', function(data) {
        console.log("net connect "+JSON.stringify(data));
      });
      client.on('timeout', function (data) {
        console.log("net timeout " + JSON.stringify(data));
      });
      client.on('close', function (data) {
        console.log("net closed, had_error: " + JSON.stringify(data));
      });
      client.on('end', function (err) {
        console.log('net client disconnected ' + JSON.stringify(skt) + ' *** ' + JSON.stringify(err));
      });
    });
    console.log('net client before callback ' + JSON.stringify(client));

    });
}

No, you're not doing anything wrong. It's an unfortunate side-effect of the current network abstraction layer... On CC3000, WIZnet, and Linux, the 'connect' function is synchronous - but when using AT commands with ESP8266 it's async.

As a result, the connect function completes immediately and then if the connection fails the error code is reported by send/recv functions - but the 'connected' callback has already been called.

It's particularly annoying in bare TCP/IP sockets, but the majority of people just use HTTP. In that case, the connected handler gets called only after the headers have been received - so in reality there is no real difference in the way it works at all.

You're also getting two disconnected handlers though? I'll check up on that - I've seen that before and wasn't sure about it. It must be some kind of regression.

I've now fixed the multiple disconnect issue, so on newer builds your code outputs this.

>onInit()
**** STARTING ****
=undefined
WiFi Connected!
["AT+CIPSTART=0,\"TCP\",\"weeso\",1888\r­\n"
net client before callback {"type":0,"opt":{"host":"weeso","port":1­888},"sckt":1}
net client callback {"type":0,"opt":{"host":"weeso","port":1­888},"sckt":1,"conn":true}
] "\r\nERROR\r\n0" <--- "\r\nERROR\r\n0"
net client disconnected {"type":0,"opt":{"host":"weeso","port":1­888},"conn":true} *** undefined
net closed, had_error: false
] "0,CLOSED\r\n" <--- ",CLOSED\r\n"

For some reason the other debug lines didn't make it into your dump - but an error (with no other info) is reported by the ESP8266. There's no socket number so I guess we just have to hope that it's always in response to a CIPSTART :)

I had a bit of a fiddle with the EspruinoWiFi driver to try and get it to detect errors, but it does seem there is some issue reporting them back through the HTTP/TCPIP stack so I'm not going to put that code in until I can get the whole thing going.

Ok, turns out there's code in there to handle errors, but it was never tested on any Espruino boards so didn't work when you used the AT command module.

I've fixed it and also updated the EspruinoWiFi module, so if you use a build from Git then you should get errors reported (but in most cases, this will be after you get a connection event)