Protokół HTTP w zastosowaniach IoT - część 2: budujemy serwer

[ethanak]

Z poprzedniej części mogliśmy się dowiedzieć, co to takiego ten cały HTTP -jak się okazało, nic strasznie skomplikowanego. Dzisiaj zajmiemy się praktyczną stroną - czyli napisaniem najprostszego serwera. Oczywiście - jako że temat traktuje o IoT - serwer będzie udostępniał dane odczytane z jakichś czujników. Już słyszę: a dlaczego serwer a nie klient, przecież klient powinien być łatwiejszy?

Ten wpis brał udział konkursie na najlepszy artykuł o elektronice lub programowaniu. Sprawdź wyniki oraz listę wszystkich prac »
Partnerem tej edycji konkursu (marzec 2020) był popularny producent obwodów drukowanych, firma PCBWay.

A dlatego, że aby sprawdzić działanie klienta, należy mieć serwer a takiego na razie nie mamy. Natomiast klienta HTTP ma tu raczej każdy - począwszy od przeglądarek, poprzez przeróżne wgety i curle kończąc na PuTTY i netcacie. Przyjrzyjmy się więc dokładniej, jak działa.

Spis treści serii artykułów:

• Protokół HTTP w zastosowaniach IoT - część 1: trochę teorii
• Protokół HTTP w zastosowaniach IoT - część 2: budujemy serwer
• Protokół HTTP w zastosowaniach IoT - część 3: tworzymy klienta

Serwer HTTP

W najprostszym przypadku serwer po podłączeniu do sieci po prostu czeka na zgłoszenie klienta, wykonuje jakąś tam funkcję obsługi, rozłącza się z klientem i powraca do czekania. Spróbujmy napisać taki program. Ponieważ dla różnych płytek i modułów łączenia z siecią program może być różny, spróbujmy stworzyć przynajmniej dwa (czyli Arduino z Ethernet Shield i dla ESP8266/ESP32).

Zacznijmy od jakichś założeń. A więc:

• Do płytki podłączony jest potencjometr 10 kΩ i przycisk;
• Serwer w odpowiedzi na zapytanie podaje wartości odczytu potencjometru i przycisku;
• Serwer nie sprawdza poprawności zapytania, zakłada że jeśli ktoś coś od niego chce to tylko tego co wypisuje;
• Serwer wypisuje wartości czystym tekstem, bez zabawy w jakieś HTML-e i podobne wymysły.

Najpierw więc przygotujmy wszystko, co nam będzie potrzebne. Przede wszystkim musimy sobie przygotować płytkę i podłączyć do niej potencjometr i przycisk. W przypadku Arduino będzie to wyglądać tak:

Podobnie dla ESP8266 i ESP32:

Zanim zabierzemy się do pisania programu - kilka słów wstępu.

Otóż różne biblioteki (WiFi, Ethernet) operujące na połączeniach sieciowych TCP/IP zawsze mają swoje klasy serwera i klienta, będące pochodnymi ogólnych klas Server i Client. Funkcje obsługi połączeń (spoza tych bibliotek) zawsze wymagają właśnie obiektów tych klas, a nie konkretnych (np. EthernetServer).

A co robią takie obiekty? To są po prostu elementy najprostszego połączenia TCP/IP. Obiekt klasy Server nasłuchuje na określonym porcie i w przypadku przychodzącego połączenia tworzy nowy obiekt typu Client, już połączony ze stroną nawiązującą połączenie:

EthernetClient client=server.available();
if (client) {
    // obsługa połączenia
}

Obiekt klasy Client można również utworzyć ręcznie - i wtedy trzeba mu podać adres i port serwera, z którym ma się połączyć:

if (client.connect(ADRES_IP_SERWERA, PORT_SERWERA)) {
    // rozmowa z serwerem
}
else {
   Serial.println("Nie mogę nawiązać połączenia");
}

Ponieważ Client dziedziczy po klasie Stream (a Stream po Print) - możemy tu używać wszystkich metod pochodzących z tej klasy (podobnie jak w obiektach klasy Serial)

Dobra, wystarczy tego wstępu. Zabierzmy się wreszcie za napisanie prostego serwera.

Zacznijmy od tego, co będzie się powtarzać we wszystkich następnych programach, czyli od tych wszystkich beginów, initów i innych powtarzalnych rzeczy. Spróbujmy od razu zrobić to tak, aby jak najmniej ingerować w późniejsze programy czy to przy zmianie płytki (Arduino - ESP), czy przy dalszych eksperymentach z programami (serwer i klient).

Taki typowy kod (dla Arduino) wygląda tak:

#include <SPI.h>
#include <Ethernet.h>

#define POT_PIN A1
#define KEY_PIN A0

