Programowanie sieciowo-komunikacyjne

Transkrypt

1 Programowanie sieciowo-komunikacyjne Krzysztof Grąbczewski Katedra Informatyki Stosowanej Uniwersytet Mikołaja Kopernika Toruń 26 maja / 176

2 Program zajęć Ogólne zasady i techniki komunikacyjne Programowanie łączy szeregowych, starszych (RS232, RS485) i nowszych (USB) Komunikacja TCP/IP, korzystanie z różnych popularnych protokołów Technologie komunikacyjne Microsoft Windows (DDE, OLE, COM, COM+,.Net remoting, web services) Architektury klient/serwer, peer to peer oraz systemy rozproszone Niezawodność i bezpieczeństwo komunikacji 2 / 176

3 Literatura Notatki z wykładu MSDN, Microsoft Douglas E. Comer Sieci komputerowe i intersieci, WNT Stevens W. Richard UNIX. Programowanie usług sieciowych, tom 1 i 2, WNT 2001/2 Wojciech Mielczarek Szeregowe interfejsy cyfrowe, Helion 1993 Wojciech Mielczarek USB. Uniwersalny interfejs szeregowy, Helion 2005 Andrzej Daniluk RS 232C. Praktyczne programowanie, Helion 2007 John Paul Mueller COM+. Kompendium programisty, Helion / 176

4 Laboratorium cel Cel: kolekcja programów wykorzystujących różne metody komunikacji do testowania prędkości przesyłu danych i czasu odpowiedzi na wzór programu ping, ale z wysyłaniem pakietów danych non-stop w zapytaniu umieszczony rozmiar pakietu do przesłania zwrotnie prowadzenia rozmowy tekstowej (chat) przez różne media rozmowa pomiędzy dwoma klientami klient zgłasza się podając swoją nazwę i z kim chce rozmawiać serwer sprawdza, czy ma parę zgodnych zgłoszeń i gdy się pojawią odpowiada obu klientom tekstem connect i przekazuje teksty pomiędzy nimi kopiowania plików z serwera i na serwer (w ustalone miejsce) pośredniczenia w komunikacji: program papuga do komunikacji przez różne media (np. TCP RS232) i podsłuchiwania 4 / 176

5 Laboratorium Metody komunikacji: pliki serwer kontroluje ustaloną lokalizację i gdy pojawi się plik, czyta z niego polecenie i w pliku o tej samej nazwie z rozszerzeniem.out zostawia odpowiedź (pliki są przenoszone do podkatalogu ARCHIWUM po obsłużeniu) łącze szeregowe (RS232 po kablu, wirtualne porty) TCP/UDP DDE, OLE COM, COM+.NET remoting, web services www tunelling 5 / 176

6 Założenia projektowe Ogólne: architektura klient/serwer wielowątkowość serwera model zapytanie odpowiedź rozdział spraw komunikacji od funkcjonalności serwera i od interfejsu użytkownika łatwa konfiguracja serwera Szczegóły komunikacji: rozdzielić kwestie zapytań i odpowiedzi od medium komunikacyjnego wykorzystać możliwości każdego medium możliwy odbiór fragmentami (użycie bufora, analiza poleceń kiedy są dostępne w całości) 6 / 176

7 Przymiarki do projektu Moduły (niewizualnego) serwera: moduły obsługi poszczególnych funkcji (ping, chat etc.) jednolity sposób obsługi gotowość na wielowątkowość (równoległa obsługa zapytań bez kolizji) komunikatory nasłuchujące i realizujące połączenia jednolity sposób obsługi łatwe dodawanie nowych komunikatorów, zamykanie ich pracy wniosek: wspólna klasa bazowa (cała hierarchia klas) i kolekcja komunikatorów interfejs konfiguracyjny możliwość konfiguracji serwera przez klienta dowolnym medium komunikacyjnym 7 / 176

8 Analiza funkcji komunikacyjnych Testy czasu odpowiedzi i prędkości przesyłu np. polecenie ping i odpowiedź pong ABC... (1024 znaki) polecenie to jedna linia tekstu (dowolnie długa) odpowiedź zawiera żądaną liczbę bajtów (dowolny tekst odpowiedniej długości) Rozmowa tekstowa polecenie połączenia z innym klientem: chat mój_id id_rozmówcy odpowiedź serwera: connect (w odpowiednim czasie) w trakcie rozmowy: msg id_rozmówcy wiadomo±... 8 / 176

