- 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