BRZĘCZYK
Blocks Extensible Exchange Protocol ( BEEP ) to platforma do tworzenia protokołów aplikacji sieciowych. BEEP obejmuje bloki konstrukcyjne, takie jak kadrowanie, przesyłanie potokowe , multipleksowanie, raportowanie i uwierzytelnianie dla protokołów peer-to-peer (P2P) zorientowanych na połączenia i komunikaty z obsługą asynchronicznej komunikacji w trybie pełnego dupleksu .
Składnia i semantyka wiadomości jest zdefiniowana za pomocą profili BEEP powiązanych z jednym lub większą liczbą kanałów BEEP, gdzie każdy kanał jest potokiem pełnego dupleksu . Mechanizm ramkowania umożliwia jednoczesną i niezależną komunikację między rówieśnikami.
Sygnał BEEP jest zdefiniowany w dokumencie RFC 3080 niezależnie od leżącego u jego podstaw mechanizmu transportowego. Odwzorowanie BEEP na konkretną usługę transportową jest określone w osobnej serii dokumentów.
Przegląd
Profile, kanały i mechanizm ramkowania są wykorzystywane w BEEP do wymiany różnego rodzaju komunikatów. Specyfikacja domyślnie określa tylko typ zawartości i kodowanie, pozostawiając projektantowi protokołów pełną elastyczność korzystania z formatu binarnego lub tekstowego. Profile definiują funkcjonalność protokołu oraz składnię i semantykę komunikatów. Kanały to potoki w trybie pełnego dupleksu połączone z określonym profilem. Wiadomości przesyłane różnymi kanałami są od siebie niezależne (asynchroniczne). Wiele kanałów może korzystać z tego samego profilu za pośrednictwem jednego połączenia.
BEEP obejmuje również TLS do szyfrowania i SASL do uwierzytelniania .
Historia
W 1998 roku Marshall T. Rose , który również pracował nad protokołami POP3 , SMTP i SNMP , zaprojektował protokół BXXP, a następnie przekazał go grupie roboczej Internet Engineering Task Force ( IETF ) latem 2000 roku. W 2001 roku IETF opublikował BEEP ( RFC 3080 ) i BEEP na TCP ( RFC 3081 ) z pewnymi ulepszeniami BXXP. Trzy najbardziej godne uwagi to:
- Używanie application/octet-stream jako domyślnego „Content-Type”.
- Obsługa wielu odpowiedzi na wiadomości.
- Zmiana nazwy z BXXP na BEEP
Sesja BEEP
Aby rozpocząć sesję BEEP, inicjujący peer łączy się z peerem nasłuchującym. Obaj partnerzy natychmiast i jednocześnie wysyłają pozytywną odpowiedź zawierającą element powitania. Pozdrowienie zawiera maksymalnie trzy różne elementy:
- zawiera opcjonalne tokeny funkcji profilu zarządzania kanałami obsługiwane przez element równorzędny.
- lokalizować opcjonalne znaczniki preferowanego języka na potrzeby raportów i komunikatów.
- profili obsługiwane przez peera.
Przykładowe powitanie i odpowiedź:
L: I: L: RPY 0 0 . 0 110 L: Content-Type: application/beep+xml L: L: L: L: L: KONIEC I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: I: Ja: KONIEC
Profile
Profile definiują składnię i semantykę komunikatów oraz funkcjonalność protokołu w oparciu o sygnał BEEP. Pojedyncza sesja BEEP może zapewnić dostęp do wielu profili. W celu identyfikacji profilu przypisywany jest do niego unikalny ciąg znaków. Ten identyfikator profilu ma format Uniform Resource Identifier ( URI ) lub Uniform Resource Name ( URN ). W przeszłości URI identyfikatora profilu wprowadzał zamieszanie, ponieważ jest podobny do adresu internetowego. Aby uniknąć nieporozumień, nowsze profile powinny używać URN .
Przykładowy identyfikator profilu:
urn:ietf:params:xml:ns:geopriv:wstrzymany:beep
|
Wiązanie BEEP dla protokołu HELD |
http://iana.org/beep/xmlrpc
|
RFC 3529 XML-RPC w sygnale dźwiękowym |
Wiadomości i ramki
Komunikaty BEEP mają strukturę zgodną ze standardem MIME . Czasami zdarzają się nieporozumienia co do używania XML w komunikatach BEEP, ale tylko mały podzbiór XML jest używany przez kanał 0 i jest przejrzysty dla projektanta profilu (użytkownika BEEP). Od projektanta profilu zależy, jaki format treści wiadomości zostanie użyty. Może to być dowolny format tekstowy, taki jak JSON lub XML , a także dane binarne. XML jest używany do zarządzania kanałami i standardowego profilu TLS zdefiniowanego za pomocą BEEP.
Przykład pomyślnej wymiany komunikatów o zamknięciu kanału z dokumentu RFC3080.
C: MSG 0 2 . 235 71 C: Content-Type: application/beep+xml C: C: C: KONIEC S: RPY 0 2 . 392 46 S: Content-Type: application/beep+xml S: S: WYSŁAĆ
Większe komunikaty są dzielone na wiele części i rozdzielane na kilka ramek sekwencji.
Typy wymiany
BEEP definiuje 5 typów komunikatów, aby umożliwić większość wymaganych wzorców protokołów aplikacji. Są to:
Wiadomość | MSG | Wiadomość od jednego peera do drugiego zawierająca treść. |
Odpowiedź | RPY | Pojedyncza odpowiedź na otrzymaną wiadomość zawierającą treść (wymiana jeden do jednego). |
Błąd | BŁĄDZIĆ | Pojedyncza odpowiedź na otrzymaną wiadomość zawierającą treść (wymiana jeden do jednego) z błędem semantycznym. |
Odpowiedź | Odp | Odpowiedź na otrzymaną wiadomość zawierającą treść. Może być od 0 do n odpowiedzi na wiadomość (wymiana jeden-do-wielu). |
nul | NUL | Terminal odpowiada na wiadomość bez treści, aby zasygnalizować peerowi działającemu obecnie jako klient koniec wymiany wiadomości z 0 lub więcej odpowiedziami. |
Niektóre z najczęstszych wzorców protokołów aplikacji są implementowane w następujący sposób:
- Żądanie-odpowiedź przy użyciu MSG dla żądania oraz RPY i ERR dla odpowiedzi
- Pojedyncze żądanie-wiele odpowiedzi przy użyciu MSG oraz seria odpowiedzi ANS zakończona ramką NUL
- Niepotwierdzone powiadomienie za pomocą MSG bez żadnej odpowiedzi
Kontrola przepływu
BEEP obsługuje ramki sekwencji (SEQ), aby zaimplementować kontrolę przepływu na poziomie kanału. Ramki sekwencji są zdefiniowane w RFC 3081 sekcja 3.3 . Protokół kontroli transmisji ( TCP ) definiuje mechanizm sekwencji na poziomie warstwy transportowej i obsługuje kontrolę przepływu związaną z połączeniem. Kontrola przepływu na poziomie kanału w BEEP jest potrzebna, aby żaden kanał lub duża wiadomość nie zmonopolizowała całego połączenia. W tym zakresie ramki sekwencji są wykorzystywane do wspierania jakości usług (QoS) oraz do unikania głodu i zakleszczenia.
Linki zewnętrzne
- BEEPcore.org Oficjalna strona internetowa
- RFC 3080 : Rdzeń protokołu Blocks Extensible Exchange
- RFC 3081 : Mapowanie rdzenia BEEP na TCP
- RFC 3117 : On the Design of Application Protocols , rozważania projektowe protokołu BXXP, jak opowiedzieli jego twórcy
- RFC 3195 : Niezawodne dostarczanie syslog — profil BEEP
- RFC 3529 : Profil XML-RPC dla BEEP
- RFC 4227 : Używanie SOAP w sygnale dźwiękowym
- RFC 3620 : Profil TUNEL
- iana.org/assignments/beep-parameters Rejestr profili BEEP ścieżki standardowej
- Wprowadzenie do BEEP w serwisie IBM.com