9 Analiza potrzeb na użytek komunikatorów Strona serwera: powiadomienie o połączeniu klienta powiadomienie o zapytaniu klienta Strona klienta: żądanie połączenia (udane bądź nie) pytanie odpowiedź (z oczekiwaniem) powiadomienie o przesyłce ze strony serwera Klasa bazowa w szczegółach nieco później 9 / 176

10 Podstawy komunikacji TCP/IP w.net Specyfika protokołu TCP (dla dopełnienia formalności): interfejs komunikacyjny jest określony przez adres IP oraz port TCP (liczba 16-bitowa bez znaku, czyli w zakresie ) serwer nasłuchuje połączeń na wybranym porcie klient łączy się wychodząc do sieci również przez pewien port, choć często port klienta jest wybierany automatycznie przez system Podstawy obsługi TCP w.net Przestrzeń nazw System.Net.Sockets Klasa TcpClient Klasa NetworkStream Klasa TcpListener Klasa Socket 10 / 176

11 Klasa TcpClient Schemat działania: tworzymy obiekt łączymy z serwerem (można już w konstruktorze) wymieniamy dane przez strumień (klasa NetworkStream) lub gniazdo (klasa Socket) Podstawowe składowe: Connect(...) kilka wersji NetworkStream GetStream() Close() zwalnia obiekt, ale nie kończy połączenia! Konieczne NetworkStream.Close() własności Connected, ReceiveBuerSize, ReceiveTimeout, SendBuerSize, SendTimeout 11 / 176

12 Prosty klient TCP 1 TcpClient client = new TcpClient(server, 80); 2 string message = "GET / HTTP/1.1\nHost: " + server + "\n\n"; 3 byte[] data = System.Text.Encoding.ASCII.GetBytes(message); 4 NetworkStream stream = client.getstream(); 5 stream.write(data, 0, data.length); 6 data = new byte[256]; 7 string odp = string.empty; 8 int bytes; 9 do 10 { 11 bytes = stream.read(data, 0, data.length); 12 odp += System.Text.Encoding.ASCII.GetString(data, 0, bytes); 13 } 14 while (bytes > 0); 15 Console.WriteLine("Pobrane: {0}", odp); 16 stream.close(); 17 client.close(); 12 / 176

13 Prosty klient TCP z użyciem klasy Socket Wystarczy w kodzie z poprzedniej strony zamienić: NetworkStream stream = client.getstream(); stream.write(data, 0, data.length); na Socket socket = client.client; socket.send(data, 0, data.length, SocketFlags.None); oraz bytes = stream.read(data, 0, data.length); na bytes = socket.receive(data, 0, data.length, SocketFlags.None); 13 / 176

14 Klasa NetworkStream Realizuje odczyt i zapis przez strumienie sieciowe Nie pozwala na wyszukiwanie (CanSeek == false) Nie ma buforowania, Flush() nic nie robi Podstawowe składowe: int Read(byte[] buer, int oset, int size) int ReadByte() void Write(byte[] buer, int oset, int size) void WriteByte(byte value) własności: logiczne: CanRead, CanWrite, DataAvailable w milisekundach: ReadTimeout, WriteTimeout, Socket 14 / 176

15 Klasa TcpListener Nasłuchiwanie portu, akceptowanie połączeń, odpowiadanie na zapytania Klienci: TcpClient lub Socket można nasłuchiwać pod konkretnym adresem bądź pod dowolnym (System.Net.IPAddress.Any) Podstawowe składowe: void Start() void Stop() Socket AcceptSocket() TcpClient AcceptTcpClient() bool Pending() 15 / 176

16 Prosty serwer TCP 1 server = new TcpListener(IPAddress.Any, 12345); 2 server.start(); 3 byte[] bytes = new byte[256]; 4 while (true) { 5 TcpClient client = server.accepttcpclient(); 6 string data = null; 7 int len, nl; 8 NetworkStream stream = client.getstream(); 9 while ((len = stream.read(bytes, 0, bytes.length)) > 0) { 10 data += Encoding.ASCII.GetString(bytes, 0, len); 11 while ((nl = data.indexof('\n'))!= 1) { 12 string line = data.substring(0, nl + 1); 13 data = data.substring(nl + 1); 14 byte[] msg = Encoding.ASCII.GetBytes(PingPong(line)); 15 stream.write(msg, 0, msg.length); 16 } 17 } 18 client.close(); 19 } 16 / 176

