[Wybrane
fragmenty]
Spis
treści
1 Wstęp
2 Modele rodziny protokołów komunikacyjnych
2.1
Model sieciowy ISO OSI
2.1.1 Warstwy w modelu ISO OSI
2.2
Model sieciowy TCP/IP
2.3
Porównanie modelu ISO OSI z modelem TCP/IP
2.3.1 Poprawność transmisji
2.3.2 Podejmowanie decyzji
3 Środowisko sieci Norand
3.1
Model działania sieci
3.2
Elementy sieci
3.3
Konfiguracja sieci
4 Wstępne wymagania narzucone przez producenta sprzętu
4.1
Protokoły dostarczane przez producenta a modele sieciowe
4.2
Sesja komunikacyjna
5 Założenia programistyczne
5.1
Rozwiązania programistyczne implikowane przez sprzęt
5.1.1 Niemożność modyfikowania dostarczonych protokołów
5.1.2 Ograniczona szybkość łącza RS-232 i wolny procesor komputera HHC
5.1.3 Długość pakietu danych
5.1.4 Dostęp do łącza i współbieżność
5.1.5 Komunikacja asynchroniczna na łączu RS-232
5.2
Rozwiązania programistyczne implikowane przez specyfikę sieci Norand
i inne uwarunkowania
5.2.1 Dwie sesje komunikacyjne
5.2.2 Poprawność sesji komunikacyjnej
5.2.3 Czy kompresować dane?
5.3
Optymalne rozwiązanie przy przyjętych ograniczeniach
6 Opis protokołu
6.1
Schemat sesji komunikacyjnej
6.2
Formaty pakietów komunikacyjnych
6.2.1 Inicjowanie transmisji przez komputer HHC
6.2.2 Inicjowanie transmisji przez komputer PC
6.2.3 Inicjowanie przesłania pliku przez komputer HHC/PC
6.2.4 Przekazanie inicjatywy do komputera PC
6.2.5 Zakończenie transmisji przez komputer HHC
6.2.6 Zakończenie transmisji przez komputer PC
6.2.7 Dane (komputer HHC/PC)
6.3
Komunikacja od strony komputera HHC
6.3.1 Nawiązanie łączności
6.3.2 Przesyłanie danych
6.3.3 Przekazanie inicjatywy do komputera PC
6.3.4 Odbieranie danych
6.3.5 Zakończenie komunikacji
6.4
Komunikacja od strony komputera PC
6.4.1 Nawiązanie łączności
6.4.2 Odbieranie danych
6.4.3 Otrzymanie inicjatywy
6.4.4 Przesyłanie danych
6.3.5 Zakończenie komunikacji
7 Testy
7.1
Wyznaczenie optymalnej długości pakietu danych
7.2
Zagłodzenie brakiem dostępu do sieci
7.3
Dwie sesje komunikacyjne
7.4
Algorytmy kompresji
7.5
Pierwsza wersja opracowanego protokołu
8 Podsumowanie
8.1
Analiza zrealizowanego rozwiązania
8.1.1 Zrealizowane rozwiązanie
8.1.2 Sugerowane rozszerzenia i modyfikacje
8.2
Obecna sytuacja na rynku komputerów przenośnych
8.3
Wnioski końcowe
Glosariusz
Bibliografia
Dodatki
A. Pakiety komunikacyjne protokołu jawnego drugiej warstwy
A.1
Pakiety komunikacyjne przesyłane ze sterownika sieciowego do komputera PC
A.1.1 Pakiet z danymi
A.1.2 Status końca sesji
A.1.3 Żądanie przesłania danych
A.1.4 Status nieaktywny
A.1.5 Status aktywny
A.1.6 Żądanie aktywacji i statusu
A.1.7 Specjalne żądanie
A.1.8 Status wykonania komendy sterującej
A.2
Pakiety komunikacyjne przesyłane z komputera PC do sterownika sieciowego
A.2.1 Pakiet z danymi
A.2.2 Koniec danych
A.2.3 Inicjalizacja
A.2.4 Odpowiedź na żądanie aktywacji i statusu
A.2.5 Odpowiedź na status aktywny
A.2.6 Deaktywacja portu na jedną minutę
A.2.7 Komenda sterująca
A.3
Komendy specjalne
A.3.1 Komputer PC gotowy
A.3.2 Komenda ponownego inicjowania
A.4
Parametry pakietu inicjowania
A.4.1 Parametry systemowe
A.4.2 Parametry komputera PC
A.4.3 Parametry portu komunikacyjnego
A.5
Parametry aktywacji
B. Fragmenty opisu modułu komunikacyjnego dla programistów
aplikacji dla komputera HHC
B.1
Wstęp
B.3.
Interfejs modułu dla aplikacji na HHC
B.3.1 Stałe
B.3.2 Inicjacja komunikacji
B.3.3 Przesyłanie plików
B.3.4 Odbieranie danych
B.3.5 Koniec komunikacji
B.3.6 Ustawianie powtórzeń
1 Wstęp
We współczesnym świecie informacja jest bardzo cenna. Im szybciej udaje się ją uzyskiwać, gromadzić i analizować, tym sprawniej można działać. W celu przyspieszenia tych procesów wykorzystuje się nowoczesną technologię, a zwłaszcza teleinformatykę. Sieci komputerowe (lokalne, metropolitalne, rozległe), bazy danych dostępne sieciowo, specjalistyczny sprzęt komputerowy - to obecnie nieodzowne rozwiązania w cywilizowanym społeczeństwie.
Również popularne usługi, takie jak inkasowanie należności za zużycie energii, czy też pobieranie opłat za dostawę towarów, coraz częściej wymagają korzystania z nowoczesnej technologii. Nie dziwi już widok inkasenta z gazowni trzymającego w ręku mały, przenośny komputer i na miejscu wystawiającego rachunki ani też widok kierowcy samochodu dostawczego, który po przyjeździe do sklepu – z podobnym komputerem – wystawia na miejscu faktury VAT lub sprawdza, czy ma ze sobą towar, o który prosi właściciel sklepu.
Wraz z rozwojem takich przenośnych komputerów (ang. hand-held computers, w skrócie: HHC), rozwijały się również metody przesyłania danych z komputerów osobistych zgodnych z IBM PC (w skrócie: PC) do komputerów HHC i w drugą stronę. Początkowo do przesyłania danych wykorzystywano zwykły kabel RS-232. Następnie zaczęto stosować pojedyncze, jednoportowe stacje (ang. single-dock), by w końcu przejść do stacji wieloportowych (ang. multi-dock) wraz ze sterownikami umożliwiającymi zbudowanie sieci lokalnych (ang. local area networks, w skrócie: LAN).
Celem niniejszej pracy jest przedstawienie doświadczeń z procesu projektowania i realizacji protokołu komunikacyjnego umożliwiającego wymianę danych pomiędzy komputerem osobistym a komputerem przenośnym firmy Norand model 4500 [NCPG91]. Komunikacja ta odbywa się w środowisku sieci LAN z wieloportowymi stacjami firmy Norand (zwanymi też stacjami dokującymi - ang. docking station) i sterownikiem komunikacyjnym model 4985 (ang. Norand Network Controler 4985), w sposób zapewniający niezawodność oraz poprawność przesyłanych danych. Zadanie to wiązało się z pracą zawodową autora - protokół został opracowany dla firmy Soft-tronik Service Sp. z o.o.
Struktura niniejszej pracy jest następująca. Rozdział drugi zawiera podstawowe pojęcia i definicje dotyczące protokołów komunikacyjnych. Rozdział trzeci zajmuje się opisem środowiska sieci Norand używanego w realizowanym projekcie. W rozdziale czwartym przedstawiono wstępne wymagania projektowe, a w szczególności ograniczenia nałożone na sprzęt. W rozdziale piątym omówiono założenia, jakie towarzyszyły tworzeniu protokołu komunikacyjnego i przedstawiono odrzucone alternatywy. Rozdział szósty zawiera opis zrealizowanego protokołu. W rozdziale siódmym są omówione testy, jakie towarzyszyły pracy projektowej, a rozdział ósmy stanowi podsumowanie wyników pracy. Porównano tam założenia początkowe z efektem końcowym, inne rozwiązania dostępne na rynku, a także omówiono dalsze możliwe kierunki rozwoju. Dodatki zawierają pełny i poprawiony w stosunku do dokumentacji opis pakietów komunikacyjnych przesyłanych pomiędzy sterownikiem komunikacyjnym a komputerem osobistym, uzupełniony o dane uzyskane empirycznie, oraz fragmenty opisu modułu komunikacyjnego dla programistów piszących aplikacje na komputer przenośny.
Jak już wspomniałem, opisywany protokół komunikacyjny powstał w ramach mojej pracy zawodowej - chciałbym więc przede wszystkim podziękować firmie Soft-tronik Service Sp. z o.o. za wyrażenie zgody na wykorzystanie tego materiału do przygotowania niniejszej rozprawy. Wdzięczny jestem także Pani dr Janinie Mincer-Daszkiewicz za podjęcie się roli promotora oraz za cenne uwagi, które niewątpliwie przyczyniły się do znacznego poprawienia strony prezentacyjnej niniejszej pracy. Składam podziękowania również swoim najbliższym za doping i wsparcie.
2 Modele rodziny protokołów komunikacyjnych
Celem prezentowanej pracy było zaprojektowanie i zaprogramowanie nowego protokołu komunikacyjnego dla konkretnego rozwiązania sprzętowego. W niniejszym rozdziale wprowadzimy podstawowe pojęcia związane z tą dziedziną. Zostaną skrótowo zaprezentowane dwa warstwowe modele sieci - ISO OSI zaproponowany przez Międzynarodową Organizacją Standaryzacyjną (ang. International Organization for Standarization, w skrócie: ISO) oraz TCP/IP [Co97, Na94, Sp93, St94, NL96]. Ponadto zostanie omówiony sprzęt, na którym ma działać realizowany protokół.
2.1 Model sieciowy ISO OSI
Aby umożliwić przesyłanie informacji w sieci składającej się z różnych i mogących podlegać wymianie komputerów, niezbędne było wypracowanie ścisłych reguł, zwanych protokołami komunikacyjnymi. W roku 1984 organizacja ISO sformułowała wzorcowy model systemów otwartych (ang. Open System Interconnection Reference Model, w skrócie: OSI), który jest podstawą do tworzenia nowych protokołów. Wszystkie systemy zgodne z tym modelem nazywamy otwartymi.
Głównym założeniem modelu ISO OSI jest podział zbioru funkcji komunikacyjnych na odpowiednie warstwy (ang. layers, por. rys. 2.1). Wyodrębniono siedem warstw. Każda z nich jest podzbiorem zbioru funkcji komunikacyjnych, dobranych w taki sposób, by było możliwe traktowanie go jako pewnej całości wykonującej autonomiczne zadanie. Ponadto warstwy są powiązane ze sobą w strukturę hierarchiczną. Komunikacja odbywa się tylko między równorzędnymi warstwami w różnych systemach otwartych, przy użyciu usług transmisji danych oferowanych przez warstwy niższe w hierarchii. Każda z warstw modelu ISO OSI jest opisana przez protokół wymiany informacji między równorzędnymi warstwami oraz przez zbiór usług komunikacyjnych udostępnianych warstwie znajdującej się bezpośrednio nad nią.
Rys. 2.1 Warstwowa organizacja oprogramowania sieciowego
2.1.1 Warstwy w modelu ISO OSI
Model ISO OSI składa się z siedmiu warstw (por. rys. 2.2), które – począwszy od najniższej do najwyższej – nazywają się: fizyczna, łącza, sieci, transportu, sesji, prezentacji oraz aplikacji.
|
Warstwa |
Nazwa |
Funkcja |
|
7 |
Aplikacji |
Udostępnienie specjalizowanych funkcji sieciowych |
|
6 |
Prezentacji |
Formatowanie danych, konwersja do postaci kanonicznej |
|
5 |
Sesji |
Umożliwienie wymiany danych między aplikacjami |
|
4 |
Transportu |
Dostarczenie niezawodnego przesyłu danych między węzłami |
|
3 |
Sieci |
Przesyłanie pakietów danych pomiędzy sieciami |
|
2 |
Łącza |
Zapewnienie niezawodnego łącza pomiędzy węzłami |
|
1 |
Fizyczna |
Transfer danych binarnych po medium |
Rys. 2.2 Model ISO OSI
1. Warstwa fizyczna (ang. physical layer) definiuje sposób wysyłania i odbierania danych w sieci (np. sposób kodowania bitów). Sieć na poziomie tej warstwy składa się z okablowania (np. UTP, ang. unshielded twisted pairs), z kart sieciowych służących do podłączenia urządzeń do okablowania oraz z mechanizmów detekcji błędnych sygnałów w medium. Na poziomie tej warstwy działają urządzenia do wzmacniania sygnału (ang. repeater). Przykładowymi protokołami tej warstwy są: ISO 2110, IEEE 802, IEEE 802.2[1].
2. Warstwa łącza (ang. data link layer) definiuje format danych przesyłanych siecią (nazywany ramką, ang. frame), synchronizuje transmisje oraz obsługuje błędy na poziomie ramek, umożliwiając transmisje danych z wykorzystaniem warstwy fizycznej. Największa ramka jaką można przesłać jest definiowana przez maksymalną jednostkę transmisji (ang. maximum transmission unit, w skrócie: MTU). W tej warstwie odbywa się składanie ramek i weryfikacja ich poprawności za pomocą sum kontrolnych (na przykład CRC, ang. cyclic redundancy check). W związku z tym, że transmisja jest niepewna, warstwa ta opisuje metody potwierdzania otrzymania poprawnej ramki. Na tym poziomie są realizowane metody dostępu do medium transmisyjnego, takie jak dostęp wielokrotny z wykorzystaniem fali nośnej i wykrywaniem kolizji (ang. Carrier Sense Multiple Access with Collision Detect (CSMA/CD)) używany w sieciach Ethernet czy dostęp na podstawie krążącego znacznika (ang. Token Ring) używany na przykład w sieciach FDDI (ang. Fiber Distributed Data Interconnect). Również w tej warstwie adresuje się przesyłane ramki na potrzeby warstwy fizycznej. Tutaj definiuje się tzw. mosty (ang. bridge), to jest urządzenia umożliwiające przesyłanie danych pomiędzy dwiema sieciami, które mogą się różnić miedzy sobą w warstwie fizycznej, czy w metodzie dostępu do medium transmisyjnego. Przykładowymi protokołami tej warstwy są: SLIP, CSLIP, PPP, HDLC.
3. Warstwa sieci (ang. network layer) jest odpowiedzialna za interakcje pomiędzy systemami otwartymi a siecią. Tutaj określa się podstawowe jednostki danych, nazywane pakietami (ang. packet), których używa się do komunikacji w ramach warstwy sieci — mogą się one różnić wielkością od MTU (por. warstwa łącza). Również tutaj ustala się zasady adresowania odbiorcy oraz wyznaczania najbardziej ekonomicznych tras przesyłania komunikatów, zarówno pod względem logicznym, jak i fizycznym. W przypadku gdy pakiet przesyłany przez sieć jest większy niż MTU, przed przesłaniem go do warstwy łącza, dzieli się go na ramki. Na tym poziomie definiuje się tzw. rutery (ang. router), czyli urządzenia do przesyłania danych pomiędzy wieloma sieciami. Przykładowymi protokołami tej warstwy są: IP, ARP, RARP, ICMP, RIP, OSPF, BGP, IGMP.
4.
Warstwa transportu (ang. transport layer) dostarcza mechanizmy
transportu danych między jednym programem użytkownika, a drugim (ang.
end-to-end). Warstwa ta jest też
odpowiedzialna za zastosowanie wymaganych parametrów transmisji danych.
Nadzoruje ona poprawność wysyłania i odbierania danych, sprawdza
czy dane przychodzą w odpowiedniej kolejności (czy są odbierane
w tej samej kolejności, w jakiej były wysyłane) oraz dba o
czasową efektywność transmisji.
Przykładami mogą tu być dwa protokoły - TCP i UDP.
5. Warstwa sesji (ang. session layer) jest odpowiedzialna za tworzenie sesji logicznej tzn. za nawiązanie, podtrzymywanie i zerwanie połączenia między dwoma urządzeniami w sieci. Definiuje ona format danych, który będzie wykorzystywany przy transmisji takim logicznym łączem, weryfikuje poprawność danych i dba o to, by w razie chwilowego zerwania połączenia zapewnić spójność przesyłanych danych. Również na tym poziomie odbywa się ustalanie odpowiedniości pomiędzy logicznymi nazwami urządzeń a ich fizycznymi adresami. (Warstwa ta została dodana do modelu w późniejszej fazie w celu umożliwienia zdalnego dostępu za pomocą terminala - była to jedna z głównych usług oferowanych przez pierwsze sieci publiczne). Przykładowym protokołem tej warstwy jest RPC.
6. Warstwa prezentacji (ang. presentation layer) jest odpowiedzialna za konwersję lokalnej reprezentacji danych do postaci kanonicznej i odwrotnie. W postaci kanonicznej obowiązuje standardowe starszeństwo bajtów i konwencja pakowania struktur niezależnych od urządzenia. Do zadań tej warstwy należy również kodowanie lub dekodowanie danych, kompresja danych czy konwersja obrazów graficznych na ciągi bitów. Przykładowymi protokołami tej warstwy są XDR czy ASN.1.
7. Warstwa aplikacji (ang. application layer) jest wykorzystywana przez aplikacje, które działają w sieci. Przykładowymi aplikacjami są emulatory terminali, programy poczty elektronicznej czy przeglądarki Internetowe. Przykładowymi protokołami tej warstwy są: DNS, TFTP, BOOTP, FTP, SNMP, TELNET, SMTP, MIME, NFS, FINGER, RLOGIN.
2.2 Model sieciowy TCP/IP
Model ISO OSI jest szeroko stosowany — wykorzystuje go na przykład rodzina protokołów X.25. Niemniej jednak w sieci Internet jest stosowane nieco odmienne rozwiązanie, tzw. model warstwowy TCP/IP. Model ten nie został opracowany w wyniku prac komitetów standaryzacji, ale dzięki badaniom, które doprowadziły do powstania nowego zestawu protokołów. Wprawdzie można by rozpatrywać model TCP/IP w modelu ISO OSI, ale wymagałoby to połączenia bądź rozdzielenia niektórych warstw tego ostatniego.
Model TCP/IP składa się z czterech warstw. Są to – począwszy od najniższej do najwyższej – następujące warstwy: interfejsu sieciowego, sieci, transportu i aplikacji.
|
Warstwa |
Nazwa |
Funkcja |
|
4 |
Aplikacji |
Obsługa programów użytkowników działających w sieci |
|
3 |
Transportu |
Zapewnienie bezbłędnej komunikacji między jednym programem użytkownika a drugim |
|
2 |
Sieci |
Obsługa datagramów IP |
|
1 |
Interfejsu sieciowego |
Obsługa ramek sieci fizycznej |
Rys. 2.3 Czterowarstwowy model TCP/IP
1. Warstwa interfejsu sieciowego (ang. link layer) definiuje sprzęt oraz sterowniki do niego. Jest ona odpowiedzialna za przyjmowanie tzw. datagramów IP (odpowiedników pakietów) i przesyłanie ich przez sieć w postaci ramek.
2. Warstwa sieci (ang. network layer) jest odpowiedzialna za obsługę komunikacji jednego komputera z drugim. Po otrzymaniu pakietu (od warstwy transportu) wraz z informacjami o odbiorcy, warstwa ta przekształca pakiet w datagram IP, wypełnia nagłówek, sprawdza dokąd przesłać datagram (czyli realizuje trasowanie (ang. routing) — wybiera trasę, którą ma być wysłany pakiet) i przekazuje do odpowiedniego interfejsu sieciowego. Warstwa ta jest również odpowiedzialna za obsługę przychodzących datagramów. W takim przypadku sprawdza ona poprawność datagramu, jak również wyznacza jego dalszą drogę lub też przetwarza go na miejscu. Warstwa ta odpowiada ponadto za wysyłanie komunikatów kontrolnych o błędach, jak również za odbiór takich komunikatów. Protokołem wykorzystywanym w takich przypadkach jest ICMP.
3. Warstwa transportu (ang. transport layer) jest odpowiedzialna za zapewnienie komunikacji między jednym programem użytkownika a drugim. W tej warstwie znajdują się mechanizmy, które mogą zapewnić poprawne przesyłanie: dane mają nadejść bez błędów i w kolejności wysyłania. Jest to realizowane przez potwierdzanie i ponowne wysyłanie utraconych pakietów, jak również ich zapamiętywanie po wysłaniu. Ponadto warstwa transportowa jest odpowiedzialna za przyjmowanie zleceń od wielu programów i przekazywania komunikatów do wielu programów. W związku z tym do każdego pakietu dodaje się pewne informacje, takie jak kod identyfikujący program użytkownika, czy kod programu docelowego.
4. Warstwa aplikacji (ang. application layer) to środowisko, w którym działają programy użytkowników korzystających z sieci. Mają one do wyboru dwie metody komunikacji realizowane przez warstwę transportu: ciąg pojedynczych komunikatów albo ciągły strumień bajtów.
2.3 Porównanie modelu ISO OSI z modelem TCP/IP
Modele ISO OSI oraz TCP/IP różnią się w dwóch istotnych kwestiach. Pierwsza z nich, to metoda weryfikacji poprawności transmisji danych, a druga, to umiejscowienie ośrodków (warstw) podejmowania decyzji. Różnice te są spowodowane różnymi wymogami, jakie były brane pod uwagę przy tworzeniu tych modeli.
2.3.1 Poprawność transmisji
W modelu ISO OSI każda z warstw przeprowadza własną weryfikację otrzymywanych danych, łącznie z potwierdzeniami. Ponadto w modelu tym znajdują się mechanizmy gwarantujące poprawność komunikacji nawet w przypadku, gdy zawiedzie sprzęt i trzeba go ponownie uruchomić. Wynikiem takiego podejścia jest wysoka niezawodność komunikacji.
Inaczej wygląda kwestia poprawności transmisji w modelu TCP/IP. Tutaj podstawą jest idea komunikacji pomiędzy programami użytkowników. W tym modelu pozwalamy na tracenie danych lub na ich uszkadzanie, bez ciągłych prób ratowania sytuacji. Warstwa interfejsu sieciowego nie zapewnia niezawodnego przesyłania danych. Prawie całe wykrywanie i korekcja błędów odbywa się w warstwie transportu. Wykorzystuje się tu mechanizmy sum kontrolnych, potwierdzeń i przekraczania terminu. Wynikiem takiego podejścia jest ułatwienie zrozumienia i poprawnego zaimplementowania protokołów w tym modelu. Jednocześnie oznacza to, że datagramy mogą być dostarczane zbyt późno, mogą być uszkodzone lub w ogóle mogą nie dochodzić do adresata, a pomimo to będziemy mieć poprawną komunikację.
2.3.2 Podejmowanie decyzji
Omawiane modele obrazują zupełnie inne podejście do kwestii podejmowania decyzji związanych z komunikacją.
W model ISO OSI to sieć stanowi centrum podejmowania decyzji i miejsce udostępniające usługi transportu. Rodziny protokołów opracowanych na podstawie tego modelu (na przykład X.25) zakładają istnienie w sieci operatorów, którzy kontrolują ruch, wyznaczają trasy przepływu danych i zapewniają niezawodność transportu. Przy takich założeniach, urządzenia podłączane do sieci mogą być relatywnie proste, gdyż nie biorą udziału w podejmowaniu decyzji przy wyznaczaniu tras komunikatów.
Twórcy modelu TCP/IP wyszli z innego założenia. Urządzenie podłączone do sieci nie jest biernym odbiornikiem i nadajnikiem komunikatów, ale aktywnym węzłem sieci, współpracującym z wszystkimi protokołami sieciowymi, z jakich chce skorzystać. Urządzenie bierze udział w wyznaczaniu tras komunikatów, reaguje na awarie medium transportowego i wyznacza trasy zastępcze. Jednocześnie nie istnieją operatorzy zapewniający niezawodność transportu, czy wyznaczający trasy przepływu danych.
*
Z powyższego porównania wynika, że model TCP/IP jest stosunkowo prostym systemem dostarczania komunikatów, działającym na niepewnych mediach transmisyjnych, do którego są przyłączone urządzenia podejmujące decyzje. Natomiast model ISO OSI jest systemem umożliwiającym prostym urządzeniom skorzystanie z pewnej, i na swój sposób inteligentnej, infrastruktury sieciowej.
3 Środowisko sieci Norand
Sieć Norand 4000 jest specjalistyczną siecią umożliwiającą wymianę danych pomiędzy przenośnymi komputerami HHC, model 4500, a komputerem PC, z wykorzystaniem stacji wieloportowej 4960 oraz sterownika sieciowego 4985.
3.1 Model działania sieci
Sieć Norand 4000 jest wykorzystywana w trybie przetwarzania wsadowego. W dzień użytkownik komputera HHC zbiera za jego pomocą dane w terenie (jest to środowisko pracy użytkownika komputera HHC; na przykład dla sprzedawcy obwoźnego terenem będą sklepy, a dla inkasenta gazowego - mieszkania).
Po powrocie do bazy (tzn. siedziby macierzystej firmy) użytkownik uruchamia na komputerze HHC funkcje wymiany danych i umieszcza swój komputer w jednym z portów stacji dokujących. Komputer HHC wykrywa podłączenie do sieci i zaczyna wysyłać żądania przydzielenia prawa do skorzystania z medium transmisyjnego. Po uzyskaniu przez HHC takiego pozwolenia (przydzielanego przez sterownik sieciowy), rozpoczyna się sesja komunikacyjna pomiędzy komputerem HHC, a komputerem PC, z wykorzystaniem sterownika sieciowego jako mostu pomiędzy siecią LAN a PC.
W wypadku poprawnego zakończenia sesji komunikacyjnej komputer HHC przechodzi w stan uśpienia, a jeśli wystąpi błąd, ponawia próbę uzyskania pozwolenia na skorzystanie z medium transmisyjnego.
3.2 Elementy sieci
Sieć Norand 4000 składa się z następujących elementów:
1.
Dowolny
komputer PC z co najmniej jednym portem szeregowym typu RS-232.
2. Od 1 do 72 komputerów HHC, model 4500 (por. rys. 3.1). Komputery te mają 16 bitowy procesor z zegarem 10 MHz (NEC 16 bit V25+) i są wyposażone w pamięć RAM o pojemności 1, 2 lub 4 MB. Do komunikacji z innymi urządzeniami mają uniwersalne złącze obsługujące zarówno RS-232, jak i RS-485 (do komunikacji w sieci LAN). Komputerem zarządza system operacyjny MS DOS w wersji 3. Jako standardowe wejście jest używana klawiatura numeryczna 23 klawiszowa lub alfanumeryczna 40 klawiszowa, a jako standardowe wyjście - czarno-biały 16 liniowy wyświetlacz ciekłokrystaliczny (128x128 punktów). Ponadto komputery są wyposażone w trzy systemy bateryjnego podtrzymywania pamięci (operacyjny, awaryjny i super awaryjny).
Rys. 3.1 Komputery HHC - model 4500
3. Sterownik sieciowy, model 4985 (por. rys. 3.2). Ma on jedno złącze RS-232 do komunikacji asynchronicznej z prędkością 19.2 Kbps lub synchronicznej z prędkością 9.6 Kbps i jedno złącze RS-485 do komunikacji w sieci LAN z prędkością 500 Kbps. Sterownik jest wyposażony w 512 KB pamięci RAM. Jest on w stanie obsłużyć maksymalnie 72 komputery HHC w 12 wieloportowych stacjach dokujących i może dostarczyć zasilania dla dwóch takich stacji. W przypadku potrzeby zasilania większej liczby stacji dokujących trzeba skorzystać z dodatkowych modułów zasilających (ang. auxilary power unit, w skrócie APU).
Rys. 3.2 Sterownik sieciowy - model 4985
4. Od 1 do 12 wieloportowych stacji dokujących, model 4960 (por. rys. 3.3), wyposażonych w dwa złącza RS-485. Jedno złącze służy jako wejściowe, a drugie jako wyjściowe. Zasilanie stacji dokujących odbywa się przez złącza RS-485. Do złączy można podłączyć sterownik sieciowy, inną wieloportową stację dokującą lub APU. Poza funkcjami komunikacyjnymi, stacje dokujące pełnią rolę zasilaczy dla komputerów HHC i umożliwiają im ładowanie baterii.
5. Od 0 do 3 dodatkowych APU model 4970 wyposażonych w dwa złącza RS-485. Podobnie jak w przypadku stacji dokujących, jedno złącze jest wejściowe, a drugie wyjściowe. APU jest w stanie zasilić maksymalnie do czterech stacji dokujących.
Rys. 3.3 Wieloportowa stacja dokująca - model 4960
3.3 Konfiguracja sieci
Podstawowa sieć Norand 4000 (por. rys. 3.4) składa się ze sterownika sieciowego podłączonego do komputera PC przez port RS-232 oraz do wieloportowej stacji dokującej podłączonej przez port RS-485.
Rys. 3.4 Konfiguracja podstawowa (łącze asynchroniczne - RS-232, sieć LAN - RS-485)
Możliwe są też konfiguracje zaawansowane wykorzystujące moduły APU do zasilania większej liczby wieloportowych stacji dokujących. Każdy z modułów APU ma możliwość zasilenia kolejnych czterech wieloportowych stacji dokujących. Mogą one być połączone szeregowo w sieci stacji dokujących, tak że mamy przeplot (por. rys. 3.5), albo równolegle - wówczas do sterownika podłączamy ciąg modułów APU, a do każdego z nich stacje dokujące (por. rys. 3.6).
Rys. 3.5 Połączenie szeregowe
Rys. 3.6 Połączenie równoległe
4 Wstępne wymagania narzucone przez producenta sprzętu
W sieci Norand 4000 są zastosowane rozwiązania, które w znacznej mierze ograniczają możliwości projektowania nowych protokołów komunikacyjnych. Do najważniejszych ograniczeń należy brak możliwości modyfikowania protokołów dostarczanych przez producenta sprzętu (por. p. 4.1) oraz narzucony schemat sesji komunikacyjnej (por. p. 4.2). Innym z ograniczeń jest możliwość wykorzystania pamięci sterownika sieciowego przez programistę tylko do jednego, ściśle określonego celu - do przechowywania plików. Plików tych może być maksymalnie 40 i nie mogą zajmować łącznie więcej pamięci niż 350 KB. Nie ma możliwości napisania własnego oprogramowania, które by było uruchamiane w pamięci sterownika sieciowego.
Kolejnym ograniczeniem jest wielkość pamięci, jaką dysponuje komputer HHC. Rozmiary dostępne, to 1 MB, 2 MB i 4 MB. Z tej pamięci 640 KB jest przeznaczone na pamięć operacyjną zarządzaną systemem operacyjnym DOS wersja 3. Z reszty dostępnej pamięci jest tworzony wirtualny dysk (RAM-dysk). Na nim się umieszcza kod wykonywalny programu, jak również bazy danych potrzebne do poprawnego działania oprogramowania na komputerze HHC. Pamięci operacyjnej nie można rozszerzyć.
4.1 Protokoły dostarczane przez producenta a modele sieciowe
Sterownik sieciowy obsługuje dwa protokoły komunikacyjne. Jednym z nich jest NPCP (ang. Norand Portable Communications Protocol), który działa w sieci LAN opartej o RS-485, drugim zaś tzw. protokół jawny (który opiszemy później), obsługujący komunikację asynchroniczną przez port RS-232 z komputerem PC. Protokół NPCP jest protokołem tajnym (jego opis nie jest dostępny) i służy do komunikacji między sterownikiem sieciowym, a komputerem HHC. Zarówno komputery HHC, jak i sterownik sieciowy mają zdefiniowaną obsługę tego protokołu w pamięci ROM - modyfikacja protokołu nie jest możliwa. Z protokołem jawnym jest trochę inaczej. Producent dostarczył pełną specyfikacje protokołu, tak, by było możliwe napisanie programu na komputer PC. Jednak ze względu na zaszycie obsługi tego protokołu w pamięci ROM sterownika sieciowego, jego modyfikacja nie jest możliwa.
Pomimo tajności protokołu NPCP, na podstawie protokołu jawnego, a także na podstawie interfejsu programisty na komputer HHC do protokołu tajnego można stwierdzić, że obydwa są protokołami odpowiadającymi warstwie drugiej modelu ISO OSI, czyli warstwie łącza (na przykład protokół NPCP wykorzystuje metodę krążącego znacznika do przydzielania uprawnień do nadawania). Oznacza to, że sterownik sieciowy działa jako most pomiędzy siecią LAN, a siecią łączącą sterownik z komputerem PC.
Protokół jawny umożliwia weryfikację poprawności przesyłanych danych dzięki mechanizmom kontroli zawartości ramki, jak również zapewnia dostarczenie wszystkich ramek, dzięki mechanizmowi potwierdzeń. Ponieważ opis protokołu NPCP nie jest dostępny, więc pomimo zapewnień producenta o poprawności komunikacji należy założyć, że komunikacja może być zawodna.
Obydwa protokoły zostały zaprojektowane w sposób umożliwiający jednoczesną komunikację trzech komputerów HHC z komputerem PC. Nie ma możliwości zwiększenia tej liczby (ale można ją zmniejszyć).
Widać stąd, że projektowany protokół powinien zapewniać podobną funkcjonalność co protokoły warstwy transportu modelu ISO OSI lub TCP/IP. Powinien on dostarczyć niezawodną komunikację pomiędzy aplikacjami na komputerach HHC i komputerze PC. Jednocześnie protokół ten, podobnie jak model TCP/IP, jest opracowywany dla specyficznego, istniejącego już rozwiązania i powinien pasować do modelu czterowarstwowego, który dla niego zaproponowano. Dwie dolne warstwy - odpowiedniki warstwy fizycznej i łącza modelu ISO OSI - zostały zaprojektowane i dostarczone przez producenta. Warstwa trzecia powstała dzięki tej pracy. Warstwa czwarta odpowiada warstwie aplikacji. Projektowany protokół nie może jednak odpowiadać protokołowi żadnej z warstw zarówno w modelu ISO OSI jak i TCP/IP z uwagi na ograniczenie, które zostanie przedstawione w p. 4.2.
4.2 Sesja komunikacyjna
Kolejnym ograniczeniem narzuconym przez producenta jest schemat sesji komunikacyjnej. Ma ona zawsze ten sam porządek zaszyty w protokole NPCP, zostawiający bardzo niewiele możliwości przy projektowaniu protokołów warstw wyższych. Sesję komunikacyjną rozpoczyna zawsze komputer HHC. Po zainicjowaniu sesji przesyła on swoje dane do komputera PC, przy wykorzystaniu sterownika sieciowego jako mostu pomiędzy siecią LAN, a siecią asynchroniczną. Po zakończeniu transmisji danych, komputer HHC przekazuje inicjatywę do komputera PC, który teraz może przesłać dane przeznaczone dla komputera HHC. Po zakończeniu przesyłania danych sesja kończy się. Nie istnieje komunikacja przeplatana, czyli np. HHC ŕ PC (żądanie jakiś danych), PC ŕ HHC (przesłanie danych), HHC ŕ PC (przesłanie potwierdzenia otrzymania poprawnych danych) … itd. Jedyna weryfikacja poprawności i przesyłanie potwierdzeń odbywa się na trasach HHC ßŕ sterownik sieciowy (co stwierdzono analizując interfejs programisty do protokołu NPCP dla komputera HHC) oraz sterownik sieciowy ßŕ PC.
Jak z tego widać, pomimo czterowarstwowego modelu, podobnego do TCP/IP i funkcjonalności podobnej do warstwy transportu, trzecia warstwa modelu sieci Norand będzie musiała mieć inną charakterystykę - protokół w niej działający będzie mógł być wykorzystany tylko w tej sieci. Jest więc to zamknięty model rodziny protokołów.
5 Założenia programistyczne
Założenia programistyczne, które trzeba było przyjąć przed przystąpieniem do projektowania protokołu, można podzielić na dwie kategorie. Jedną z nich stanowią ograniczenia wynikające z charakterystyki sprzętu i protokołów warstwy drugiej wykorzystywanych w sieci Norand. Na drugą składa się specyfika pracy osób, które docelowo korzystają z komputerów HHC oraz z życzeń lub żądań wyrażanych przez programistów, którzy tworzyli aplikacje mające korzystać z opracowywanego protokołu.
5.1 Rozwiązania programistyczne implikowane przez sprzęt
Z powodu specyfiki sprzętu oraz niejawności protokołu tajnego, okazało się, że rozwiązania programistyczne wykorzystane do zrealizowania protokołu komunikacyjnego będą musiały być bardzo specyficzne.
Omówimy teraz podstawowe wnioski wynikające z tych ograniczeń i spróbujemy zaproponować optymalne rozwiązanie.
5.1.1 Niemożność modyfikowania dostarczonych protokołów
Zaszycie protokołów drugiej warstwy w pamięci ROM sterownika sieciowego oraz komputera HHC i uniemożliwienie ich modyfikacji jest jedną z najbardziej odczuwalnych restrykcji. Uniemożliwia ona wymianę tych protokołów na inne i zmusza do budowania protokołów wyższych warstw wykorzystując mechanizmy dostarczane przez warstwę drugą. Podstawowe ograniczenia wynikające z tego, to brak możliwości przesyłania potwierdzeń na poziomie HHC ßŕ PC, ustalenie schematu sesji komunikacyjnej „na sztywno” oraz niemożność rozbudowania funkcjonalności sterownika sieciowego.
Protokoły dostarczone przez producenta umożliwiają otrzymywanie potwierdzeń dotarcia pakietu do odbiorcy, ale tylko w ramach pojedynczych protokołów (tj. tajnego i jawnego). Mamy więc informacje o tym, że pakiet wysyłany z komputera HHC do sterownika sieciowego tam dotarł, ale już nie mamy pewności czy ten pakiet zostanie przesłany ze sterownika sieciowego do komputera PC oraz czy nie wystąpi błąd podczas jego transmisji. To powoduje, że korekcje błędów transmisyjnych jesteśmy w stanie przeprowadzić na bieżąco tylko pomiędzy komputerem HHC a sterownikiem oraz sterownikiem a komputerem PC. Wynika stąd konieczność dodania potwierdzania poprawności danych w nowo projektowanym protokole na poziomie HHC ßŕ PC.
Okazuje się jednak, że zrobienie takich potwierdzeń w projektowanym protokole wcale nie jest banalne. Sesja komunikacyjna ma zawsze ten sam, z góry ustalony porządek. Komunikację nawiązuje komputer HHC i on pierwszy przesyła swoje dane, potem przekazuje inicjatywę do komputera PC, który może przesłać swoje. Wraz z zakończeniem przesyłania danych z komputera PC do komputera HHC, sesja komunikacyjna kończy się. Nie istnieje komunikacja przeplatana, czyli np. HHC ŕ PC, PC ŕ HHC, HHC ŕ PC … itd. Oznacza to, że weryfikacje poprawności transmisji możemy przeprowadzać tylko innymi metodami, takimi jak weryfikacja poprawności struktury pakietów, weryfikacja długości danych, wykorzystanie algorytmu CRC na poziomie HHC ßŕ PC, czy też wysłanie informacji o poprawności etapu sesji w chwili jego kończenia - komputer HHC przesyła informacje do komputera PC o tym, że wszystkie dane zostały wysłane poprawnie, komputer PC przesyła podobną informacje do komputera HHC. Jedynym wyjątkiem jest zerwanie przez komputer HHC komunikacji. Kiedy zostaje wywołana funkcja zerwania komunikacji, może on przesłać do komputera PC informacje o błędzie. Daje to pewne możliwości informowania o wystąpieniu błędów i reagowania na tą sytuację.
Jednocześnie pamięć sterownika sieciowego nie może być wykorzystana do uruchomienia jakiejkolwiek aplikacji. Jedyna możliwość jaka pozostała, to przechowywanie plików na RAM-dysku sterownika. Pliki te mogą być skopiowane do RAM-dysku komputera HHC, tak by było możliwe uruchomienie środowiska DOS na komputerze HHC. Jest to więc zbiór plików, który się kopiuje do nowych komputerów HHC w celu utworzenia odpowiedniego środowiska pracy.
5.1.2 Ograniczona szybkość łącza RS-232 i wolny procesor komputera HHC
Kolejne elementy decydujące o projektowanym protokole, to szybkość łącza RS-232 i typ procesora zastosowanego w komputerach HHC.
Każdy z protokołów poza przesłaniem danych uzyskanych od warstwy wyższej, dokłada pewne dane właściwe sobie, które służą realizacji zadań powierzonych danej warstwie. Wydawałoby się, że szybkość jaką uzyskujemy w sieci LAN za pomocą złącza RS-485 (500 Kbps) jest w zupełności wystarczająca do obsługi sieci 72 komputerów HHC i dodawania nawet sporej ilości informacji nadmiarowej w projektowanym protokole. Niestety okazuje się, że w sieci Norand mamy do czynienia z wąskim gardłem w postaci złącza RS-232 na sterowniku sieciowym, które jest w stanie przesyłać dane tylko z prędkością 19,2 Kbps. W związku z tym projektowany protokół powinien minimalizować ilość danych nadmiarowych, które będzie dokładał w pakiecie przed przesłaniem go do warstwy drugiej.
Producent przewidział dwa rodzaje pakietów, które są wykorzystywane na łączu RS-232. Pierwszy z nich, to pakiety kontrolne. Wykorzystuje się je do zainicjowania sterownika sieciowego przez komputer PC, przesyłania potwierdzeń pomiędzy komputerem PC a sterownikiem, informowania o tym czy obydwie strony są nadal aktywne. Pakiety kontrolne mają określoną składnię i długość. Drugi, to pakiety z danymi. W zależności od trybu pracy sterownika sieciowego, ustalanego podczas jego zainicjowania, mamy do wyboru dwa rodzaje pakietów do przesyłania danych. Mogą one mieć stałą, z góry określoną długość lub mieć długość zmienną. W pierwszym przypadku podczas zainicjowania sterownika sieciowego przez PC należy podać długość pakietów z danymi, w drugim za koniec pakietu uznaje się wyszczególniony znak - standardowo CR. Pomimo lepszego wykorzystania pasma transmisji przy zastosowaniu dynamicznej długości pakietów z danymi, metoda ta nie nadaje się do zastosowania w przypadku przesyłania danych, które mogą zawierać dowolny znak ASCII (również te niedrukowalne). Z tego względu trzeba wykorzystać stały rozmiar pakietu w zakresie od 258 - 263 bajtów (są to jedyne długości dopuszczane przez producenta i możliwe do ustawienia na sterowniku sieciowym).
Narzucającym się rozwiązaniem przy wolnych łączach jest zastosowanie kompresji danych. Okazuje się, że w przypadku sieci Norand nie daje to spodziewanych efektów. Komputer HHC ma na tyle słaby procesor, że czas jaki zyskujemy na przesyłaniu mniejszej ilości danych jest niwelowany przez czas wymagany do kompresowania i dekompresowania danych w trakcie ich nadawania i odbioru. Wydaje się możliwe zastosowanie algorytmów kompresji danych przed transmisją i dekompresji po transmisji, ale nie daje się tego rozwiązania zastosować we wszystkich przypadkach (por. p. 5.2.3 i 8).
5.1.3 Długość pakietu danych
Okazało się, że optymalną i jedyną dopuszczalną długość pakietów z zakresu 258 - 263 daje się wyznaczyć jednoznacznie na 258 bajtów (por. p. 7.1). Zastosowanie innej długości powodowało powstawanie błędów transmisji.
5.1.4 Dostęp do łącza i współbieżność
W sieci Norand przewidziano możliwość podłączenia do sieci 72 komputerów HHC, ale tylko trzy z nich mogą jednocześnie komunikować się. Wynika stąd, że jest realna sytuacja, gdzie większość komputerów HHC będzie oczekiwać na rozpoczęcie sesji komunikacyjnej, a tylko co najwyżej trzy będą aktywne.
Do tego niestety trzeba dodać jeszcze jedno ograniczenie - brak możliwości kontroli nad kolejnością przyznawania prawa do rozpoczęcia sesji komunikacyjnej. Jest ona zupełnie losowa i nie bierze pod uwagę żadnych parametrów czasowych, takich jak kolejność zgłoszeń, czy czas spędzony na oczekiwaniu. Z tego względu pojawia się niebezpieczeństwo zagłodzenia niektórych komputerów HHC. By tego uniknąć trzeba było wprowadzić kilka dodatkowych założeń.
W pierwszej kolejności należało określić kiedy sesja komunikacyjna kończy się sukcesem i co będzie podczas niej przesyłane. Za jedną sesję komunikacyjną zostało przyjęte przesłanie wszystkich danych (plików) z komputera HHC na komputer PC i/lub z komputera PC na komputer HHC (por. p. 5.2.2). Zastosowanie metody przesyłania danych po jednym pliku prowadziło do zbyt wielu problemów. Należały do nich między innymi zbyt duże narzuty na przesyłanie danych w trakcie rozpoczynania sesji komunikacyjnej oraz zwiększenie możliwości zagłodzenia komputera HHC w wyniku zwiększenia liczby sesji potrzebnych do przesłania wszystkich danych z komputera HHC na komputer PC i z komputera PC na komputer HHC (ponad dziesięciokrotne zwiększenie liczby potrzebnych sesji komunikacyjnych - por. 7.2). Sukces sesji komunikacyjnej został określony jako bezbłędne przesłanie wszystkich plików.
Drugim założeniem było rozbicie pełnego cyklu przesyłania danych na dwie sesje komunikacyjne (por. p. 5.2.1)
5.1.5 Komunikacja asynchroniczna na łączu RS-232
Protokół komunikacyjny warstwy drugiej, pomiędzy sterownikiem sieciowym a komputerem PC, jest protokołem asynchronicznym. Pakiety są przesyłane naprzemiennie. Na każdy pakiet sterownika komputer PC odpowiada jednym pakietem. Sterownik sieciowy dysponuje trzema logicznymi kanałami komunikacyjnymi, którymi się łączy z trzema komputerami HHC w sieci LAN. W nagłówku pakietu będącego żądaniem danych sterownik umieszcza informacje o tym, którym z trzech kanałów zostanie przesłana odpowiedź. Dane przesłane z komputera PC do sterownika zostaną automatycznie przekierowane odpowiednim kanałem do komputera HHC, dla którego są przeznaczone. W związku z tym, pakiet od komputera PC nie musi zawierać danych dotyczących kanału komunikacyjnego, którym dany pakiet powinien być przesłany.
5.2 Rozwiązania programistyczne implikowane przez specyfikę sieci Norand i inne uwarunkowania
Sieci Norand są stosowane w firmach, których pracownicy muszą mieć dostęp do danych podczas wykonywania pracy w terenie - takich, jak dostawcy towaru do sklepów, inkasenci gazowi. Praca wykonywana przez pracowników tych firm wymaga spędzania większości czasu poza biurem i jednocześnie posiadania danych o towarach, które się ma ze sobą. Powinni oni również mieć możliwość składania zamówień do magazynów centralnych w celu uzupełnienia towaru, przesyłania danych o wystawionych fakturach do księgowości, przekazywania zamówień klientów do centralnych baz danych, czy też przesyłania informacji o nowych klientach. W tym celu odpowiednie fragmenty baz danych są przesyłane na poszczególne komputery HHC. Gdy pracownik wraca do firmy, podłącza swój komputer HHC do sieci LAN i następuje automatyczne uaktualnienie lokalnych oraz centralnych baz danych. Niestety, czas jaki pracownik może poświęcić na pozostawienie swojego komputera HHC podłączonego do sieci jest często ograniczony. W wielu firmach jedyną porą dostępną na synchronizację baz danych jest noc.
W typowym zastosowaniu, pracownik firmy cały dzień spędza w terenie. Wieczorem wraca do oddziału firmy, podłącza komputer HHC do sieci i wychodzi. Rano komputer HHC jest odłączany od sieci i pracownik udaje się do magazynu centralnego po odbiór towarów, które ma danego dnia dostarczyć klientom. Na komputerze HHC powinny być dane dotyczące klientów, których ma odwiedzić, informacje o towarze, którym będzie dysponował i przewidywane trasy. Czasami taki pracownik odwiedza oddział tylko raz w tygodniu.
Taki styl pracy narzucił kilka rozwiązań, koniecznych do zastosowania w projektowanym protokole.
5.2.1 Dwie sesje komunikacyjne
Poza standardowym (w sensie przetwarzania współbieżnego) zagrożeniem zagłodzenia komputera HHC przez brak możliwości nawiązania sesji komunikacyjnej, pojawia się też druga możliwość. By ją lepiej zrozumieć wprowadźmy nowe pojęcie: niech zagłodzenie brakiem towaru oznacza to, że nie dostanie się jakiegoś zasobu (towaru) w ogóle. Natomiast sytuacja taka, że nie dostanie się 100% zasobu (towaru), ale dostaje się więcej niż 0 oznacza, że nie nastąpiło zagłodzenie brakiem towaru.
Wyobraźmy sobie następujący scenariusz. W magazynie centralnym jest K sztuk towaru A. Do sieci mamy podłączonych H komputerów HHC. Pierwszy z nich zamawia X1 sztuk towaru K, drugi - X2, ..., N-ty (gdzie N Ł H – 1) zamawia Xn. Jeśli X1 + X2 + ... + Xn ł K, to komputer o numerze N+1 nie będzie mógł dostać ani jednej sztuki towaru A, nawet jeśli będzie go potrzebował, a tym samym zostanie zagłodzony (brakiem towaru) podczas danego dnia.
W celu uniknięcia zagłodzenia brakiem towarów, zostało zaproponowane rozwiązanie polegające na przeprowadzeniu dwóch sesji komunikacyjnych. W pierwszej, komputer HHC przesyłałby swoje dane do komputera PC. W drugiej, komputer PC przesyłałby dane do komputera HHC. Drugie sesje komunikacyjne mogłyby się rozpocząć dopiero po zakończeniu pierwszej sesji komunikacyjnej przez wszystkie komputery HHC podłączone do sieci. Po zebraniu danych od komputerów HHC, system centralny przetworzyłby zamówienia i dopiero wtedy następowałaby druga sesja komunikacyjna. Posiadanie danych od wszystkich komputerów HHC minimalizuje ryzyko wystąpienia zagłodzenia brakiem towarów, gdyż jesteśmy w stanie dostarczyć każdemu zamawiany towar, choć w mniejszej ilości (wyjątkiem jest sytuacja, gdy towaru jest mniej niż komputerów HHC i może wtedy wystąpić zagłodzenie brakiem towaru).
Pomiędzy pierwszą a drugą sesją, komputer HHC powinien przez pewien czas nie próbować inicjowania drugiej sesji (komputer HHC jest zawsze stroną inicjującą komunikację) - na przykład do określonej godziny. Czekanie pasywne jest tu wyraźnie preferowane.
Rozwiązanie to powoduje podwojenie liczby sesji komunikacyjnych, ale różni się od przypadku opisywanego w rozdziale 5.1.4. Analizowaliśmy tam sytuację, gdy każdy plik był wysyłany w oddzielnej sesji komunikacyjnej, co dawało ponad dziesięciokrotne zwiększenie liczby potrzebnych sesji. Teraz proponujemy jedynie podwojenie liczby sesji. Okazuje się, że zastosowanie podwójnej sesji komunikacyjnej może skrócić czas, przez jaki komputer HHC musi być podłączony do sieci. Dzieje się tak ze względu na wyeliminowanie czasu potrzebnego na przetworzenie danych na komputerze PC kiedy komputer HHC jest podłączony do sieci (por. p. 7.3).
Do tematu wrócimy w rozdziale 8.
5.2.2 Poprawność sesji komunikacyjnej
Dane będziemy uważać za poprawne tylko wtedy, gdy powiedzie się cała sesja komunikacyjna, tzn. wymiana danych z komputera HHC na komputer PC oraz odwrotnie. W przypadku wystąpienia błędu na którymkolwiek etapie sesji będziemy ją powtarzać od początku. Jest to wymaganie programistów piszących aplikacje wykorzystujące protokół warstwy trzeciej.
Poprawność logiczna zależy od tego, czy będzie wykorzystywany model komunikacji z jedną, czy z dwiema sesjami. Sprawdzanie jej pozostawia się programistom wyższej warstwy.
5.2.3 Czy kompresować dane?
Ponieważ czas, przez jaki komputer HHC jest podłączony do sieci LAN, powinien być jak najkrótszy, powstało pytanie czy można wykorzystać algorytmy kompresji i dekompresji. Rozważano ich zastosowanie w dwóch przypadkach. Pierwszym z nich było użycie tych algorytmów na etapie wysyłania i odbierania pakietów. Drugim było wykorzystanie ich przed rozpoczęciem sesji komunikacyjnej i po jej zakończeniu, a nie w trakcie.
Pierwszy z tych przypadków okazał się nieopłacalny. Na komputerze HHC jest zbyt słaby procesor by osiągnąć zysk z tych algorytmów. Decyzję o zastosowaniu drugiego pozostawiono programistom piszącym aplikacje, wykorzystujące opracowany protokół. Można go zastosować po zapoznaniu się ze specyfiką pracy klienta, dla którego dane rozwiązanie będzie przygotowane. Jeśli czynnikiem krytycznym jest czas od rozpoczęcia przetwarzania danych do jego zakończenia (czyli przygotowanie danych przez komputer HHC, sesja komunikacyjna i przetworzenie danych otrzymanych przez komputer HHC), to nie zaleca się stosowania algorytmów kompresji. Jeśli czynnikiem krytycznym jest czas przez jaki komputer HHC jest podłączony do sieci LAN (czas sekcji krytycznej ze względu na możliwość zagłodzenia brakiem dostępu do sieci), to wtedy warto rozważyć możliwość ich zastosowania (por. p. 7.4).
5.3 Optymalne rozwiązanie przy przyjętych ograniczeniach
Przejdźmy teraz do opisania optymalnego rozwiązania opartego na wcześniej wymienionych założeniach.
Długość ramki, która będzie wykorzystywana do przesyłania danych między komputerem PC a sterownikiem sieciowym musi mieć stałą długość. Jest to rozwiązanie mniej ekonomiczne niż wykorzystanie zmiennej długości ramki, zakończonej ustalonym znakiem, ale niezbędne przy przesyłaniu danych zawierających znaki ASCII inne niż litery. Została wybrana minimalna długość dostępna, czyli 258 bajtów, przy czym dwa pierwsze bajty są informacjami dla jawnego protokołu komunikacyjnego niższej warstwy pomiędzy komputerem PC a sterownikiem sieciowym, a 256 bajtów zostanie wykorzystane do zaimplementowania nowo tworzonego protokołu i przesyłania danych.
Ostatnie dwa bajty pakietu 256 bajtowego zostaną wykorzystane do liczenia sumy kontrolnej pakietu algorytmem CRC. W celu maksymalnego wykorzystania 254 pozostałych bajtów danych przesyłanych między komputerem HHC a komputerem PC, pakiety nie będą miały stałej struktury. Pakiety inicjujące komunikację i informacyjne będą miały określoną składnię, natomiast dane będą przesyłane pełnymi 254 bajtowymi blokami. W tym celu pakiety inicjujące komunikację będą musiały zawierać informacje o tym, ile danych ma być przesłanych i będzie to weryfikowane przy odbiorze. W przypadku, gdy jest mniej niż 254 bajty danych do przesłania, pakiet będzie dopełniany do 254. W celu oszczędzania pasma, w pakietach inicjujących przesłanie pliku będzie się znajdował nagłówek inicjujący z danymi o pliku oraz dane (z pliku), dopełniające pakiet do 254 bajtów.
Dane przesyłane nie będą poddawane kompresji na etapie budowy pakietów, gdyż wydłuża to sesję komunikacyjną.
Sesję komunikacyjną będziemy uważać za udaną wtedy i tylko wtedy, gdy pomyślnie zostaną przesłane dane zarówno z komputera HHC do komputera PC jak i z komputera PC do komputera HHC. Jakikolwiek błąd w trakcie sesji będzie powodował powtórzenie całej sesji od początku. Podczas transmisji z HHC do PC nie mamy możliwości przekazania komputerowi HHC informacji o wystąpieniu błędu przy odbiorze danych. Możemy natomiast rozpoznać następujące sytuacje awaryjne i przerwać prawie natychmiast sesję komunikacyjną w przypadku ich wystąpienia:
1. Błąd podczas próby wysłania danych z komputera HHC do komputera PC.
2. Błąd w odczycie danych do wysłania na komputerze HHC.
3. Błąd w CRC po odebraniu pakietu danych na komputerze HHC.
4. Błąd odczytu danych do przesłania na komputerze PC.
5. Błąd zapisu danych na komputerze HHC.
6. Błąd w odbiorze pakietu na komputerze HHC.
7. Błąd w formacie odebranego pakietu na komputerze HHC.
8. Błąd podczas próby wysłania pakietu z komputera PC.
W przypadku wykrycia błędu na komputerze PC w trakcie gdy stroną nadającą jest komputer HHC, musimy poczekać z przekazaniem informacji o błędzie do komputera HHC aż protokół warstwy drugiej nam na to pozwoli, czyli do zakończeniu nadawania danych z komputera HHC. Sytuacje, które będą podlegać temu scenariuszowi, to:
1. Błąd w CRC po odebraniu pakietu przez komputer PC.
2. Błąd w formacie pakietu odebranego od komputera HHC.
3. Błąd zapisu danych na komputerze PC.
Ponieważ jedynym typem danych, jakie będą przesyłane pomiędzy HHC a PC (poza samym zainicjowaniem komunikacji) są pliki, protokół został przystosowany do wyłącznej obsługi tego typu danych.
7 Testy
Wszystkie testy, których wyniki są przytaczane w tym rozdziale, zostały przeprowadzone na sieci składającej się z sześciu komputerów HHC, z wykorzystaniem jednej wieloportowej stacji dokującej, bądź na jednym komputerze HHC podłączonym bezpośrednio do komputera PC poprzez złącze RS-232. W obu przypadkach transmisja z i do komputera PC odbywała się z prędkością 19,2 Kbps. Wszystkie testy przeprowadzano na trzech różnych bazach danych (jednej fikcyjnej i dwóch uzyskanych od klientów) i trzech różnych wersjach aplikacji na komputerze HHC. Podczas jednej pełnej wymiany danych pomiędzy komputerem HHC a komputerem PC przesyłano około 900 KB danych w dziesięciu plikach. Każdy z testów był powtarzany co najmniej 20 razy.
Wszystkie testy związane z wydajnością i zagładzaniem były ograniczane do 40 minut, by przeskalować środowisko 72 komputerów i 8 godzin na dostępne 6 komputerów.
7.1 Wyznaczenie optymalnej długości pakietu danych
Testy w celu wyznaczenia optymalnej długości pakietu danych miały w pierwszej kolejności określić, czy istnieją różnice w wydajności protokołu jawnego (pomiędzy komputerem PC a sterownikiem sieciowym) w przypadku stosowania różnej długości pakietów z zakresu 258 - 263 bajtów. Intuicyjnie wydawało się, że zastosowanie dłuższych pakietów powinno zwiększyć wydajność. Wyniki okazały się inne.
Najlepsze rezultaty wydajnościowe w porównaniu z zastosowaniem pakietów o większej długości dały pakiety o długości 258. Wynikało to między innymi z tego, iż tylko ta długość dawała transmisję bezbłędną. Zwiększenie długości powodowało pojawienie się błędów w transmisji na poziomie 0,4% pakietów. Błędy te pojawiały się tylko wtedy, gdy przesyłane dane zawierały znaki ASCII spoza zakresu alfabetu. Po przeanalizowaniu informacji dostarczonych na temat protokołu niejawnego, jawnego oraz pakietów przesyłanych w sieci (analizatorem pakietów) okazało się, że przekłamania powstają na poziomie sterownika sieciowego i są związane z interpretowaniem jednego ze znaków ASCII w 259 bajcie jako komendy sterującej (dokładnie był to znak wyznaczony jako koniec pakietu w przypadku korzystania ze zmiennej długości - standardowo CR, aczkolwiek mógł być zmieniony na inny). Było to niezgodne z dokumentacją dostarczoną przez producenta, ale okazało się, że jest nie do obejścia.
Ponieważ dane mogą zawierać dowolny znak ASCII, nie było możliwości zagwarantowania poprawnej transmisji, a poziom błędów był zbyt wysoki, by można go było zaakceptować.
7.2 Zagłodzenie brakiem dostępu do sieci
Testy te służyły do sprawdzenia czy liczba sesji komunikacyjnych ma wpływ na możliwość wystąpienia sytuacji zagłodzenia komputera HHC brakiem dostępu do sieci. Podczas testów nie brano pod uwagę przetwarzania danych dostarczonych z komputera HHC na komputer PC - dane były wcześniej przygotowane. Wynikiem testów był czas potrzebny by wszystkie komputery HHC zakończyły sesję komunikacyjną. Wyliczany był również średni czas sesji dla jednego komputera HHC.
Testowano następujące scenariusze i uzyskano takie oto wyniki:
· Jedna sesja komunikacyjna - około 24 minut (4 min. na jeden HHC)
· Dwie sesje komunikacyjne - około 26 minut (4 min. 20 sek. na HHC)
· Pięć sesji komunikacyjnych - około 33 minut (5 min. 30 sek. na HHC)
· Dziesięć sesji komunikacyjnych - około 49 minut (8 min. 10 sek. na HHC)
W ostatnim przypadku nastąpiło zagłodzenie brakiem dostępu do sieci.
7.3 Dwie sesje komunikacyjne
Po postawieniu postulatu, że dwie sesje komunikacyjne mogą być lepsze niż jedna, ze względu na możliwość ograniczenia efektu zagłodzenia brakiem towaru, przeprowadzono 40 testów mających na celu empiryczne sprawdzenie tej teorii. Podczas testów badano czy nawiązanie dwóch sesji komunikacyjnych z jednoczesnym wyeliminowaniem aktywnego czekania może skrócić czas, przez jaki komputer HHC będzie podłączony do sieci.
W trakcie testów porównywano czas przez jaki komputer HHC jest podłączony do sieci, w zależności od tego czy wszystkie dane są przesyłane podczas jednej sesji komunikacyjnej, czy dwóch.
Ponieważ znane już były wyniki testów z danymi wcześniej przygotowanymi (por. p. 7.2), wiadomo było, że przy takim scenariuszu dwie sesje komunikacyjne powodują wydłużenie czasu dostępu do sieci o około 8%. Interesowało nas tylko stwierdzenie czy dwie sesji komunikacyjne wydłużą czas przez jaki komputer HHC jest podłączony do sieci, jeśli na czas przetwarzania danych otrzymanych od komputera HHC przez komputer PC i przygotowanie danych do wysłania dla komputera HHC, sesja komunikacyjna zostanie przerwana. Okazało się, że w przypadku gdy komputer HHC czekał podłączony do sieci na przetworzenie danych, całkowity czas wykorzystania sieci był o około 41% dłuższy niż w przypadku użycia dwóch sesji komunikacyjnych.
Widać stąd wyraźnie, że wybranie modelu pojedynczej lub podwójnej sesji komunikacyjnej powinno być uzależnione od specyfiki pracy klienta, który będzie korzystał z sieci Norand.
7.4 Algorytmy kompresji
Testy związane z algorytmami kompresji miały na celu sprawdzenie dwóch rzeczy. Pierwszą z nich była opłacalność stosowania kompresji danych na poziomie wysyłania i odbierania pakietów. Okazało się, że zastosowanie takiego rozwiązania średnio wydłużyło czas sesji komunikacyjnej o 0.7%.
Drugą sprawdzaną rzeczą był wpływ kompresowania danych przygotowywanych do wysłania i dekompresowania danych odebranych, na długość pełnej wymiany danych, a także na czas, przez jaki komputer HHC musi być podłączony do sieci. Testy wykazały, że całkowity czas (z sekcjami lokalnymi i sekcją krytyczną - od rozpoczęcia przygotowywania danych do przesłania przez komputer HHC, do przetworzenia danych otrzymanych zwrotnie od komputera PC) wydłużył się o 6%. Jednak długość sekcji krytycznej, czyli czas podłączenia komputera HHC do sieci LAN, została skrócona o 28%.
7.5 Pierwsza wersja opracowanego protokołu
Po zrealizowaniu pierwszej wersji
protokołu należało sprawdzić, czy została osiągnięta poprawa w wydajności
sieci LAN w porównaniu z dotychczasowymi rozwiązaniami. Przeprowadzono w tym celu dwa testy.
W pierwszym teście porównano wydajność opracowanego protokołu z rozwiązaniem firmy Norand. Średni czas jednej pełnej wymiany danych przy wykorzystaniu protokołu firmy Norand, wynosił 50 minut i 6 sekund dla sześciu komputerów HHC, co oznacza 8 minut i 21 sekund na jeden komputer. Wykorzystanie nowego protokołu skróciło średni czas pełnej wymiany danych do 30 minut, czyli do 5 minut na jeden komputer. Czas jaki komputer HHC musiał spędzić podłączony do sieci LAN został skrócony o około 67% przy zastosowaniu nowego protokołu.
W drugim teście porównano wydajność opracowanego protokołu z komunikacją bezpośrednią pomiędzy komputerem HHC a komputerem PC przy użyciu złącza RS-232. Czas pełnej wymiany danych z wykorzystaniem złącza RS-232 i protokołu komunikacyjnego opracowanego wcześniej w tym celu przez firmę Soft-tronik Service sp. z o.o., wynosił średnio 7 minut. Wykorzystanie wieloportowej stacji dokującej, sterownika sieciowego, sześciu komputerów HHC, oraz nowego protokołu, wymaga średnio 30 minut dla jednej pełnej wymiany danych przy sześciu aktywnych komputerach HHC. Oznacza to 5 minut na jeden komputer - czyli wzrost wydajności sieci o około 40%.
8 Podsumowanie
Niniejsza praca jest prezentacją doświadczeń z projektowania oraz implementowania protokołu komunikacyjnego dla specyficznej konfiguracji sprzętowej. Zostały w niej przedstawione przemyślenia, analizy i wyniki niektórych testów, jakie towarzyszyły temu procesowi.
Najważniejszym kryterium narzuconym przez zleceniodawcę był termin ukończenia projektu. Z tego względu nie było możliwe zaimplementowanie optymalnego rozwiązania, omówionego w rozdziale 4.3 - należy tylko mieć nadzieję, że w kolejnych implementacjach protokołu zostaną spełnienie wszystkie tam podane postulaty. Drugim kryterium było jak najprostsze zintegrowanie nowego rozwiązania z aplikacjami, które już były wykorzystywane w trybie komunikacji jeden komputer HHC - komputer PC. Trzecim kryterium było spełnienie oczekiwań klientów co do funkcjonalności rozwiązania i przygotowanie takiego, które będzie działać przy różnym trybie pracy.
Największą przeszkodą w projektowaniu nowego protokołu była niedostępność opisu protokołu NPCP i niewystarczający opis działania sterownika sieciowego. Niektóre parametry, jak na przykład wielkość pakietu, trzeba było ustalać doświadczalnie, często uciekając się do oglądania zawartości ramek protokołów drugiej warstwy poprzez analizatory sieciowe. Była to również jedna z podstawowych metod wykrywania błędów w dokumentacji dostarczonej przez producenta sprzętu.
8.1 Analiza zrealizowanego rozwiązania
Firma Norand, poza produkcją sprzętu wykorzystywanego w sieci Norand, dostarcza również aplikację na komputery HHC oraz aplikację centralną, uruchamianą na komputerze PC. Rozwiązanie przyjęte w obu aplikacjach działa na danych tekstowych, jest powolne, nie posiada interfejsu użytkownika w języku polskim, nie daje się modyfikować i jest bardzo drogie. Protokół, który powstał w wyniku tej pracy jest częścią większego projektu mającego na celu opracowanie rozwiązania konkurencyjnego do proponowanego przez firmę Norand.
Na pierwszym etapie powstały aplikacje na komputery HHC i aplikacje na komputer PC. Komunikacja odbywała się poprzez łącze bezpośrednie pomiędzy PC a HHC. Uzyskane rozwiązanie było szybsze niż oryginalne. Kolejnym krokiem było dodanie obsługi sieci LAN zbudowanej z użyciem sterownika sieciowego i wieloportowych stacji dokujących.
Podstawowe cele tej fazy projektu, to zbudowanie poprawnego rozwiązania, szybszego niż produkt oryginalny i łatwo wkomponowującego się w pracę, która już została zrobiona. Dopiero po osiągnięciu tego zadania, miało nastąpić dalsze optymalizowanie i dostrajanie protokołu komunikacyjnego. W wyniku tych założeń pierwsza wersja protokołu dla sieci Norand nie implementuje pewnych rozwiązań z tych, które były postulowane w rozdziale 5.3.
8.1.1 Zrealizowane rozwiązanie
W pierwszej wersji udało się osiągnąć podstawowe cele. Komunikacja w sieci jest niezawodna, obsługuje środowisko sieci LAN oraz łatwo integruje się z już istniejącymi aplikacjami. Zaprojektowany protokół okazał się znacznie wydajniejszy niż oryginalny (por. p. 7.5). Wpłynęło na to wiele czynników, przy czym jednym z ważniejszych było to, iż rozwiązanie firmy Norand było wstecznie zgodne z produktami już nie będącymi w sprzedaży, ale jeszcze występującymi na rynkach w Europie zachodniej.
Sterownik sieciowy został wykorzystany w jedyny dostępny sposób, tzn. do przechowywania plików, które po skopiowaniu na komputer HHC służą do stworzenia środowiska systemu operacyjnego DOS oraz instalują podstawową wersję aplikacji. Kopiowanie odbywa się automatycznie, jeśli do sieci podłączy się komputer HHC, bez zainstalowanego systemu operacyjnego. Udało się maksymalnie dostosować protokół komunikacyjny do specyficznego zadania, jakim jest przesyłanie plików, dzięki czemu zmniejszyła się ilość danych nadmiarowych. System wykrycia błędów w przebiegu sesji reaguje najszybciej jak to jest możliwe w celu udostępnienia kanału logicznego innemu komputerowi HHC. Długość pakietu jest dobrana optymalnie pod względem wydajności i niezawodności sesji komunikacyjnej.
Niektóre aspekty działania opracowanego rozwiązania pozostawiono programistom aplikacji z wyższej warstwy. To oni muszą zdecydować, czy będą wykorzystywać model z tylko jedną sesja komunikacyjną, czy też z dwoma. Również oni muszą zadbać o to, by w tym drugim przypadku dopiero dwie sesje komunikacyjne poprawnie wykonane oznaczały pomyślną wymianę wszystkich danych. Także na poziomie aplikacji trzeba będzie przygotować dane do przesłania i obsłużyć dane odebrane.
8.1.2 Sugerowane rozszerzenia i modyfikacje
Jak już wcześniej wspomniano, w pierwszej implementacji nie udało się zrealizować wszystkich postulatów optymalnego rozwiązania. Z przyczyn czasowych zostały one przełożone do następnej wersji. Należy do nich brak sprawdzania poprawności pakietów przez sumy kontrolne algorytmem CRC i dopełnianie pakietów inicjujących etapy transmisji danymi z plików.
Zaimplementowanie pierwszego z tych rozwiązań spowoduje niewielkie spowolnienie transmisji danych ze względu na konieczność liczenia sum kontrolnych, jak również zmniejszenia o dwa bajty ilości danych przesyłanych w pakiecie. Spowoduje to zwiększenie liczby pakietów potrzebnych na jedną sesję komunikacyjną średnio o 0,8%. Zyskuje się za to pewność wykrycia błędów powstałych podczas transmisji danych. Może się zdarzyć, że będzie się oferowało zainteresowanym klientom obydwie wersje protokołu. W zależności od tego czy klient preferuje większą wydajność, czy większe bezpieczeństwo, będzie wybierał odpowiednią wersję protokołu.
Drugim postulatem, który nie został zrealizowany, jest dopełnianie pakietów poprzedzających przesłanie pliku faktyczną zawartością pliku. Jest to modyfikacja, którą będzie można dodać do następnej wersji protokołu. Daje ona oszczędność 232 bajtów na jednym pliku. W jednej sesji komunikacyjnej średnio przesyła się 10 plików, co daje 2,2 KB danych na jedną sesję. Jednocześnie przesyła się około 900 KB danych. Jak widać oszczędność jest rzędu 0,55%.
Jeśli zaimplementujemy jednocześnie obydwa rozwiązania, to przyrost danych przesyłanych przez sieć będzie na poziomie 0,25%, oraz odczujemy minimalne spowolnienie na skutek wykonywania algorytmu CRC. Wydaje się to być akceptowalne w większości zastosowań.
8.2 Obecna sytuacja na rynku komputerów przenośnych
Protokół będący przedmiotem tej pracy został opracowany parę lat temu. Pomimo bardzo szybkiego rozwoju technologii komunikacji i komputerów typu przenośnego (hand-held, palmtop itp.), rozwiązania bazujące na sprzęcie serii 4000 nadal są w sprzedaży[2]. Wynika to ze specyfiki sprzętu, który się w tej serii znajduje.
Najważniejszym atutem komputera HHC model 4500 jest jego wytrzymałość i niezawodność. Jest on tak skonstruowany, że wytrzymuje wielokrotne upadki z wysokości dwóch metrów na beton. Ponadto jest odporny na kurz oraz pył, odporny na deszcz i zachlapania oraz zanurzanie w wodzie, działa w dużym zakresie temperatur (od -20° do +60° C) i ma niewielki pobór mocy. W razie wyczerpania akumulatorów, może być zasilany przez pięć baterii typu AA („paluszki”). Ma również możliwość pracy z wieloma urządzeniami dodatkowymi, jak na przykład czytniki laserowe i podczerwone czy drukarki przenośne (z możliwością zasilania z akumulatora samochodowego). Jest to więc idealne urządzenie do pracy w terenie.
W ofercie producenta znajdują się również inne modele. Są one wyposażone w lepsze procesory, więcej pamięci, dotykowe kolorowe monitory, modemy radiowe i lepsze systemy operacyjne (np. Windows CE). Mają jedną zasadniczą wadę - są w porównaniu z modelem 4500 delikatniejsze. Również specyfika wykorzystania modelu 4500 powoduje, że wiele z dodatków dostępnych w nowszych modelach jest zupełnie nieprzydatna. Są one przygotowane do pracy w magazynach, gdzie jest przydatna obsługa lokalnej sieci radiowej, czy wbudowane skanery działające na podczerwień. Ponadto warunki eksploatacyjne w magazynie są o wiele łagodniejsze niż w przypadku sprzedaży bezpośredniej w terenie.
W Polsce jest wielu klientów wykorzystujących w dalszym ciągu sieci serii 4000. Niektórzy z nich mają po kilka komputerów HHC model 4500, inni po kilkaset. Niektórzy z nich dokonali zakupu w ciągu ostatniego roku, pomimo że cena wcale nie jest niska (parę tysięcy dolarów za jeden zestaw). Czemu nie zdecydowali się na nowszą technologie? Czemu nie skorzystali z sieci radiowych czy technologii WAP? Okazuje się, że miejsca w których sprzedawcy dokonują transakcji są często poza zasięgiem sieci radiowych czy telefonii komórkowych. Również ilość danych jakie musiałyby być przesłane, spowodowałaby zmniejszenie wydajności sprzedawcy ze względu na znacznie mniejsze prędkości komunikacji uzyskiwane w sieciach radiowych. I na koniec - inne rozwiązanie nie gwarantowałoby takiej niezawodności sprzętu.
8.3 Wnioski końcowe
Dzięki tej pracy, poza możliwością pogłębienia swojej wiedzy na temat protokołów komunikacyjnych i metod ich projektowania, autor zdobył bardzo cenne doświadczenie. Okazuje się, że w rzeczywistych warunkach pracy, pod wpływem stresu, terminów i nacisków, ciężko jest poświęcić na projektowanie i dokumentowanie oprogramowania tyle czasu, ile wydaje się konieczne. Szczególnie część związana z dokumentowaniem programów jest w polskich firmach traktowana jako coś co można ewentualnie zrobić, gdy już zupełnie nie ma nic innego do zrobienia.
Biorąc pod uwagę czas, jaki był dostępny i ogrom pracy, jaki był związany z rozszyfrowywaniem dokumentacji sieci Norand, wynajdywaniem w niej błędów i nieudokumentowanych elementów, pierwsza implementacja protokołu komunikacyjnego jest szybka i niezawodna.
Jednak gdyby dziś autor ponownie stanął przed podobnym zadaniem, to niektóre ówczesne decyzje projektowo-implementacyjne byłyby inne. Już w pierwszej wersji protokołu byłyby sprawdzane sumy kontrolne, mimo spowolnienia transmisji oraz wydłużenia czasu opracowania protokołu. Również jeszcze dwa bajty w każdym pakiecie byłyby przeznaczone na przesłanie skróconego identyfikatora terminala. W przypadku awarii sprzętowej sterownika sieciowego, dałoby to możliwość wcześniejszego jej wykrycia. Spowodowałoby to wprawdzie spadek wydajności o kolejne 0,8%, ale dałoby większą pewność, że dane trafiają do miejsca przeznaczenia.
Glosariusz
· APU - ang. Auxiliary Power Unit, dodatkowy moduł zasilający do stacji wieloportowych w sieci Norand 4000
· Baza - oddział firmy macierzystej, do której powraca pracownik po zakończeniu pracy w terenie
· HHC - ang. hand-held computer, komputer przenośny; tutaj komputer przenośny firmy Norand, model 4500
· IP - ang. Internet Protocol, protokół wykorzystywany przez TCP i UDP, ale nie zapewniający poprawności transmisji
· ISO OSI - ang. International Standard Organization Open System Interconnect Model; model definiujący sposób komunikacji pomiędzy systemami otwartymi, definiujący siedem warstw sieci
· LAN - ang. local area network, sieć lokalna; tutaj sieć lokalna zbudowana w oparciu o sprzęt firmy Norand serii 4000
· MTU - ang. maximum transmission unit, maksymalna dopuszczalna jednostka transmisji w sieci, czyli największą ramka jaką można przesłać
· NPCP - ang. Norand Portable Communications Protocol, protokół opracowany przez firmę Norand do komunikacji urządzeń w sieci LAN
· Pakiet - podstawowa jednostka danych, definiowana w warstwie sieci modelu ISO OSI
· PC - ang. personal computer, komputer osobisty kompatybilny z komputerem firmy IBM
· Ramka - format danych do przesłania przez sieć definiowany w warstwie łącza modelu ISO OSI
· Seria 4000 - urządzenia firmy Norand o następujących numerach: 4500, 4985, 4960, 4970
· Stacja dokująca - stacja, umożliwiająca podłączenie komputerów HHC firmy Norand, model 4500 do sieci LAN
· Teren - środowisko pracy użytkownika komputera HHC, np. dla sprzedawcy obwoźnego będą to sklepy będące jego klientami
· TCP - ang. Transmission Control Protocol, protokół kontroli transmisji umożliwiający zestawienie niezawodnego połączenie pomiędzy urządzeniami sieci
· UDP - ang. User Datagram Protocol, prosty protokół datagramów nie zapewniający poprawności transmisji danych
· Wieloportowa stacja dokująca - stacja umożliwiająca podłączenie do sześciu komputerów; patrz też stacja dokująca
Bibliografia
[Co97] Douglas E. Comer: Sieci komputerowe TCP/IP 1. Zasady, protokoły i architektura. Wydawnictwa Naukowo-Techniczne, Warszawa 1997.
[CoSt97] Douglas E. Comer, David L. Stevens: Sieci komputerowe TCP/IP 2. Projektowanie i realizacja protokołów. Wydawnictwa Naukowo-Techniczne, Warszawa 1997.
[CoSt97a] Douglas E. Comer, David L. Stevens: Sieci komputerowe TCP/IP 3. Programowanie w trybie klient-serwer. Wersja BSD. Wydawnictwa Naukowo-Techniczne, Warszawa 1997.
[EDRS87] XDR: External Data Representation Standard. RFC 1014, Sun
Microsystems, Inc. 1987.
[Na94] Matthew G. Naugle: Network Protocol Handbook. McGraw-Hill,
Inc. 1994.
[NCPG91] 4985 Network Controller Programmer’s Guide.
Norand Data Systems, October 1991.
[Sp93] Darren L. Spohn: Data Network Design. McGraw-Hill, Inc.
1993.
[St94] W. Richard Stevens: TCP/IP Ilustrated, Volume 1. Addison-Wesley Publishing Company. 1994.
[Po80] J. Postel: User Datagram Protocol. RFC
768, 1980.
[Po81] J. Postel: Transmission Control Protocol. RFC 793,
1981.
[NL96] The Trustees
of Indiana University. 1996.
Dostępne w sieci Internet pod adresem:
http://www.uwsg.indiana.edu/usail/network/nfs/network_layers.html