Alternatives to (laggy) http posting

I’m designing a servo-controlling solution where Imp plays the role of central communication board. And I have a web app that knows how to send http post to the respective URL so that my imp gets the message and can interpret it and move the servos accordingly.

My solution works fine, but the latency is pretty terrible. Implementing a simple “keep turning while the button is pushed, stop when released” becomes virtually impossible, because the motor keeps rolling while the stop signal travels. It can be even up to 10 seconds, and, as a rule, very variable.

So, is there some alternatives to http communication with imp? Can the imp pull data from URL on the local ethernet? Or, perhaps, I can open a websocket connection for more responsive comms?

I have a number of imps that I control via HTTP from an iOS app, including a hacked HexBug Spider. I see occasional lag, but it is typically in ms and not seconds. If you see 10 second lag, I would diagnose the other hops in your system. I’m on the east coast, and my imp response time is very fast.

I’m in Europe, Latvia. So the summary length of wire is pretty long, I guess. But your post doesn’t mention anything regarding alternatives - are there none?

Ahh… that could do it. As far as the alternatives, I can tell you my understanding of the answer… but someone from the Imp team will probably give you a better one. You can’t directly interface with the device, and I don’t think they plan on doing that. I believe that socket connections are in the works though.

Have you ever seen a cross section of undersea fiber? Its pretty cool. Layer after layer of stranded shielding.

I was testing a similar kind of setup last month, web page with buttons posting to the Imp server, controlling hobby servos connected to an Imp.

The Imp was in Eastern Canada, being controlled by a friend in Berlin, Germany. That’s a 6000km+ “wire”. We had a video Skype call, so my friend could report (subjectively) on the latency between pressing a button on the web page and seeing a resulting move of the motors via the Skype call. This wasn’t meant to be exact, we just wanted to know if there was a subjective feel of lag.

We were seeing under a quarter of a second for everything round trip, with our crude measurements, and that was with whatever delay Skype was adding.

EDIT: Ping time between our locations was around 100ms that day.

@passiday - data to the imp has to pass through the imp servers.

We don’t have stats for Latvia, but 10 seconds of latency seems a bit high. Do you have any code you could possibly share (either here, or in a PM).

One strategy we’ve used in the past to improve http response times is “long polling.” Depending on how you have set things up, this may or may not improve things…

For long polling, your agent would open an http request to whatever server you’re running the web app on. The web server hangs onto that request until something interesting changes (in this case, the button is pressed, or released), at which point is immediately sends the response.

Sounds to me like the 10 seconds is because you’re issuing so many requests that they’re backing up - by the time they get to complete, it’s 10 seconds later.

Long polling is far by the best option here. We have a feature coming which allows you to keep a session open and stream requests to the agent (ie, agent makes an outbound request and then you can return multiple results and get a callback for each). This would likely be the best solution in the short term.

As for doing the same for inbound http requests, that’s not in there yet but could be added.