17 Ping-pong fragment klienta TCP 1 string message = "ping 1024\n"; 2 byte[] data = Encoding.ASCII.GetBytes(message); 3 4 stream.write(data, 0, data.length); 5 Console.Write("Wysªane: {0}", message); 6 7 byte[] response = new byte[256]; 8 string responsestr = string.empty; 9 int bytes; 10 do 11 { 12 bytes = stream.read(response, 0, response.length); 13 responsestr += Encoding.ASCII.GetString(response, 0, bytes); 14 } 15 while (stream.dataavailable); Console.WriteLine("Pobrane: {0}", responsestr); 17 / 176

18 Przydatne klasy.netu Przestrzeń nazw System.Net Dns WebClient abstrakcyjne WebRequest i WebResponse HttpWebRequest i HttpWebResponse FtpWebRequest i FtpWebResponse FileWebRequest i FileWebResponse Przestrzenie nazw System.Net System.Net.Http System.Net.Mail System.Net.MIME System.Net.Security 18 / 176

19 Projektowanie własnych protokołów k-s Podstawowe pytania na początek: 1 Na jakie pytania mają być udzielane odpowiedzi? 2 Jaka jest specyfika zapytań? Każde niezależne czy ciągi powiązane? Czy protokół połączeniowy? Simplex, half-duplex czy full-duplex? Komunikacja synchroniczna czy asynchroniczna? 3 Protokół tylko dla maszyn czy również dla ludzi? Komunikaty tekstowe czy binarne? 4 Jaka jest wymagana/oczekiwana prędkość komunikacji? 5 Jakie medium będzie najodpowiedniejsze? 6 Na bazie jakiego innego protokołu budować swój własny? 19 / 176

20 Projekt systemu na użytek laboratorium (1) Ad 1: Pytania od klientów (propozycja): ping: chat: ping n data... chat msg nicknames mynickname text... chat get mynickname chat getnow mynickname chat who file management: file dir dirname file mkdir dirname file get filename file put filename data... papuga osobny program 20 / 176

21 Projekt systemu na użytek laboratorium (2) Ad 2: Przykład rozwiązań: Testujemy różne łącza, więc dla ułatwienia niech wszystko działa bezpołączeniowo, każde polecenie niezależnie Jeśli half-duplex, to chat należy wzbogacić o polecenie sprawdzające czy są nowe wiadomości Dla półdupleksu wystarczy komunikacja synchroniczna Ad 3: Edukacyjnie, więc i dla ludzi wszystko tekstowo chat: text... rozpychany by był pojedynczą linią file management: pliki można przekodować w tekst, np. przez Base64 Ad 4-6: Różnie, czyli wszechstronnie 21 / 176

22 Projekt systemu na użytek laboratorium (3) Moduły serwera: Centrum pytań i odpowiedzi niezależne od mediów i połączeń Słuchacze poleceń dynamiczna kolekcja (nawiązanie połączenia dodaje element do kolekcji, zerwanie usuwa) Nasłuchiwacze połączeń (TCP,.NET remoting) rejestrują i odrejestrowują słuchacze poleceń 22 / 176

23 Projekt systemu na użytek laboratorium (4) Klasa serwera: kolekcja świadczonych usług: Dictionary<string,IServiceModule> services; kolekcja słuchaczy poleceń (zgłaszających zapytania i przekazujących odpowiedzi) kolekcja nasłuchiwaczy połączeń (przy połączeniu dodają komunikator, przy rozłączeniu usuwają) metody konfiguracyjne: AddServiceModule(string name, IServiceModule service) AddCommunicator(ICommunicator communicator) AddListener(IListener listener) RemoveXYZ(...) 23 / 176

24 Projekt systemu na użytek laboratorium (5) Interfejsy: IServiceModule string AnswerCommand(string command) ICommunicator void Start(CommandD oncommand) void Stop() IListener void Start(CommunicatorD onconnect, CommunicatorD ondisconnect)} Delegaty: void Stop() delegate string CommandD(string command); delegate void CommunicatorD(ICommunicator commander); 24 / 176

25 Projekt systemu na użytek laboratorium (6) Klienci usług Klient każdej usługi jako osobna klasa Klasa bazowa QAClient Communicator communicator string QA(string question) wysyła linię komunikatorowi i pobiera od niego linię klasy potomne: PingClient, FileClient, ChatClient Klasa bazowa Communicator - również dla funkcjonalności serwera bool WriteLine(string line); string ReadLine(); klasy potomne: FileCom, RS232Com, TCPCom, UDPCom, NETCom, / 176

