Arduino Yun - REST API delays

The REST API in Yun is great but there is more or less one second delay between the moment when browser makes the HTTP request (over WiFi) and the moment when it becomes available for arduino sketch. Is it expected behavior for Yun?
In order to get better responsiveness I had to use console available after forwarding 6571 port over SSH for sending and receiving commands - these data are passed to arduino sketch instantly, but it requires dedicated application with SSH support. I’d like to controll the robot with javascript application using REST. Is there any way to improve REST responsiveness?

Speed of the Bridge example can be improved by modifying its code this way

  if (client) {
    client.setTimeout(5);
    // Process request
    process(client);

Thank you, Federico, that helped in my project using the Arduino REST API too.

Hi mamu I ask you if you can please explain me a little bit more about what you said here:

I had to use console available after forwarding 6571 port over SSH for sending and receiving commands - these data are passed to arduino sketch instantly, but it requires dedicated application with SSH support.

Do you think it is possible to write a phyton script that exchange data with the mcu with the console rather than the bridge? In order to speed the comunication up? I need as much speed as possible. I'm not really expert in python programming, but maybe there exists a SSH library to forwarding requests trough the 6571 port...

That was not me, that was from panjanek.

mamu: That was not me, that was from panjanek.

Oh...you are right. I confused the names. So, i forward the question to panjanek :)

mrk_b:
Hi mamu
I ask you if you can please explain me a little bit more about what you said here:

I had to use console available after forwarding 6571 port over SSH for sending and receiving commands - these data are passed to arduino sketch instantly, but it requires dedicated application with SSH support.

Do you think it is possible to write a phyton script that exchange data with the mcu with the console rather than the bridge? In order to speed the comunication up? I need as much speed as possible.
I’m not really expert in python programming, but maybe there exists a SSH library to forwarding requests trough the 6571 port…

Sure.
I worked out that data read and written in sketch using functions Console.write/Console.read in Arduino Yun are not transmitted by serial USB port (like in other boards) but are transmitted throuth tcp socket at localhost:6571 where “localhost” is arduino yun linux host. So if you log into Arduino Yun with SSH you can open connection with telnet command to local port 6571 (the exact command is ‘telnet localhost 6571’) and you will see output of Console commands, and everything you type in will be available do Console.read function in sketch.
I decided I will communicate with my sketch that way, but I didn’t want to open putty everytime and type addidtional telnet command. I wanted to wrote dedicated GUI for sending and receiving data from my robot.
So I found a SSH library for C# and write C#/WPF program. That program opens SSH tunel using Renci.SshNet library. Tunel is forwarding local port 3000 on my PC to 6571 port on yun. After that I’m sending commands to my sketch by TCP connection to my-PC:3000 and they are sent to (throuth the tunel) to sketch running on Yun.
Arduino IDE 1.5.4 is doing the same thing when you open serial monitor to remote Arduino Yun.
I can post code fragments if you like, but you have to be familiar with C# and .NET in order to make use of them. The same thing could be done in Java of course.

Unfortunatelly, I'm not an expert on python either, but I'm sure it is possible to forward a TCP port from python - eventually you can run SSH command with appropriate parameters in background for port forwarding.

Other solution would be to run your python script on Arduino Yun linux - port forwarding is not neccessary then, just open connection to localhost:6571 and you can communicate with sketch.

Thanks, setTimeout(5) helped, REST API is now more responsive, but still commands going through 6571 port console are received faster. What is the purpose of this undocummented function setTimout? (making a delay while processing http request is not a standard definition of 'timeout', I would gues that this is pooling interval of some kind...?). Is there any way to optimize rest api further? (like setting lower delay/pooling interval on server object?)

YunClient is a subclass of Stream http://arduino.cc/en/Reference/StreamSetTimeout Console and plain socket based YunClient/Server are faster because, in order to deal with an http request, uhttpd (the webserver running on linino) has to start a lua process to handle it (i.e.: since more work has to be done, it's slightly slower)

Just to clarify: Is Console faster than YunClient?

As far as I know, no. But it depends who is feeding the YunClient: if it’s the web server with a REST api then you need to sum the time taken by the web server to handle the http request and translate it into a plain socket connection, hence it’s a little slower

So having one's eyes on performance one should make a direct http call and handle it with the YunClient and avoid the REST layer of the linino/bridge? Just to be sure: using /arduino/ means I'm using the REST API?

panjanek: The REST API in Yun is great but there is more or less one second delay between the moment when browser makes the HTTP request (over WiFi) and the moment when it becomes available for arduino sketch. Is it expected behavior for Yun? In order to get better responsiveness I had to use console available after forwarding 6571 port over SSH for sending and receiving commands - these data are passed to arduino sketch instantly, but it requires dedicated application with SSH support. I'd like to controll the robot with javascript application using REST. Is there any way to improve REST responsiveness?

Would it be an option to make Linino server forward to 6571 by modifying etc/firewall?

mamu: So having one's eyes on performance one should make a direct http call and handle it with the YunClient and avoid the REST layer of the linino/bridge?

That's what YunClient/YunServer are about, and if you start the YunServer with noListenOnOnLocalhost you don't even need SSH.

Just to be sure: using /arduino/ means I'm using the REST API?

Yes

mamu: Would it be an option to make Linino server forward to 6571 by modifying etc/firewall?

I think it should be possible to open 6571 port for remote connection. You won't need SSH support then but loose the security - anyone would be able to connect to your-yun:6571. And still, the connection will be raw TCP without HTTP headers, although it should be possible to implement adding HTTP headers in sketch.

panjanek:

mamu: Would it be an option to make Linino server forward to 6571 by modifying etc/firewall?

I think it should be possible to open 6571 port for remote connection. You won't need SSH support then but loose the security - anyone would be able to connect to your-yun:6571. And still, the connection will be raw TCP without HTTP headers, although it should be possible to implement adding HTTP headers in sketch.

And in the sketch would you use YunServer or Console for communication?

[quote author=Federico Fissore link=topic=196429.msg1458850#msg1458850 date=1383814860] [quote author=mamu link=topic=196429.msg1458412#msg1458412 date=1383776594 So having one's eyes on performance one should make a direct http call and handle it with the YunClient and avoid the REST layer of the linino/bridge? [/quote] That's what YunClient/YunServer are about, and if you start the YunServer with noListenOnOnLocalhost you don't even need SSH. [/quote] Cool. Will give it a try. Any examples on noListen ?

mamu:

panjanek:

mamu: Would it be an option to make Linino server forward to 6571 by modifying etc/firewall?

I think it should be possible to open 6571 port for remote connection. You won't need SSH support then but loose the security - anyone would be able to connect to your-yun:6571. And still, the connection will be raw TCP without HTTP headers, although it should be possible to implement adding HTTP headers in sketch.

And in the sketch would you use YunServer or Console for communication?

If I had access to 6571 TCP port on yun from remote PC, I would use Console for communication.

Maybe you could even program your sketch to act as webserver using Console (write HTTP data in Console.write and parse browser request in Console.read), but I'm not sure 100% that this would work. It would be interesting to test this idea.

That's what you do with a WiFi/Ethernet shield. If you have to deal with http at that level, you're wasting a lot of space from the 32u4 and you're not gaining any advantage from the yun. Delegate to the linux side everything network related: that's one of the key point of the yun