byte mac[] = { 
  0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };

EthernetServer server(80);

void setup() {
    Serial.begin(9600);
    while (!Serial); // dla Leonardo
    Ethernet.begin(mac);
    while (Ethernet.linkStatus() == LinkOFF) {
        Serial.println(F("Ethernet cable is not connected."));
        delay(500);
    }
    // dajmy mu trochę czasu na połączenie
    delay(1000);
    
    Serial.print(F("Adres serwera: "));
    Serial.println(Ethernet.localIP());
    
    pinMode(KEY_PIN, INPUT_PULLUP);
    server.begin();
}

Oczywiście jest to najprostszy z możliwych sposobów połączenia z siecią, więcej informacji można znaleźć w dokumentacji i przykładach biblioteki Ethernet.

Porównajmy to z kodem dla ESP8266 i ESP32:

#ifdef ESP32

#include <WiFi.h>
#define POT_PIN 32
#define KEY_PIN 16

#else

#include <ESP8266WiFi.h>
#define POT_PIN A0
#define KEY_PIN 4

#endif

const char* ssid = "My_SSID";
const char* password = "My_PASSWORD";

WiFiServer server(80);

void setup(void)
{
    Serial.begin(115200);
    WiFi.mode(WIFI_STA);
    WiFi.begin(ssid, password);

    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        Serial.print(".");
    }
    Serial.println();
    Serial.print("Połączono z WiFi, adres serwera: ");
    Serial.println(WiFi.localIP());
    
    pinMode(KEY_PIN, INPUT_PULLUP);
    server.begin();
    
}

I znów procedura łąćzenia jest maksymalnie uproszczona - ale nie czas to i nie miejsce na omawianie niuansów różnych rodzajów połączeń:)

Jak widać kody dla ESP8266 i ESP32 są na tyle podobne, że mogliśmy użyć wspólnego kodu zmieniając tylko bibliotekę i definicje pinów. Spróbujmy jednak pójść dalej i stworzyć wspólny kod dla Arduino/Ethernet i ESP.

#ifdef AVR

// część dla Arduino i Ethernet Shield

#include <SPI.h>
#include <Ethernet.h>

#define POT_PIN A1
#define KEY_PIN A0

byte mac[] = { 
  0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED };

#define MyServer EthernetServer
#define MyClient EthernetClient
#define SERIAL_SPEED 9600

void init_network(void)
{

    Ethernet.begin(mac);
    while (Ethernet.linkStatus() == LinkOFF) {
        Serial.println(F("Ethernet cable is not connected."));
        delay(500);
    }
    // dajmy mu trochę czasu na połączenie
    delay(1000);
    
    Serial.print(F("Adres serwera: "));
    Serial.println(Ethernet.localIP());

}

#else

// część dla ESP

#ifdef ESP32

#include <WiFi.h>
#define POT_PIN 32
#define KEY_PIN 16

#else

#include <ESP8266WiFi.h>
#define POT_PIN A0
#define KEY_PIN 4

#endif

const char* ssid = "My_SSID";
const char* password = "My_PASSWORD";

#define MyServer WiFiServer
#define MyClient WiFiClient
#define SERIAL_SPEED 115200


void init_network(void)
{
    WiFi.mode(WIFI_STA);
    WiFi.begin(ssid, password);

    while (WiFi.status() != WL_CONNECTED) {
        delay(500);
        Serial.print(".");
    }
    Serial.println();
    Serial.print("Połączono z WiFi, adres serwera: ");
    Serial.println(WiFi.localIP());
}

#endif


MyServer server(80);

void setup(void)
{
    Serial.begin(SERIAL_SPEED);
#ifdef __AVR_ATmega32U4__
    while (!Serial); // potrzebne tylko dla Leonardo/Micro
#endif
    init_network();
    pinMode(KEY_PIN, INPUT_PULLUP);
    server.begin();
}

Możemy teraz zobaczyć, że:

• wszystkie zależne od płytki wywołania funkcji inicjalizujących połączenie zostały przeniesione do funkcji init_network();
• nazwy klas zależnych od płytki i typu połączenia z siecią zostały "zamaskowane" definicjami MyClient i MyServer

W ten sposób pisząc dalej program nie będziemy musieli zawracać sobie głowy różnicami między płytkami, bibliotekami i sposobami połączeń z siecią.

I teraz mając wszystko przygotowane, możemy na spokojnie zająć się...

pierwszą wersją serwera

Kod jest tu banalnie prosty i chyba nie wymaga komentarza. Po połączeniu klienta pobieramy od niego wszystko jak leci nigdzie tego nie zapamiętując, aż do napotkania pustej linii. W tym momencie zakładamy, że klient nic więcej wysyłać nie będzie. W odpowiedzi wysyłamy dwa nagłówki:

HTTP/1.1 200 OK - potwierdzenie, że wszystko się udało
Content-Type: text/plain - czyli, że odpowiadamy czystym tekstem

Po nagłówkach wysyłamy linię zawierającą obie odczytane z wejść wartości i zamykamy połączenie.

void loop()
{

    // Sprawdzamy, czy klient się połączył
    MyClient client = server.available();
    if (!client) { // nie połączył się
        return;
    }
    Serial.println(F("Nowe połączenie"));
    
    // Czytamy znak po znaku aż do napotkania pustej linii:
    bool linia_pusta = true;
    bool naglowki_wczytane = false;
    while (client.connected()) {
        if (!client.available()) continue;
        char c = client.read();
        Serial.print(c);
        if (c == '\n') { // koniec linii
            if (linia_pusta) {
                naglowki_wczytane = true; // wczytaliśmy wszystko
                break;
            }
            linia_pusta = true;
        }
        else if (c != '\r') { // znak '\r' po prostu pomijamy
            linia_pusta = false;
        }
    }
    
    // czy na pewno wszystko wczytaliśmy?
    
    if (!naglowki_wczytane) {
        // klient zniknał
        Serial.println();
        Serial.println(F("Klient rozwiał się we mgle"));
    }
    else {
        // Wypisujemy ważne nagłówki i pustą linię
        client.print(F("HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\n"));
        int pot = analogRead(POT_PIN);
        int key = digitalRead(KEY_PIN);
        client.print(pot);
        client.print(' ');
        client.println(key);
    }
    client.stop();
}

Możemy teraz w praktyce przetestować nasz serwer. Możemy do tego użyć przeglądarki, wpisując następujący URL:

http://adres_ip_serwera/

My jednak chcielibyśmy obejrzeć całą transmisję, więc znów użyjemy PuTTY lub nc:

Jak się przekonaliśmy, napisanie prostego serwera nie jest wcale takie trudne, a nawet taki banalny program może byc użyteczny (np. w czujniku temperatury, odpytywanym periodycznie przez główny komputer w domu). Tym niemniej program może się niespecjalnie podobać. Przede wszystkim - czego byśmy nie wpisali, dostaniemy w odpowiedzi wartości z czujników. Podglądając komunikację widzimy, że przeglądarka wysłała dodatkowy request prosząc o ikonkę serwisu - a takiej przecież nie mamy. Spróbujmy więc ulepszyć nieco nasz serwer, tworząc...

ulepszoną wersję serwera

Poczyńmy znów pewne założenia:

• Oprócz potencjometru i przycisku serwer podaje wartość jakiejś zmiennej (nazwijmy ją po prostu nasza_zmienna);
• Serwer oprócz metody GET obsługuje również HEAD;
• W przypadku otrzymania nieprawidłowej linii serwer odpowiada komunikatem błędu;
• Z poziomu przeglądarki możemy ustawić wartość "nasza_zmienna" wpisując URL typu http://adres_ip_serwera/set/wartość;
• Jeśli serwer otrzyma żądanie /favicon.ico, odpowiada błędem 404 (Not Found).

#ifdef AVR
#define BUFFER_LENGTH 128
#else
#define BUFFER_LENGTH 1024
#endif

int nasza_zmienna=0;

void error400(MyClient& client)
{
    client.println(F("HTTP/1.1 400 Bad Request\r\n\
Content-type: text/plain\r\n\r\n\
Bad request"));
    client.stop();
}

void error404(MyClient& client)
{
    client.println(F("HTTP/1.1 404 Not Found\r\n\
Content-type: text/plain\r\n\r\n\
Not found"));
    client.stop();
}

void error405(MyClient& client)
{
    client.println(F("HTTP/1.1 405 Method Not Allowed\r\n\
Allow: GET,HEAD\r\n\
Content-type: text/plain\r\n\r\n\
Method not allowed"));
    client.stop();
}