26 Transmisja danych Media transmisyjne: kable miedziane kable koncentryczne skrętka linie skręcone dla zmniejszenia interferencji światłowody włókna szklane przewodzą światło generowne przez diody świecące lub lasery fale radiowe, mikrofale, podczerwień, lasery komunikacja satelitarna transpondery przekazują różne częstotliwości satelity geostacjonarne ok 36 tys. km nad powierzchnią Ziemi niskie orbity km bardziej problematyczne 26 / 176

27 Komunikacja synchroniczna i asynchroniczna Komunikacja na poziomie sprzętu synchroniczna urządzenia pracują we wspólnym rytmie zwykle zegar wysyła sygnały synchronizacyjne asynchroniczna nadawca i odbiorca nie wymagają koordynacji przed wysłaniem każdej porcji danych, nadawanie może zacząć się w dowolnym momencie sygnał nie zawiera dodatkowych informacji o początku i końcu kolejnych bitów (brak sygnału zegarowego) Komunikacja na poziomie aplikacji: synchroniczna proces wysyła zapytanie i czeka na otrzymanie odpowiedzi, blokując inne swoje funkcje asynchroniczna proces wysyła zlecenie wraz ze specyfikacją sposobu powiadomienia o zakończeniu jego obsługi i kontynuuje działanie, a informacja zwrotna przychodzi niezależnie od procesu pytającego 27 / 176

28 Kodowanie bitów prądem elektrycznym Dość naturalny pomysł: stan neutralny (bazowy) brak napięcia bit 1 dodatnie napięcie bit 0 ujemne napięcie Jeśli po każdym bicie następuje powrót do stanu neutralnego, to mamy system RZ (return-to-zero): 28 / 176

29 Kodowanie bitów prądem elektrycznym c.d. Jeśli po każdym bicie nie powracamy do stanu neutralnego, to mamy system NRZ (non-return-to-zero): NRZI (non-return-to-zero inverted) zmiana napięcia gdy 1, bez zmian gdy 0: 29 / 176

30 Komunikacja asynchroniczna RS-232 Kodowanie w RS-232 podobnie do NRZ, ale nieco inaczej: ujemne napięcie bit 1 i stan neutralny dodatnie napięcie bit 0 Standard RS-232-C zdefiniowany w 1969 roku przez Electronic Industries Association (EIA) napięcia +15V i -15V, (w układach UART nawet zakres 3-25V) maksymalna długość kabla 15m oryginalnie 7 bitów danych brak stanu zerowego w bezczynności -15V bit startu określa początek, bit(y) stopu na koniec Błędy synchronizacji ramki, gdy nie rozpoznano poprawnych bitów startu i stopu. 30 / 176

31 RS232 - litera K w ASCII - 0x4b +15V Space LSB MSB Start Stop +3V Start b0 b1 b2 b3 b4 b5 b6 b7 Stop -3V Idle Idle -15V Time Mark 31 / 176

32 Kod Manchester Kodowanie sygnałów cyfrowych zdefiniowane przez G. E. Thomasa w 1949: bit 0 zmiana stanu w środku bitu z niskiego na wysoki bit 1 zmiana stanu z wysokiego na niski Zastosowane np. w modelu 10BASE-T sieci Ethernet. 32 / 176

33 Różnicowy kod Manchester Podobnie do zwykłego kodu Manchester, ale bit 0 zmiana w tym samym kierunku co poprzednia bit 1 zmiana w przeciwnym kierunku niż poprzednia Kod stosowany w wielu modemach telefonicznych Podstawowa zaleta: odporność na zmianę polaryzacji Inne nazwy: biphase mark code (BMC), FM1 33 / 176

34 Sygnalizacja różnicowa (Differential signaling) RS-422, RS-485, Ethernet (skrętka), PCI Express, USB, SATA, FireWire, HDMI 34 / 176

35 Transmisja na duże odległości Nośna o kształcie sinusoidalnym potrafi dotrzeć dalej niż nośna o stałym napięciu. Zastosowanie znajdują trzy główne klasy modulacji: kluczowanie amplitudy (ASK amplitude-shift keying) kluczowanie częstotliwości (FSK frequency-shift keying) kluczowanie fazy (PSK phase-shift keying) Idea tych modulacji jest taka sama jak ich analogowych odpowiedników AM amplitude modulation FM frequency modulation PM phase modulation 35 / 176

36 Modulacja amplitudy nośna sygnał wyjście 36 / 176

37 Modulacja częstotliwości nośna sygnał wyjście 37 / 176

38 Metody modulacji i kluczowania Zwięzły i precyzyjny opis wraz z dobrymi ilustracjami: 38 / 176

