Architektura typu klient serwer: przesyłanie pliku tekstowo oraz logowania do serwera za pomocą szyfrowanego hasła

Architektura typu klient serwer: przesyłanie pliku tekstowo oraz logowania do serwera za pomocą szyfrowanego hasła Wydział Inżynierii Mechanicznej i Informatyki Instytut Informatyki Teoretycznej i Stosowanej dr inż. Łukasz Szustak

Komunikacja bezpołączeniowa (SOCK_DGRAM) Główna koncepcja komunikacji bezpołączeniowej

Komunikacja bezpołączeniowa (SOCK_DGRAM) Gniazda typu SOCK_DGRAM komunikacja w modelu bezpołączeniowym korzystającą z tzw. datagramów Datagram blok danych pakietowych przesyłany przez sieć między komputerami, zawierający wszelkie niezbędne informacje do przesłania danych z hosta źródłowego do hosta docelowego, bez konieczności wcześniejszej wymiany informacji przez te hosty Datagram jest podstawową jednostką przesyłania danych w sieciach pakietowych, w których czas i kolejność dostarczenia kolejnych jednostek danych nie są gwarantowane

Komunikacja bezpołączeniowa (SOCK_DGRAM) Gniazdo może zostać opisane przy pomocy domeny adresowej, w której wyróżniamy m.in. domenę internetową PF_INET W przypadku komunikacji bezpołączeniowej oraz domeny internetowej komunikacji odbywać się będzie w oparciu o protokół UDP (User Datagram Protocol) W dalszej części prezentacji zostanie przedstawiony przykład pary programów: klient oraz serwer, których zadaniem będzie przesłanie plików tekstowych z wykorzystaniem gniazd w modelu komunikacji bezpołączeniowej w domenie internetowej PF_INET

Serwer #define _XOPEN_SOURCE #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> #include <stdio.h> #include <netdb.h> #include <cstdlib> #include <cstring> #include <string> #include <iostream> #include <fcntl.h> #define SRVPORT 1111 /* numer portu serwera */ #define CLIPORT 31337 /* numer portu gniazda klienta */ #define SRVADDR "localhost" /* adres serwera */ #define PASSWD "alakota" /* haslo wymagane do polaczenia z serwerem */ #define CSALT "Zz" /* dwuznakowy tzw. salt dla funkcji crypt() */ #define PLIK "/proc/cpuinfo" /* plik, który wyślemy klientowi */

