I uploaded and got working this example on the Yun succesfully, the one where you could turn on and off led 13 through web browser with url command and Yun as the server.
My question is, what protocol is behind this stuff. Tcp or Udp? Or none? I'm newbie to all this servers and client stuff, thanks for your answer.
The protocol is http. You used it with a web browser didn't you? That's the beauty behind rest.
cyborg5:
The protocol is http. You used it with a web browser didn't you? That's the beauty behind rest.
And what I still don't understand, is that I can send to the same server a string with the command "digital/13/HIGH" via TCP socket, and still works.
Does that mean that the server is capable to understand any protocol?
A TCP socket is a means of reliably sending a stream of data across a network.
HTTP is a protocol that rides on top of a TCP socket. A protocol is an agreement of what data is sent, in what order, and with what meaning. It allows computers to a agree on a "language" for the communications. Think of TCP as being your phone line, and HTTP (or FTP, SSH, Telnet, etc) as being the language spoken over the phone line.
When you use a browser to access "http://arduino.local/arduino/digital/13/HIGH" the web browser opens a TCP socket on port 80, and starts negotiating the details of the HTTP connection. The net result is that it sends a GET request "/arduino/digital/13/HIGH" to your Yun. The web server running on the Linux side gets the request, sees that it starts with "/arduino/" and therefore send the remainder of the request to your sketch through the Bridge. Your sketch receives the "digital/13/HIGH" and processes it.
When you open a direct TCP connection, you are bypassing all of the HTTP protocol, and directly sending the "digital/13/HIGH" to your sketch.
The "digital/13/HIGH" can be considered a protocol that you define and implement in your sketch. It can ride on top of the HTTP protocol, which rides on top of TCP.
mart256:
Does that mean that the server is capable to understand any protocol?
ANY protocol? No. The REST API can understand HTTP GET requests, and direct TCP connections (although you use a somewhat different command string for each method.)
Thank you, I think I understood. HTTP over TCP socket is like Modbus over RS485, I guess...
mart256:
HTTP over TCP socket is like Modbus over RS485, I guess...
Yes, a good analogy!
mart256:
Thank you, I think I understood. HTTP over TCP socket is like Modbus over RS485, I guess...
mart256,
a typical explanation for TCP is that it is a "virtual circuit". However, the way it physically works is much more involved. There is a Sync phase, a Handshake phase, then establishment. When you "hang up" the circuit, you are supposed to send a physically signal (packet) that indicates as such.
However, the nitty gritty can be understood by understanding the infamous Syn Flood Attack.
Oh and of course, you can read the complexity at wikipedia
Jesse