39 Metody modulacji i kluczowania modulacja i demodulacja modemy telefoniczne, kablowe, radiowe, optyczne komunikacja jednostronna (sympleks) nadawanie na zmianę (półdupleks) komunikacja dwustronna (pełny dupleks) nadawanie może być jednoczesne (4 żyły, 3 żyły, różne częstotliwości nośnej na 2 żyłach) multipleksowanie kilka fal nośnych o różnych częstotliwościach, szybkość transmisji mierzy się w bodach liczba zmian sygnału nadajnika w ciągu sekundy dla RS-232 od 300 bodów do bodów (tyle samo bitów na sekundę transferu) ogólnie: maksymalny transfer (bps) = liczba bodów log 2 liczba poziomów sygnału 39 / 176

40 Transmisja pakietowa Dane w sieciach są najczęściej przesyłane porcjami zwanymi pakietami efektywniejsze współdzielenie sieci (sprawiedliwy podział zasobów) sprawna kontrola błędów transmisji Hasło pakiety jest ogólne i nieprecyzyjne konkretne protokoły używają ściśle zdefiniowanych formatów ramek W ASCII zdefiniowano znaki specjalne SOH (kod 1, start of header) i EOT (kod 4, end of transmission) jako znaki sterujące komunikacją Zwykle: na początku nagłówek, potem zasadnicza treść przesyłki, potem ewentualnie znacznik końca. 40 / 176

41 Rozpychanie danych (ang. data stuffing) Rozpychanie bajtów rozwiązuje problem możliwości wystąpienia znaków sterujących w treści przesyłki wprowadza się nowy znak sterujący do definiowania odpowiednich dwuznaków (tak samo jak w napisach w języku C symbol \ ) wysyłający koduje treść, a odbierający dekoduje przed przekazaniem dalej 41 / 176

42 Rozpychanie danych Rozpychanie bitów wstawianie bitów w celu ułatwienia synchronizacji przy odbiorze wiadomości, wyrównania mieszanych (multipleksowanych) sygnałów itp. USB w trybie Mode 1 (jak w NRZI, strona 24, ale zmiana napięcia gdy 0, brak gdy 1) problem synchronizacji gdy długie serie jedynek po każdej serii 6 jedynek wstawiane jest dodatkowe zero sieci z rodziny HDLC (High-Level Data Link Control), np. X.25, gdzie komunikacja synchroniczna wymaga wysyłania ciągu synchronizacyjnego FSS (Frame Sync Sequence) zero dodawane, gdy 5 kolejnych jedynek w danych 42 / 176

43 Kontrola błędów transmisji Błędy transmisji, choć dzisiaj są dość rzadkie, mogą pojawiać się na skutek wyładowań atmosferycznych narażenia kabli na silne pola magnetyczne, itp. Mogą to być: przekłamania bitów zanik części przesyłki indukowanie nie nadanych bitów Popularne rozwiązania: kontrola parzystości sumy kontrolne CRC cyclic redundancy check 43 / 176

44 Kontrola błędów Kontrola parzystości parametr: parzystość lub nieparzystość dodawanie bitu do każdego bajtu tak, by suma bitów równych 1 w serii bitów była taka jak określa parametr (zawsze parzysta albo zawsze nieparzysta) Sumy kontrolne: parzystość nie ratuje gdy przekłamane zostają dwa bity wysyłający kalkuluje dla całej przesyłki sumę kontrolną i dołącza ją na koniec przesyłki odbierający kalkuluje sumę po odbiorze i porównuje z wynikiem przesłanym przez serwer różne możliwości kalkulacji sumy kontrolnej np. suma wszystkich bajtów suma liczb dwubajtowych + przeniesienie (gdy suma większa niż maksymalna liczba dwubajtowa) 44 / 176

45 CRC cyclic redundancy check kombinacje rejestrów przesuwających i bramek XOR jedno z popularniejszych rozwiązań (CRC-16-CCITT): wejście bit 12 bit 5 bit 0 łatwa implementacja sprzętowa wiele teoretycznych analiz matematyków w języku arytmetyki wielomianów modulo 2, teoretyków informatyki w języku arytmetyki liczb binarnych, sprzętowców w języku układów,... wersje big-endian i little-endian lepiej zabezpiecza przed najbardziej prawdopodobnymi błędami niż zwykłe sumy kontrolne (np. błędami pionowymi i grupowymi) 45 / 176

46 CRC arytmetyka binarna n-bitowy CRC to reszta z dzielenia ciągu danych przez (n+1)-bitowy dzielnik CRC. Np. dla n=4, dzielnika oraz danych : / 176

