Espruino Wifi Socket recovery

Hi,

I should have consulted my notes from a year ago, this problem is linked with an issues I raised here previously (http://forum.espruino.com/conversations/304601/#comment13692804 ) about sockets being closed erroneously during a 'send'. I did some work on this and had comms with @Gordon but then had to move on to other projects.

The problem will occur very quickly if you open one socket and start sending data in a loop whilst you receive data on another socket.

The EspruinoWifi code for sending via the AT commands of the ESP8266 has a final else statement that catches anything other than "OK", "SEND OK" , "Recv" or "Busy s..." and in that event nulls that socket.

if (d=="OK") {
        at.register('> ', function() {
          at.unregister('> ');
          at.write(data);
          return "";
        });
        return cb;
      } else if (d=="Recv "+data.length+" bytes" || d=="busy s...") {
        // all good, we expect this
        // Not sure why we get "busy s..." in this case (2 sends one after the other) but it all seems ok.
        return cb;
      } else if (d=="SEND OK") {
        // we're ready for more data now
        if (socks[sckt]=="WaitClose") netCallbacks.close(sckt);
        socks[sckt]=true;
      } else {  // <- this clause here shouldn't fire but it does !!
        socks[sckt]=undefined; // uh-oh. Error.
        at.unregister('> ');
      }

It all looks OK as the IPDHandler should deal with anything else BUT the reality is that 'd'(the data provided in the at.cmd callback) often contains incoming data meant for the other socket. It looks like data is being 'lost' within the Espruino stack rather than being lost packets from the ESP8266.

In my case the incoming and outgoing data will use checksums so some corruption is OK and to simply keep the link up and running I have amended the code as follows

} else {
          console.log("Send error, received :" + d);
          if (d){
            var ok = d.indexOf("SEND OK")
            if (ok !== -1) {
              //ipdHandler(d.substring(0, ok));
              if (socks[sckt]=="WaitClose") netCallbacks.close(sckt);
              socks[sckt]=true;
              return;
            }     
            if(d.indexOf("> ") !== -1){
              at.unregister('> ');
            }
          }

          return cb;
          //socks[sckt]=undefined; // uh-oh. Error.
          //at.unregister('> ');
        }

This is a pretty ugly hack but it proves the issue and I have had the link running all night when it previously wouldn't last a few minutes. I tried passing the data back to the ipdHandler (commented line above) but it doesn't 'repair' the incoming data.

One important observation is that the erroneous buffer always contains the 'end' of an incoming 'line' meant for the other socket. It looks very much like we are missing the start of the IPD sentence coming from the ESP2866. I will try and debug at the AT module level but hopefully it gives @gordon something to go on.