System Rozproszone Komunikator Dokumentacja. Maciej Muszkowski Jakub Narloch



Podobne dokumenty
Przesyłania danych przez protokół TCP/IP

Klient-Serwer Komunikacja przy pomocy gniazd

SEGMENT TCP CZ. II. Suma kontrolna (ang. Checksum) liczona dla danych jak i nagłówka, weryfikowana po stronie odbiorczej

Specyfikacja HTTP API. Wersja 1.6

Uproszczony opis obsługi ruchu w węźle IP. Trasa routingu. Warunek:

SERWER AKTUALIZACJI UpServ

1. Proszę wejść na stronę: poczta.home.pl i zalogować się do nowej skrzynki za pomocą otrzymanych danych.

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Zadanie 1: rozproszona wiedza SKJ (2016)

Sieci komputerowe i bazy danych

Programowanie współbieżne i rozproszone

Skąd dostać adres? Metody uzyskiwania adresów IP. Statycznie RARP. Część sieciowa. Część hosta

Minimalna wspierana wersja systemu Android to zalecana 4.0. Ta dokumentacja została wykonana na telefonie HUAWEI ASCEND P7 z Android 4.

Dr Michał Tanaś(

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

Cele. Założenia. Format komunikatów

Enkapsulacja RARP DANE TYP PREAMBUŁA SFD ADRES DOCELOWY ADRES ŹRÓDŁOWY TYP SUMA KONTROLNA 2 B 2 B 1 B 1 B 2 B N B N B N B N B Typ: 0x0835 Ramka RARP T

Model OSI. mgr inż. Krzysztof Szałajko

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Protokół wymiany sentencji, wersja 1

Referencyjny model OSI. 3 listopada 2014 Mirosław Juszczak 37

Warstwy i funkcje modelu ISO/OSI

Protokoły zdalnego logowania Telnet i SSH

Aplikacja Sieciowa wątki po stronie klienta

KS-ZSA. Mechanizm centralnego zarządzania rolami

MODEL OSI A INTERNET

Komunikator wewnętrzny. funkcjonalność podstawowa bs4 intranet

Tytuł: Instrukcja obsługi Modułu Komunikacji internetowej MKi-sm TK / 3001 / 016 / 002. Wersja wykonania : wersja oprogramowania v.1.

Autorzy. Zespół SABUR Sp. Z o.o. Wydanie Data. Sierpień SABUR Sp. Z o. o. Wszelkie prawa zastrzeżone

TCP/IP formaty ramek, datagramów, pakietów...

Sieci komputerowe Warstwa transportowa

Akademia Techniczno-Humanistyczna w Bielsku-Białej

Dokumentacja smsapi wersja 1.4

Co nowego w systemie Kancelaris 4.11 STD/4.21 PLUS. Co nowego w systemie Kancelaris 4.12 STD/4.22 PLUS

Dodawanie kamer w rejestratorach z PoE

Lekcja 8, 9 i 10. Konspekt lekcji Poczta elektroniczna. Materiał z podręcznika: Rozdział 5. Poczta elektroniczna

DOKUMENTACJA TECHNICZNA SMS API MT

Stan globalny. Krzysztof Banaś Systemy rozproszone 1

Politechnika Łódzka. Instytut Systemów Inżynierii Elektrycznej

Dokumentacja interfejsu MySQL. Platforma BSMS.PL Instrukcja podłączenia po przez mysql

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Praca w sieci z serwerem

Wirtualna centralka telefoniczna P2P

Specyfikacja implementacyjna aplikacji serwerowej

Specyfikacja techniczna. mprofi Interfejs API

Tryby komunikacji między procesami w standardzie Message Passing Interface. Piotr Stasiak Krzysztof Materla

Procedura Walidacyjna Interfejs

RPC. Zdalne wywoływanie procedur (ang. Remote Procedure Calls )

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Sieci komputerowe - administracja

Manual konfiguracji konta dla fax2mail opcji BP Basic oraz BP Fiber

Instrukcja korzystania z usługi 2SMS. Wersja 2.0 [12 stycznia 2014] bramka@gsmservice.pl

Biuletyn techniczny. Eksport i import przelewów za pomocą usługi sieciowej

Instrukcja EQU Kantech

Protokół aukcji internetowych

3S TeleCloud - Aplikacje Instrukcja użytkowania usługi 3S FAX SYSTEM

Instrukcja integratora - obsługa dużych plików w epuap2

Remote Quotation Protocol - opis

Mechanizmy pracy równoległej. Jarosław Kuchta

Podstawy Transmisji Danych. Wykład IV. Protokół IPV4. Sieci WAN to połączenia pomiędzy sieciami LAN

Opracowanie protokołu komunikacyjnego na potrzeby wymiany informacji w organizacji

SERWER AKTUALIZACJI UpServ

Dokumentacja SMS przez FTP

Stworzenie programu KSIĄŻKA ADRESOWA posiadającego funkcjonalności przechowywania danych o osobach dodanych przez użytkownika.

Automater.pl zdalne tworzenie i zarządzanie transakcjami dokumentacja API wersja 0.1

Klient poczty elektronicznej - Thunderbird

Model sieci OSI, protokoły sieciowe, adresy IP

MODEM GSM-01. INSTRUKCJA OBŁUGI MODUŁU KOMUNIKACYJNEGO GSM-01 wersja 1.0 GSM-01 INSTRUKCJA OBSŁUGI - 1 -

Architektury systemów rozproszonych LABORATORIUM. Ćwiczenie 1

TRX API opis funkcji interfejsu

Połączenie VPN SSL Web Proxy. 1. Konfiguracja serwera VPN 1.1. Ustawienia ogólne 1.2. Profile SSL Web Proxy 1.3. Konto SSL 1.4. Grupa użytkowników

DR INŻ. ROBERT WÓJCIK DR INŻ. JERZY DOMŻAŁ

Nowe funkcje w wersji 2 hafciarki PR-650

Rysunek 1: Okno z lista

Protokoły sieciowe - TCP/IP

System obsługi ubezpieczeń FORT

Czas w systemach rozproszonych. Krzysztof Banaś Systemy rozproszone 1

Dokumentacja SQL API 1

Dokumentacja SMPP API

Skrócona instrukcja korzystania z Platformy Zdalnej Edukacji w Gliwickiej Wyższej Szkole Przedsiębiorczości

SERWER AKTUALIZACJI UpServ

Specyfikacja protokołu zdalnych kolejek RQP Krzysztof Choromański 19 kwietnia, 2008

Wiadomości. ZPKSoft Doradca. Wstęp.

Koordynacja procesów w środowisku rozproszonym

Instrukcja konfiguracji funkcji skanowania

Sieci Komputerowe Modele warstwowe sieci

INSTRUKCJA OBSŁUGI SUPLEMENT

Karol Gałka. Numer albumu: Inżynieria mechatroniczna

1. Rejestracja Partnera

Spis treści. 1 Moduł RFID (APA) 3

Specyfikacja raportowania dla partnerów

1 Moduł Diagnostyki Sieci

ZiMSK. VLAN, trunk, intervlan-routing 1

Sieci komputerowe - Protokoły warstwy transportowej

Aukcja trwa od momentu, gdy informacje o przedmiocie są dostępne dla klientów, a kończy się wraz z wysłaniem opisanego dalej komunikatu FINISH_MSG.

Zarządzanie bazą danych

Integracja Obieg Dokumentów - GiS Spis treści

Program do obsługi ubezpieczeń minifort

wersja dokumentu 1.0 data wydania

Funkcje dodatkowe. Wersja 1.2.1

Transkrypt:

System Rozproszone Komunikator Dokumentacja Maciej Muszkowski Jakub Narloch

Wymagania Zgodnie ze wstępnymi założeniami komunikator musi, realizowad następujące funkcje: 1. Jest oparty o model Peer2Peer, nie istnieje pojedynczy serwer centralny. Każdy z komunikatorów pełni funkcje zarówno serwera jak i klienta. 2. Przesyłanie publicznych wiadomości do wszystkich podłączonych komunikatorów. 3. Przesyłanie prywatnej wiadomości do wybranego adresata. 4. Komunikator wyświetla informację o tym, że ktoś w danej chwili pisze wiadomośd. 5. Przechowuje historię wiadomości wszystkich innych komunikatorów i pozwala ją w dowolnej chwili wyświetlid. 6. W przypadku rozłączenia się lub awarii po ponownym podłączeniu historia wiadomości jest synchronizowana. 7. Jeżeli nastąpi awaria, któregoś z węzłów i sied ulegnie podziałowi pozostałe komunikatory powinny byd w stanie na nowo nawiązad połączenie ze sobą. Protokół Protokół komunikacji został oparty o TCP, który zapewnia niezawodnośd. Format przesyłanych wiadomości został utworzony na bazie JSON. Poniżej wyspecyfikowane wszystkie rodzaje przesyłanych wiadomości wraz z opisem znaczenia ich pól oraz przykładami. Base: : pól: {"from_ipv4": "adres", "from_port": port} Komunikat base, stanowi bazowy typ wiadomości, wszystkie pozostałe wiadomości dziedziczą po nim jego pola. Pola from_ipv4 i port jednoznacznie identyfikują nadawcę w sieci. Komunikat Base nie jest przekazywany pomiędzy komunikatorami. Message: : {"from_ipv4": adres", "from_port": port, "time_info": wektor czasu, "msg_from_ipv4 : adres, "msg_from_port": port, "msg_to_ipv4": "adres", "msg_to_port": port, "message": "wiadomość" }

pól: Message, służy do przesyłania wiadomości pomiędzy użytkownikami. Każda z wiadomości zawiera aktualny czas wektorowy ze stanem wiedzy danego komunikatora o innych procesach. W momencie wysyłania wiadomości czas wektorowy w pozycji odpowiadającej nadawcy, jest zwiększany o 1. Wszystkie wiadomości, które zawierają adres msg_to_ipv4 ustawiony na 0.0.0.0, są traktowane, jako wiadomości publiczne i przesyłane do wszystkich komunikatorów. Wiadomości prywatne natomiast posiadają określonego odbiorcę wiadomości. Ponieważ wiadomości są rozsyłane po całej sieci, istniała potrzeba identyfikacji nadawcy wiadomości, dlatego dodano dwa pola msg_from_ipv4 oraz msf_from_port wskazujące na osobę, która wysłała wiadomośd. Pola from_ipv4 natomiast zawierają informację o tym, kto rozpowszechnia tą wiadomośd dalej. Wiadomośd message jest przesyłana w formacie UTF-8 w celu rozwiązania kwestii kodowania znaków diakrytycznych. time_info Zawiera czas wektorowy danego komunikatora i jego wiedzę o czasie logicznym innych komunikatorów. msg_from_ipv4 Adres IP nadawcy wiadomości. msg_from_port Port nadawcy wiadomości. msg_to_ipv4 Adres IP odbiorcy, zawiera 0.0.0.0, w przypadku wiadomości publicznych. msg_to_port Port odbiorcy, zawiera 0, w przypadku wiadomości publicznych. message Treśd wiadomości. Status: : pól: {"from_ipv4": "adress", "from_port": port, "status_ipv4": "adres", "status_port": port, "status": status"} Wiadomośd status, służy do przesyłania informacje o zmianie statusu użytkownika, czy jest on dostępny czy też się rozłączył. Pole status może zawierad dwie wartości: online lub offline. Status jest przesyłany przez każdy komunikator, który podłącza się do sieci (online). W momencie odłączania, się komunikator przesyła status offline. status_ipv4 Identyfikuję adres komunikatora, który przesyła informację o statusie. status_port Identyfikuję port komunikatora, który przesyła informację o statusie. status Status, może przyjmowad tylko dwie wartości online i offline.

MyIP: : pól: { "from_ipv4": adres", "from_port": port, "my_ipv4": "adres", "my_port": port} Wiadomośd MyIP, jest przesyłana jako pierwsza w momencie nawiązania nowego połączenia pomiędzy dwoma węzłami, służy ona do identyfikacji połączonych do siebie komunikatorów. my_ipv4 Zawiera adres IP nowo podłączonego węzła. my_port Zawiera port nowo podłączonego węzła. Backup: : pól: { "from_ipv4": "adress", "from_port": port, "backup_ipv4": "adress", "backup_port": port} Ze względu na przyjętą topologię sieci oraz mechanizm podłączania się do innych węzłów, w celu obsługi awarii innych konieczne było zdefiniowanie wiadomości, która będzie definiowała backup (węzeł zastępczy dla danego węzła). Backup jest przesyłany w momencie nawiązania nowego połączenia. Wiadomośd ta jest przesyłana wyłącznie przez serwer, do którego dany komunikator się podłączył. W przypadku, gdy węzeł który został wyznaczony za backup odłączy się ulegnie awarii istnieje koniecznośd wyznaczenia backup-a na nowo. backup_ipv4 Adres IP węzła będącego backup-em. backup_port Port węzła będącego backup-em.

Algorytmy i zastosowane rozwiązania Topologia sieci: W ramach tego projektu zastosowano topologię drzewa tzn. każdy z węzłów w danej chwili może się podłączyd wyłącznie do jednego węzła, sam natomiast, może przyjąd dowolną ilośd połączeo. Rozwiązanie to ma na celu wykluczenie cykli w tak zbudowanej sieci. Podłączenie się nowego węzła: W celu podłączenia się do innego węzła wymagana jest znajomośd adresu IP oraz portu nasłuchującego danego węzła. Identyfikatorem nowo przyłączonego węzła staje się jego własny IP oraz port nasłuchujący i pozwala on jednoznacznie identyfikowad użytkowników w sieci. Po podłączeniu do danego węzła następuję wymiana pomiędzy nimi komunikatów: 1. Wysyłamy do zdalnego węzła wiadomośd MyIP z naszym adresem i portem. 2. Odbieramy taką sama wiadomośd od podłączonego do nas węzła. 3. Przesyłamy aktualną historie wszystkich wiadomości, zarówno publicznych jak i prywatnych. 4. Przesyłamy mu listę statusów wszystkich komunikatorów w sieci. 5. Przesyłamy informację o backupie, zgodnie z przyjętymi zasadami. Odłączenie się węzła: W przypadku zakooczenia komunikatora w sposób standardowy lub awarii węzeł do którego był podłączony przesyła do wszystkich status offline z id użytkownika, który się odłączył. W wyniku odłączenia się jednego z węzłów, może dojśd do podziału sieci, dlatego wszystkie węzły, dla których odłączony węzeł pełnił rolę serwera podłączają się do węzła zdefiniowanego, jako backup (o ile jest to możliwe). Rozpowszechnianie komunikatów po sieci Komunikaty zdefiniowane wcześniej można podzielid na dwie kategorie: komunikatów broadcastowanych i point 2 point. Wiadomości broadcastowane są przesyłane do wszystkich innych użytkowników. Zalicza się do nich wiadomości message i status. Pozostałe wiadomości, czyli myip i backup są przesyłane wyłącznie do konkretnych węzłów i nie są przesyłane dalej.

Przesyłanie wiadomości Wiadomości dzielą się na dwa rodzaje: publiczne prywatne Wiadomości publiczne są adresowane do wszystkich użytkowników, i dany węzeł po ich odebraniu wyświetla je po czym przesyła je dalej. Wiadomości prywatne są adresowane wyłącznie do jednego użytkownika, wszystkie węzły, które napotka po drodze mają za zadanie jedynie je przekazad dalej. Czas wektorowy wiadomości Wiadomośd message jest przesyłana wraz z logicznym czasem wektorowym. Służy on do identyfikacji poszczególnych wiadomości i pozwala wykryd sytuacje, w której dana wiadomośd została otrzymana po raz drugi. Do obsługi czasu wektorowego definiuje się następujące operacje: W przypadku wysyłania, nadawca inkrementuje swój czas, nie zmieniając pozostałych, po czym wysyła wiadomośd. Przyjęto, że każdy proces inicjuje swój czas wartością 1. Pierwsza wysłana przez niego wiadomośd będzie, więc miała czas 2. W przypadku odebrania wiadomości łączymy wektor odebrany z wiadomości wraz z naszym, w przypadku elementów, które się nie powielają nie ulegają one zmianie i są dodawane do wynikowego wektora. W pozostałych wybierany jest maksymalny czas z obu wektorów: max(wektor_wiadomości, nasz_wektor). Gdy komunikator otrzymuje wiadomośd, pierwszą rzeczą, którą sprawdza to jej czas wektorowy nadawcy, wiadomośd jest przesyłana dalej tylko w wypadku, gdy czas wektorowy z wiadomości jest większy od tego zapisanego u odbiorcy. W przeciwnym wypadku wiadomośd nie jest przekazywana dalej. Synchronizacja wiadomości Nowo połączone węzły synchronizują historię wiadomości z innymi komunikatorami. Historię wiadomości otrzymuje się od węzła do którego się dany komunikator podłączył. Otrzymuje on historię wszystkich rozesłanych po sieci wiadomości uwzględniając w tym wiadomości prywatne i publiczne. Backup Każdy z sąsiadów ma przypisany swój węzeł Backup (o ile jest podłączony do przynajmniej 2 węzłów), jest to węzeł do którego należy się podłączyd w przypadku odejścia tego sąsiada.

Rys.1 Kolorowe strzałki to wskazują węzły, do których należy się połączyd w przypadku odejścia sąsiada o tym kolorze. Rys.2-4 Szary węzeł to sąsiad, który odszedł, kolorowe strzałki to nowe połączenia. Węzłem Backup jest w pierwszej kolejności nasz rodzic, jeśli nie mamy rodzica to jest to pierwsze z naszych dzieci (o ile mamy więcej niż 1 dziecko, w przeciwnym wypadku i tak nie mamy komu wysład tego węzła). Adres węzła backup jest aktualizowany i na nowo przesyłany przy: podłączeniu się kogoś do nas (wtedy my jesteśmy rodzicem tej osoby) odłączeniu się kogoś od nas podłączeniu się nas do kogoś (wtedy my jesteśmy dzieckiem tej osoby) Takie rozwiązanie posiada jedną wadę, powoduje, że sied rozpadnie się jeśli nie będziemy mieli możliwości połączenia do naszego węzła backup (czyli np padnie nasz rodzic oraz rodzic rodzica w tej samej chwili i w tym krótkim czasie nie zostanie wyznaczony nowy węzeł backup).