47 CRC arytmetyka wielomianów modulo 2 Dzielnik to x 4 + x 3 + x, a dane to x 4 (x 15 + x 14 + x 10 + x 9 + x 6 + x 5 + x): x 15 + x 12 + x 11 + x 8 + x 7 + x 19 + x 18 + x 14 + x 13 + x 10 + x 9 + x 5 : x 4 + x 3 + x x 19 + x 18 + x 16 x 16 + x 14 + x 13 + x 10 + x 9 + x 5 x 16 + x 15 + x 13 x 15 + x 14 + x 10 + x 9 + x 5 x 15 + x 14 + x 12 x 12 + x 10 + x 9 + x 5 x 12 + x 11 + x 9 x 11 + x 10 + x 5 x 11 + x 10 + x 8... W CRC-16-CCITT dzielnik to x 16 + x 12 + x / 176

48 RS-232 oryginalnie do komunikacji typu komputer modem DTE Data Terminal Equipment (np. komputer) DCE Data Communication Equipment (np. modem) komunikacja asynchroniczna i synchroniczna jeden bit w jednostce nadawania (liczba bodów = liczba b/s) kontrola transmisji parzystość parzystość (even parity) nieparzystość (odd parity) brak kontroli (none) 48 / 176

49 RS-232 linie transmisyjne i sygnałowe Złącza: Oryginalnie 25-pinowe (gorąco polecam The Hardware Book) Ostatnio bardziej popularne DB-9, a nawet RJ-45, RJ-12 Podstawowe linie złącza 25-pinowego: TxD (2, Transmitted Data), RxD (3, Received Data) Linie bazowe - GND: 1 Shield Ground, 7 System Ground Sygnał dzwonka telefonicznego (22, RI Ring Indicator) Sygnały gotowości urządzeń: DTR (20, Data Terminal Ready), DSR (6, Data Set Ready) 49 / 176

