ESP8266 Community Forum

- Wed Jun 01, 2016 5:06 pm #48419 @martinayotte since the server is not too quick on sending packets, your while loop exits after all data is read (you have read the response faster than it's coming). Again, something that async can coop with just fine

Async HTTP and WebSocket Server for ESP8266
Async TCP Library for ESP8266
ESP8266 Exception Stack Trace Decoder

- Thu Jun 02, 2016 10:16 am #48459 Thanks @me-no-dev !
I've also tried the HTTPClient suggested by @IGrr in gitter, it works, but I've found something really interesting : if the output is Serial, it works fine, but if the output is a Telnet client, it is slower than a snail, even after 1 minutes, the connection is still ongoing outputting less than 1 line per second.

https://gist.github.com/igrr/a81e10c375 ... c1a18b0eb4

- Thu Jun 02, 2016 2:33 pm #48471 Hi, all,
Thanks for having a look into this issue. I'm following your interesting chat on https://gitter.im/esp8266/Arduino
I'm also trying to grasp how to do it the async way using Me-no-dev's async libs, but although I understand the server part quite well, I don't see how the "async client" comes into play...
Any hint or link to similar use ?
Kind regards,
Vicne

- Thu Jun 02, 2016 4:07 pm #48475 Thanks for the interesting chat.

For those interested in this topic, the basic outcome of this is :
1) using synchronous client and server libs causes too many packets to be put on the stack and it can not take it anymore
2) using asynchronous client and server would solve this. Me No Dev libs allow an easy implementation of a web server but interleaving calls with an async client might be tricky. A few hints are:
- an AsyncTCP holds client and server (and some variations of the client)
- when you are a client and you want to connecto to a server you use connect and then get callback onConnect or onError
- if you get onConnect, then you are connected and you can write(buffer, up to client->space() bytes) then you will get onAck for each packet that was sent (first send will be a copuple of packets at the same time if you have lots of data)
- in onAck you can send another chunk the same way
- you get data from the other end in onData
- onPoll is something that get's called every 125/256 ms while the connection is open and no data is passing through (in case you have not had data to send on the last onAck)
3) in the end, it's probably much simpler to use SPIFFS to cache data before returning it to the browser. This should solve the ram limitation issue, and avoids re-fetching the same data over and over again until is has changed.

I will first try the SPIFFS way and see how it goes.

Thanks to all who contributed to that discussion. Any hint or comment is welcome of course.

Kind regards,

Vicne