Closed fkromer closed 3 years ago
Is possible to see the code?
The library itself does not buffer requests. In case of the Ethernet shield the buffering happens on the Wiznet chip. When the connected client is processed with the app.process function it just tries to read from that and times out if there is no data.
That beings said I think the ethernet shield should not have any problems waiting for a few milliseconds for the request to be read unless you run out of sockets if you create too many open requests at the same time. You should be able to reproduce this behaviour without the library by just sending the http response manually without the library.
What is your http client and what kind of behaviour are you seeing in that end? Can you provide me a simplified sketch that would reproduce the problem. What ethernet shield are you using. I have a few old Arduino Dues somewhere and a W5100 ethernet shield. I could fire one up and see how it works.
@lasselukkari Thanks for the response. aWOT works just fine. It turned out that the Wiznet W5500 Ethernet chip on the Arduino Shield v2 abstracts away a lot of things related to Ethernet about which you usually have to care about yourself. It's capable of handling 8 independent sockets and has 32Kbytes Memory for Tx/Rx Buffers. In my case (1 socket connection, app code) the chip buffer is sufficiently big enough that I do not have to care about how regularly I trigger the aWOT logic. The issue was created by an unexpected behaviour of some other Arduino lib functionality.
Ok. Happy to hear you got it working!
I've implemented a RESTful API server. At the moment I'm running the server in a superloop. I'm calling code similar to the one from https://github.com/lasselukkari/aWOT/blob/master/examples/Ethernet/Ethernet.ino#L43-L49 periodically. I observed that dependent on the call periodicity of this logic requests are not handled properly. In my particular case (Arduino Due + my application logic) responses are delivered properly if the logic is called every 430 microseconds (approx. 2325 Hz). If the logic is called every 3-4 milliseconds (33.3-250 Hz) my client does not get a response. I'm thinking about migrating the logic into RTOS tasks. Would be great if you could provide a rule of thumb w.r.t. how regularly logic needs to be executed. That would help to assign task priorities/define task trigger periodicity.
EDIT: The requests seem to be buffered. This means one has to consider call periodicity w.r.t. application specific requirements only like e.g. accetable responsiveness for HMI related endpoints which is often around 250ms (4Hz).