50 RS-232 połączenia komutowane Procedura połączenia telefonicznego: wybranie numeru sygnał RI u adresata po uzyskaniu połączenia (komputer zdalny wystawia DTR), modem uaktywnia DSR można wysyłać dane zanik sygnału DTR po którejkolwiek ze stron spowoduje rozłączenie Półdupleks sygnały pozwalające na transmisję: RTS Request To Send wysyłany przez komputer gdy chce nadawać CTS Clear To Send wystawiany przez modem, gdy można nadawać DCD (8, Data Carrier Detect lub RLSD Received Line Signal Detector 50 / 176

51 RTS/CTS handshaking Interakcja DTE DSE: DTE wystawia sygnał RTS DCE odpowiada sygnałem CTS o ile modem zdalny nie zgłasza gotowości do nadawania (włączony sygnał DCD) DTE nadaje dane linią TxD, modem przekazuje dalej modem odbierający dane kieruje je na linię RxD urządzenia DTE po zakończeniu wysyłania danych DTE wyłącza RTS (modem wyłącza CTS i DCD w stacji odległej) każda strona może uaktywnić RTS i uzyskać kontrolę nad łączem 51 / 176

52 Protokół XON XOFF Cel: uniknięcie przepełnienia bufora wejściowego przekazanie informacji nadawcy, żeby wstrzymał nadawanie Realizacja sprzętowa lub programowa sprzętowo: sygnały wtórne programowo: przy pełnym dupleksie wysyłanie znaków Ctrl-Q (DC1) i Ctrl-S (DC3) Sygnały wtórne (secondary): podobnie jak w kanale podstawowym, zwykle znacznie wolniej sygnały danych: STxD (14), SRxD (16) sygnały sterujące: SRTS (19), SCTS (13), SDCD (12) 52 / 176

53 Sterowniki portów szeregowych przerwania sprzętowe dla sygnalizacji danych przychodzących, zmian stanu sygnałów sterujących itp. adresy rejestrów używanych do obsługi komunikacji Standardowe parametry interfejsów: Port Obszar adresowy Przerwanie COM1 03F8 03FF IRQ4 COM2 02F8 02FF IRQ3 COM3 03E8 03EF COM4 02E8 02EF Różne inne rozwiązania: wspólne przerwania, wspólny adres, zwłaszcza dla kart wieloportowych 53 / 176

54 Adresacja rejestrów interfejsów szeregowych Przesunięcie Nazwa rejestru A2 A1 A0 LCR Bufor nadajnika (TB) Bufor odbiornika (RB) Mniej znaczący bajt dzielnika Rejest aktywacji przerwań (IER) Bardziej znaczący bajt dzielnika Rejestr identyfikacji przerwań (IDR) Rejestr parametrów transmisji (LCR) Rejestr sterowania modemem (MCR) Rejestr stanu transmisji (LSR) Rejestr stanu modemu (MSR) 54 / 176

55 Komunikacja przez RS-232 INT 14h INT 14h Przerwanie programowe do obsługi portów szeregowych Rejestr AH wybór funkcji 0 inicjalizacja portu wejście: AH = 00h, DX = nr portu, AL = bajt inicjalizujący wyjście: AH = status portu, AL = status modemu 1 wysłanie znaku wejście: AH = 01h, DX = nr portu, AL = znak do wysłania wyjście: AH = informacje o błędach, statusie portu 2 odebranie znaku wejście: AH = 02h, DX = nr portu wyjście: AH = błędy, status portu, AL = odebrany znak 3 odczyt statusów portu i modemu wejście: AH = 03h, DX = nr portu wyjście: AH = status portu, AL = status modemu 55 / 176

56 Komunikacja przez RS-232 język C Funkcje w Ansi-C opakowujące INT 14h z prototypami w bios.h: int bioscom(int cmd, char abyte, int port); unsigned _bios_serialcom(int cmd, char abyte, int port); Parametry cmd wybór funkcji (odpowiednik rejestru AH) abyte bitowo kodowane parametry transmisji port numer portu Funkcje z dos.h / pc.h zapis i odczyt bajtu do/z portu void outportb(unsigned short _port, unsigned char _data); unsigned char inportb(unsigned short _port); 56 / 176

57 Komunikacja przez RS-232 POSIX (1) POSIX Portable Operating System Interface próba standaryzacji różnych odmian Unixa The Open Group (IBM, Sun, HP i inni) Port jako strumień (tak jak pliki) różne nazwy portów w różnych systemach: COM1, /dev/ttys0, /dev/ttyd0, /dev/ser1 polecenie stty do ustawiania i czytania parametrów portów funkcje obsługi strumieni: 1 #include <fcntl.h> 2 int open(const char path, int oag,...); 3 #include <unistd.h> 4 int close(int ldes); 5 ssize_t read(int ldes, void buf, size_t nbyte); 6 ssize_t write(int ldes, const void buf, size_t nbyte); 57 / 176

58 Komunikacja przez RS-232 POSIX (2) Konfiguracja portu Struktura termio 1 struct termios { 2 tcag_t c_iag; / input specic ags (bitmask) / 3 tcag_t c_oag; / output specic ags (bitmask) / 4 tcag_t c_cag; / control ags (bitmask) / 5 tcag_t c_lag; / local ags (bitmask) / 6 cc_t c_cc[nccs]; / special characters / 7 }; Mnóstwo bitowych flag, np: wejściowe: ICRNL, IGNBRK, IGNCR, IGNPAR, INLCR, INPCK, ISTRIP, IXANY, IXOFF, IXON, PARMKR Funkcje z pliku termios.h tcgetattr() i tcsetattr() tcgetispeed() i tcsetispeed() tcgetospeed() i tcsetospeed() 58 / 176

59 Komunikacja przez RS-232 C# Przestrzeń nazw System.IO.Ports Klasa SerialPort ważniejsze składowe: PortName BaudRate, Parity, DataBits, StopBits, Handshake ReadTimeout, WriteTimeout void Open(), void Close() Read(), ReadLine(), ReadByte(),... Write(), WriteLine(), WriteByte(),... DtrEnable, DsrHolding RtsEnable, CtsHolding delegaty: DataReceived, ErrorReceived, PinChanged 59 / 176

60 Protokoły komunikacyjne Potrzeba protokołów komunikacji Definicja fizycznych procesów transmisji to za mało Od specyfikacji funkcjonowania sprzętu do języka komunikacji dla docelowych aplikacji bardzo daleko! Różne potrzeby komunikacyjne wymagają różnych języków komunikacji Zwykle opracowuje się całe zestawy (lub rodziny) protokołów, by w sposób optymalny objąć nimi wszelkie potrzeby. 60 / 176

61 Protokoły połączeniowe i bezpołączeniowe Protokoły połączeniowe przed wysłaniem danych musi nastąpić połączenie po zakończeniu konwersacji należy połączenie zamknąć Protokoły bezpołączeniowe nie wymagają żadnych wstępnych czynności przed wysyłaniem danych brak gwarancji, że pakiety dotrą brak gwarancji, że serwer otrzyma pakiety w takiej kolejności w jakiej były wysłane Protokoły w ramach TCP/IP: Transmission Control Protocol (TCP) protokół połączeniowy User Datagram Protocol (UDP) protokół bezpołączeniowy 61 / 176

62 Techniki używane w protokołach kontrola błędów: bity parzystości, sumy kontrolne, CRC próby naprawiania błędów ustawianie segmentów w kolejności rozpoznawanie duplikatów i ochrona przed opóźnionymi pakietami retransmisja niedostarczonych pakietów kontrola przepływu zatrzymaj i idź metoda przesuwającego się okna przepustowość zwiększona niemal o mnożnik równy rozmiarowi okna odbiorca 1 nadawca odbiorca 2 62 / 176

63 Model OSI 7 warstw OSI Open System Interconnection 1984 model odniesienia opracowany przez ISO (International Organization for Standardization) Warstwa aplikacji Warstwa prezentacji Warstwa sesji Warstwa fizyczna Nagłówek ramki Nagłówek sieciowy Nagłówek sieciowy Nagłówek segmentu Nagłówek segmentu Nagłówek segmentu Dane Dane Dane Warstwa aplikacji Warstwa prezentacji Warstwa sesji Warstwa transportowa Warstwa sieciowa Warstwa fizyczna Stos komunikacji, stos sieciowy, system implementuje stos TCP/IP 63 / 176

64 Warstwy w modelu OSI 1 Fizyczna specyfikacja sygnałów wysyłanych elektrycznie, optycznie, radiowo 2 Łącza danych organizacja ramek, kontrola błędów (rozpychanie danych, sumy kontrolne itp.), nadzór nad warstwą fizyczną 3 Sieci wyznaczanie dróg (trasowanie, routing), uwzględnia topologię sieci 4 Transportowa segmentacja pakietów, kontrola dostawy, retransmisja,... 5 Sesji kontrola wielu aplikacji, kontrola dostępu 6 Prezentacji uzgadnianie reprezentacji danych (postać kanoniczna liczb, znaków), kompresja, szyfrowanie 7 Aplikacji protokoły komunikacji pomiędzy aplikacjami 64 / 176

65 Warstwy w modelu TCP/IP (1) 1 Dostęp do sieci warstwa fizyczna zajmuje się przekazywaniem danych pomiędzy urządzeniami (karty sieciowe, modemy), pozwala na automatyczne przyznawanie adresów IP 2 Internet ustalanie dróg (trasowanie) dla pakietów na podstawie adresów IP, tablic routingu. Routery na tym kończą. 3 Transport (ang. host-to-host layer) kontrola nad dostarczaniem danych, kierowanie do odpowiednich aplikacji (porty TCP, UDP) 4 Warstwa aplikacji protokoły konkretnych aplikacji użytkowych (HTTP, FTP, DNS, itd.) 65 / 176

66 Warstwy w modelu TCP/IP (2) Warstwy OSI vs TCP/IP Warstwy OSI Aplikacji Prezentacji Sesji Transportowa Sieciowa Łącza danych Fizyczna Warstwy TCP/IP Aplikacji Transportowa Internetu Dostępu do sieci Protokoły można przypisać konkretnym warstwom Aplikacje posługują się protokołami najwyższej warstwy (wyjątki: ping, traceroute korzystające z ICMP z warstwy sieciowej) 66 / 176

67 Przepływ informacji i opakowywanie ramek Network Topology Host A Router Router Host B Data Application Application Data Flow process-to-process Application UDP header UDP data Transport Transport host-to-host Transport IP header IP data Internet Internet Internet Internet Internet Frame header Frame data Frame footer Link Link Link Link Link Ethernet Fiber, Satellite, etc. Ethernet 67 / 176

68 Ramki protokołów TCP/IP Ramka UDP: Protocol#Packet_structure Ramka TCP: Control_Protocol#TCP_segment_structure Ramka IP, wersja 4: Ramka IP, wersja 6: Ramka Ethernetu: 68 / 176

69 Protokół IP Protokół bezpołączeniowy Datagramy (odpowiedniki ramek poziomu sprzętowego) nagłówek i pole danych rozmiar: od jednego oktetu danych do 64K oktetów wraz z nagłówkiem suma kontrolna suma 16-bitowych słów w arytmetyce uzupełnień do jedynki Niezależność od warstwy sprzętowej potrzeba niezależnego adresowania adresy 32-bitowe, notacja dziesiętna z kropkami, np: / 176

70 Protokół IP Klasy adresów w IPv4: Klasa początek prefiks+sufiks # sieci # adresów A B C D 1110 E 1111 Zakresy adresów: A: B: C: D - Multicast: E - Zarezerwowane: / 176