Consecutive http.get requests

[espruino-discuss]

Posted at 2015-09-26 by Tobbe

I'm doing two get-requests. As soon as I've gotten an answer from the first one I want to do the second one. So something like this

http.get(url, function (res) {
  res.on('data', function (chunk) { ... });
  res.on('close', function () {
    http.get(url2, function (res) {
      res.on('data', function (chunk) { ... });
      res.on('close', function () {
        console.log('both get-requests completed');
      });
    });
  });
});

However, it doesn't work :( I get this:

ERROR: Socket error -1 while sending
Uncaught Error: CIPSTART failed
 at line 1 col 177
...d 0,Error("CIPSTART failed");}
                               ^
in function "b" called from line 1 col 26
{d=void 0;var f;b&&(f=b(a))?(d=p,b=f):clearTimeout(e);void 0...
                          ^
in function "d" called from line 1 col 325
...c&&(e[c](k),n=!0);n||d&&d(k)}a=a.substr(f+1);"\n"==a[0]&&(a=...
                               ^
in function called from system

I can work around it by wrapping the inner get-call in a setTimeout, but that doesn't feel right. What's the correct way to do this?

[espruino-discuss]

Posted at 2015-09-26 by DrAzzy

You probably need to wait a bit between them - the esp 8266 (that's what you're using, right?) supports up to 5 sockets, but their protocol is ambiguous (or it was - when a socket closed, it didn't tell you which one, or something like that), and espruino doesn't use that functionality yet.

So yeah, setTimeout() is what I'd do, at least in the medium term

[espruino-discuss]

Posted at 2015-09-26 by Tobbe

Yeah, I'm using an ESP8266 :) I'll post a video in another thread to show off ;)

[gfwilliams]

Posted at 2015-09-26 by @gfwilliams

Which firmware is it on the ESP8266 - 0.25, or the older one?

Probably Espruino 'asks' the socket to close, but then tries to open it again before it has properly closed. I think it's something that should be fixable in the ESP8266 driver pretty easily.

[espruino-discuss]

Posted at 2015-09-26 by Tobbe

I'm using the newer one, 0.25

[espruino-discuss]

Posted at 2015-09-26 by Kolban

@gordon ... he he he .... Am I sensing the asynchronous story of ESP8266 is biting us again for the partner board story? As you know, a request to do something on the ESP8266 does not mean it is done until the ESP8266 later tells it is :-)

[espruino-discuss]

Posted at 2015-09-26 by @allObjects

...therefore, a queue is required that holds on to the command and the callback until ESP8266 is ready to do it. This queueing can be a separate - chain linked - module or built into the ESP8266 module. It has also to support some simple querying about the state of the queue and some error handling (callback) on overflow...

Asynch systems were never easy to build... but run very efficient: Espruino is living proof of that.

[gfwilliams]

Posted at 2015-09-27 by @gfwilliams

In this case I think it's easier than having a queue... I literally just wait until OK is received before setting the state of the socket as free. As the ESP8266 can handle 5 clients (iirc?) at the same time, it's just a matter of making sure it uses one of the other 4 :)

[espruino-discuss]

Posted at 2015-10-09 by tve

If back-to-back requests aren't working then that's a bug IMHO. The esp8266 is definitely capable of doing the back-to-back requests as well a concurrent requests.

[espruino-discuss]

Posted at 2015-10-09 by tve

...

[gfwilliams]

Posted at 2015-10-09 by @gfwilliams

I think the issue is really just that the JS close callback is called after the socket has been asked to close, but not before we've got the response saying it has. It's not a big thing to work around.

[gfwilliams]

Posted at 2015-10-09 by @gfwilliams

Ok, should be fixed now.

Turns out the socket had already closed, and so the close command created an error, which confused the socket open command.