Serwer Otwieramy lokalne gniazdo (PF_INET, SOCK_DGRAM) int main (void) { int sd, fd, ret; /* deskryptor gniazda, deskryptor pliku, pomocnicza */ struct sockaddr_in saddr, caddr; /* adres lokalnego gniazda, adres zdalnego gniazda */ char buf[1024], /* bufor */ hash[20]; /* bufor na zahashowane hasło */ socklen_t len; sd = socket (PF_INET, SOCK_DGRAM, 0); if (sd < 0) { perror ("socket()"); exit (1); Następnie przypisujemy mu adres aby zdalni klienci byli w stanie wysyłać do serwera datagramy (gniazdo musi mieć przypisany adres aby możliwa była komunikacja z nim)

Serwer saddr.sin_family = PF_INET; saddr.sin_port = htons (SRVPORT); saddr.sin_addr.s_addr = INADDR_ANY; if (bind (sd, (struct sockaddr *) &saddr, sizeof (saddr)) < 0) { perror ("bind()"); exit (1); Następnie jest obliczany tzw. one way hash na podstawie hasła (PASSWD) i tzw. salt. Salt jest prawie dowolnym dwuliterowym ciągiem znaków ([a-z, A-Z, 0-9]) i jest stosowane przez algorytm liczenia funkcji hashującej sprintf (hash, "%s", crypt (PASSWD, CSALT)); printf ("Czekam na datagramy...\n");

Serwer W dalszej kolejności jest pętla, w której są obsługiwane nadchodzące żądania od klientów while (true) { bzero (buf, sizeof (buf)); len = sizeof (caddr); recvfrom (sd, buf, sizeof (buf), 0, (struct sockaddr *) &caddr, &len); Wywołanie recvfrom() blokuje do czasu, aż nadejdą jakieś dane do odczytania Kiedy tak się stanie struktura wskazywana przez *from zostanie wypełniona adresem gniazda, z którego te dane nadeszły

Serwer Poniższy fragment kodu sprawdza, czy klient jest upoważniony do komunikacji z serwerem Procedura autoryzacji klienta oparta jest na dwóch elementach: haśle i porcie źródłowym (porcie, z którego nadaje klient) Serwer oczekuje od klienta datagramu zawierającego ciąg (hash) utworzony na maszynie klienta w ten sam sposób, co na serwerze Jeśli wyniki działania funkcji hashujących na serwerze i na kliencie pokrywają się oraz jeśli port źródłowy zgadza się z wcześniej ustalonym po obu stronach to serwer wyśle w stronę klienta datagram zawierający odpowiedź 'OK' printf ("Datagram od %s:%i... ", inet_ntoa (caddr.sin_addr), ntohs (caddr.sin_port)); if (!strncmp (buf, hash, strlen (hash)) && ntohs (caddr.sin_port) == CLIPORT) { printf ("Przyjęty.\n"); sendto (sd, "OK\n", 3, 0, (struct sockaddr *) &caddr, sizeof (caddr));

Serwer W dalszej części programy otwierany jest wcześniej zdefiniowany plik i po kawałku przesyłamy go do klienta Kiedy cały plik zostanie przesłany, wysyłany jest klientowi ciąg znaków 'END' aby poinformować, że transmisja się powiodła fd = open(plik, O_RDONLY); if (fd < 1) { perror ("open()"); sendto (sd, "Błąd: open()\n", 13, 0, (struct sockaddr *) &caddr, sizeof (caddr)); bzero (buf, sizeof (buf)); while (read (fd, buf, sizeof (buf)) > 0) { sendto (sd, buf, strlen (buf), 0, (struct sockaddr *) &caddr, sizeof (caddr)); bzero (buf, sizeof (buf)); close (fd); sendto (sd, "END\n", 4, 0, (struct sockaddr *) &caddr, sizeof (caddr));

Serwer Blok else wykonuje się jeśli któryś z elementów autoryzacji (hasło, port źródłowy) jest niepoprawny W tym miejscu również się kończy główna pętla while oraz cały kod serwera else { printf ("Odrzucony.\n"); sendto (sd, "Błąd: złe hasło albo port źródłowy\n", 4, 0, (struct sockaddr *) &caddr, sizeof (caddr)); return 0;

Klient Kod klienta niewiele różni się od kodu serwera #define _XOPEN_SOURCE #include <unistd.h> #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> #include <stdio.h> #include <netdb.h> #include <cstdlib> #include <cstring> #include <string> #include <iostream> #include <fcntl.h> #define SRVPORT 1111 /* numer portu serwera */ #define CLIPORT 31337 /* numer portu gniazda klienta */ #define SRVADDR "localhost" /* adres serwera */ #define PASSWD "alakota" /* haslo wymagane do polaczenia z serwerem */ #define CSALT "Zz" /* dwuznakowy tzw. salt dla funkcji crypt() */

Klient W pierwszej kolejności tworzone jest lokalne gniazda Drugim krokiem w tym przypadku jest ręczne przypisanie adresu do lokalnego gniazda Tą czynność można pozostawić systemowi, jednakże w przedstawianym przypadku ze względu na autoryzację należy numer portu musi zostać dobrany we właściwy sposób, ponieważ serwer nie zgodzi się na sesję jeśli nie będziemy wysyłali datagramów ze ściśle określonego gniazda

Klient int main () { int sd; struct sockaddr_in saddr, caddr; struct hostent *sent; /* struktura opisująca host-serwer */ char buf[1024]; /* bufor */ socklen_t len; sd = socket (PF_INET, SOCK_DGRAM, 0); if (sd < 0) { perror ("socket()"); exit(1); caddr.sin_family = PF_INET; caddr.sin_port = htons (CLIPORT); caddr.sin_addr.s_addr = INADDR_ANY; if (bind (sd, (struct sockaddr *) &caddr, sizeof (caddr)) < 0) { perror ("bind()"); exit(1);

Klient Kolejnym krokiem jest wypełnienie struktury sockaddr gniazda zdalnego printf ("Szukam adresu IP serwera %s...\n", SRVADDR); sent = gethostbyname (SRVADDR); if (!sent) { herror ("gethostbyname()"); exit (1); saddr.sin_family = PF_INET; saddr.sin_port = htons (SRVPORT); bcopy (sent->h_addr, (char *) &saddr.sin_addr, sent->h_length); Do bufora jest kopiowany wynik działania funkcji hashującej bzero (buf, sizeof (buf)); sprintf (buf, "%s", crypt (PASSWD, CSALT));

Klient Do serwera jest wysyłane zakodowane hasło, a następnie klient oczekuje na przyzwolenie do dalszej komunikacji printf ("Wysyłam hasło do %s:%i...\n", inet_ntoa(saddr.sin_addr), SRVPORT); sendto (sd, buf, strlen (buf), 0, (struct sockaddr *) &saddr, sizeof (saddr)); printf ("Czekam na odpowiedź...\n"); do { bzero (buf, sizeof(buf)); len = sizeof(caddr); recvfrom (sd, buf, sizeof(buf), 0, (struct sockaddr *) &caddr, &len); while (caddr.sin_addr.s_addr!= saddr.sin_addr.s_addr); Należy tutaj zwrócić szczególną uwagę na fakt, że istnieje możliwość przyjścia na nasz adres jakiegoś przypadkowego datagramu nie związanego zupełnie z sesją między nami a serwerem W pętli do-while są odbierane kolejne datagramy, które przychodzą na adres klienta W sytuacji gdy otrzymany datagram pochodzi od serwera, kod programy pozwoli na kontynuację programu

Klient W dalszej części programu weryfikowane jest czy odebrana informacja jest to odpowiedź na wysłany wcześniej przez program klienta datagram z hasłem (ciąg 'OK') if( strncmp(buf, "OK", 2) ) { fprintf (stderr, "Nieprawidlowe haslo albo zly port zrodlowy. Koncze...\n"); exit(1); else printf ("Polaczenie przyjete.\n\n"); Ostatnim fragmentem programu jest pętla, która ponownie przegląda wszystkie nadchodzące datagramy, sprawdza, czy pochodzą one od serwera, a następnie podejmuje jedno z trzech działań: jeśli datagram zawiera ciąg 'END' to znaczy, że serwer zakończył już transmisję pliku jeśli zawiera ciąg 'Błąd:' to wyświetlany jest komunikat błędu oraz kończymy program

Klient ostatnia możliwość jest nadejście datagramu zawierającego część przesyłanego pliku: w tym przypadku jest wyświetlana cała zawartość datagramu na standardowym wyjściu bzero (buf, sizeof (buf)); len = sizeof (caddr); while (recvfrom (sd, buf, sizeof (buf), 0, (struct sockaddr *) &caddr, &len) > 0) { if (caddr.sin_addr.s_addr == saddr.sin_addr.s_addr) { if (!strncmp (buf, "END", 3)) { break; else if (!strncmp (buf, "Błąd:", 5)) { printf ("%s", buf); break; else printf ("%s", buf); bzero (buf, sizeof (buf)); len = sizeof (buf); return 0;

Podsumowanie W omawianym przypadku wystarczy jedno gniazdo aby obsłużyć wielu klientów W bardziej skomplikowanych przypadkach uzasadnione może stać się przydzielenie każdemu klientowi osobnego procesu Główną wadą omawianego przykładu jest brak gwarancji, że dane dotrą w niezmienionej postaci do klienta oraz, że w ogóle dotrą Wadę tej można uniknąć stosując komunikację w modelu połączeniowym z użyciem pakietu TCP

Podsumowanie Komunikacja połączeniowa wykorzystująca protokół TCP, wysyła klientowi pakiety, a następnie oczekuje od niego potwierdzenia, że pakiet pomyślnie dotarł do celu Jeśli w pewnym przedziale czasu nie ma potwierdzenia to następuje ponowna próba przesłania pakietu w przypadku definitywnego braku połączenia warstwa TCP zasygnalizuję błąd Powyższym mechanizmem nie dysponuje protokół UDP, jednakże można samemu zaimplementować podobną procedurę weryfikacji

Podsumowanie Należy również zwrócić uwagę na niewielkie różnice pomiędzy serwerem i klientem opartymi na tym protokole Oba programy przeglądają wszystkie nadchodzące datagramy, a różnica pojawia się właściwie dopiero w warstwie aplikacji modelu sieciowego