void loop(void)
{
    char bufor[BUFFER_LENGTH];
    bool isHead;
    
    // Sprawdzamy, czy klient się połączył
    MyClient client = server.available();
    if (!client) { // nie połączył się
        return;
    }
    Serial.println(F("Nowe połączenie"));
    
    // dajmy sobie czas na wpisanie czegoś do PuTTY
    
    client.setTimeout(20000);
    
    // Wczytujemy pierwszą linię

    int n = client.readBytesUntil('\n',bufor, BUFFER_LENGTH-1);
    if (!n) { // nic nie wczytano?
        Serial.println(F("Klient się rozmyślił"));
        client.stop();
        return;
    }
    bufor[n] = 0; // dopisujemy '\0' na końcu stringu
    Serial.println(bufor);
    
    // teraz pomijamy resztę nagłówków
    bool linia_pusta = true;
    bool naglowki_wczytane = false;
    while (client.connected()) {
        if (!client.available()) continue;
        char c = client.read();
        Serial.print(c);
        if (c == '\n') { // koniec linii
            if (linia_pusta) {
                naglowki_wczytane = true; // wczytaliśmy wszystko
                break;
            }
            linia_pusta = true;
        }
        else if (c != '\r') { // znak '\r' po prostu pomijamy
            linia_pusta = false;
        }
    }
    
    // czy na pewno wszystko wczytaliśmy?
    
    if (!naglowki_wczytane) {
        // klient zniknał
        Serial.println();
        Serial.println(F("Klient rozwiał się we mgle"));
        client.stop();
        return;
    }
    
    char *path=strchr(bufor,' ');
    if (!path) {
        error400(client); return;
    }
    *path++=0;  // wstawiamy zero w miejsce spacji
                // oddzielającej metodę od ścieżki
    if (!strcmp(bufor, "GET")) {
        isHead = false; 
    }
    else if (!strcmp(bufor, "HEAD")) {
        isHead = true;
    }
    else {
        error405(client); return;
    }
    
    char *proto = strchr(path, ' ');
    if (!proto) {
        error400(client); return;
    }
    *proto++=0;
    
    // nie przesadzajmy, uwierzmy na słowo że to HTTP :)
    // nie będziemy sprawdzać co siedzi w proto
    
    if (!strcmp(path,"/favicon.ico")) {
        error404(client); return;
    }
    if (!strncmp(path, "/set/", 5)) {
        nasza_zmienna = atoi(path+5);
        Serial.print(F("Ustawiamy nową wartość zmiennej: "));
        Serial.println(nasza_zmienna);
    }
    
    // wypisujemy nagłówki
    
    client.print(F("HTTP/1.1 200 OK\r\nContent-Type: text/plain\r\n\r\n"));
    
    // teraz możemy odpowiedzieć trzema wartościami:
    // potencjometr, przycisk i nasza zmienna
    
    if (!isHead) {
        int pot = analogRead(POT_PIN);
        int key = digitalRead(KEY_PIN);
        client.print(pot);
        client.print(' ');
        client.print(key);
        client.print(' ');
        client.println(nasza_zmienna);
    }
    client.stop();
}

Kod powinien być zrozumiały bez szczegółowego omawiania każdej linii, być może z dwiema uwagami:

• dotychczas nie mówiliśmy o metodzie HEAD. Działa ona podobnie jak GET, ale serwer kończy transmisję po wysłaniu nagłówków.
• zamiast błędu 405 (Method Not Allowed) należałoby użyć 501 (Not Implemented). Sugerowałoby to jednak błąd oprogramowania serwera  tymczasem to klient przeznaczony do współpracy z urządzeniami IoT powinien wiedzieć jakie pytanie można zadać serwerowi. Dodatkowo obsługa błędu 405 wymaga wysłania dodatkowego nagłówka informującego klienta, jakich metod może używać.

A oto wyniki działania naszego serwera:

Widzimy więc, że zgodnie z naszymi założeniami:

• Metoda HEAD powoduje wysłanie tylko nagłówków;
• Nieznana metoda powoduje wystąpienie błędu 405
• Prośba o /favicon.ico powoduje wystąpienie błędu 404
• URI o specialnej postaci: /set/<liczba> powoduje zapisanie liczby w pamięci serwera.

Możemy również zauważyć, ze odpowiedź informująca o błędzie ma taką samą postać jak prawidłowa, czyli składa się z głównego nagłówka odpowiedzi (tzw. "status line"), nagłówka typu, ewentualnie dodatkowych nagłówków i odpowiedzi w postaci zrozumiałej dla człowieka.

Dodatkowym efektem wysłania 404 w odpowiedzi na favicon.ico jest zapamiętanie tej informacji przez przeglądarkę i nie proszenie o nią za każdym razem.

Taki serwer może już służyć bardziej praktycznym celom - np. sterowaniem różnych domowych urządzeń za pomocą przeglądarki.

I tyle na dziś. Kody obu programów znajdziemy w załączniku: servers.zip - a w następnej części spróbujemy stworzyć klienta, czyli skomunikować się z naszym serwerem.

Spis treści serii artykułów:

• Protokół HTTP w zastosowaniach IoT - część 1: trochę teorii
• Protokół HTTP w zastosowaniach IoT - część 2: budujemy serwer
• Protokół HTTP w zastosowaniach IoT - część 3: tworzymy klienta

[Treker (Damian Szymański)]

Artykuł został opublikowany, więc podbijam, aby wszyscy widzieli go jako nowy temat