BRZĘCZYK

Kanały BEEP mogą uzyskiwać dostęp do wielu profili w ramach jednej sesji.

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