I am a HW/firmware kinda guy new to web protocols so forgive me if this question isn’t well framed.
I have written a light dimmer type demo application based on the RGB demo. I have a HTTP IN connected to my imp passing in the color value (#RRGGBB). I have also written an Mac-based application that emits HTTP POSTS based on the position of some sliders. Seems to work reliably. However the application can generate many posts per second when the slider is dragged. I can verify that the posts are being sent by watching my network traffic. However the lights on the imp do not change until the final post is sent and only represent the final intensity level. There is no fading as the slider is moved which is what I’d like to implement.
Is there some rate limit for processing the posts? What is the preferred method of sending many commands per second to the imp?
Also I have a callback registered when I receive a response. It seems that you only send a response after some seconds of inactivity? Is this to be expected? What is the timeout?
There’s currently not a rate limit (though there may be at some point, it’ll likely be an long term average so that you can still do the type of thing you’re trying to do here).
These should all be getting through independently. We have a very similar demo here. Can you count the set() calls and log them on the imp and see if it’s just many events arriving at once?
Thanks for the ideas Hugo. I did two experiments that had a similar result:
log set() calls on the imp
Added a counter vimp to the HTTP IN in planner
They both only incremented by one for each series of POSTS that I log in my own application (matching how the LED itself seems to work).
Unfortunately I don’t have a way to decode the encrypted HTTPS packets on my own ethernet traffic. I have wireshark running and I see a lot of TCP traffic between my computer and your server as I move the slider. For example if I just click one position on the slider I see several packets. If I move the slider back and forth I see hundreds of packets. I just not sure what the content is so I don’t know where the problem is.
I’d appreciate any insight/ideas you have. I’m going to play with my own code to see if there is any issue there.
Just a thought: are these definitely coming through as separate HTTP sessions, or is it possible the library you’re using for HTTP is keeping the connection open and stuffing subsequent requests down the same socket?
Probably it is one session and for some reason only one actual POST is being made even though there is an awful lot of TCP traffic generated. I did some additional experimentation:
I changed to using unencrypted HTTP so Wireshark could analyze the traffic. I see all kinds of TCP traffic between my machine and your server but only one POST at the end. The TCP traffic definitely increased as I pushed multiple posts into my library. Unfortunately I don’t really understand what was happening with the TCP traffic just that the two machines were exchanging a lot of it (SYN, ACK, FIN, occasional RST).
I told my library to use synchronous posts (1 second timeout) and saw success getting each post through although the latency slowed the throughput (and responsiveness of the control because the thread that samples it and posts data was blocked most of the time).
You mention separate sessions. I think I have to go learn about these protocols more but I am gathering that I probably have to wait for an OK for each POST and if I want to have a bunch of POSTs outstanding at a time then I need to have as many different open sessions?
Is there a recommended way to burst data to you from an application?