Download - Verteilte Systeme (Uni Lübeck) - Kapitel 3 · PDF file• In den Daten: Byte Stuffing von DLE-Zeichen 38 DLE STX Daten DLE ETX . Byte Stuffing Beispiel • Daten vor Byte Stuffing

Verteilte Systeme

Kapitel 3: Nachrichtenrepräsentation

Prof. Dr. Stefan Fischer

Institut für Telematik, Universität zu Lübeck

https://www.itm.uni-luebeck.de/people/fischer

Übersicht

• Motivation / Problemstellung

• Repräsentation von Nachrichten – ASCII-basiert

– RFC 1014: External Data Representation (XDR)

– Abstract Syntax Notation One (ASN.1)

– Extensible Markup Language (XML)

– JavaScript Object Notation (JSON)

– Objektserialisierung

• Trennung von Nachrichten (Framing)

• Unterscheidung mehrerer Nachrichtentypen

2

Motivation

3

Stefan Fischer Stefan Fischer Mensa-Protokoll (MP)

Repräsentation von Nachrichten

• Umwandlung Daten(-Strukturen) Payload von

Netzwerknachrichten

– Marshalling / Unmarshalling

– Serialisierung / Deserialisierung

– Encoding / Decoding

4

1:1 Kopie aus dem Arbeitsspeicher

5

1234234534563469

Größe der Datentypen

• Größe verschieden je nach • Programmiersprache

• Rechnerarchitektur

• Beispiel: unsigned int Datentyp in C

6

Jennic (32 Bit)

MSP430 (16 Bit)

PC (64 Bit)

Byte Order (Big-/Little-Endian)

• Repräsentation im Speicher je nach

Rechnerarchitektur

– Problematisch bei Multi-Byte-Werten (int, long int, ...)

– Floating Point unproblematisch IEEE 754

Darstellung

• Little Endian (least significant lowest address)

– x86, x86-64, MOS-6502 (Apple II, PET), DEC Alpha,

Altera Nios, Atmel AVR

• Big Endian (most significant lowest address)

– Java, SPARC, Motorola 6800, IBM System/360, IBM

System/370, ESA/390, and z/Architecture

7

Little

Endian

Big

Endian

Adresse

Alignment (Speicherausrichtung)

• Datentypen werden im Speicher „aligned“ abgelegt

– Starten an Adressen, sodass sie in einem Zyklus gelesen werden können

– Alignment abhängig von Architektur, Compiler und Sprache

8

sizeof(d.d1): 1 sizeof(d.d2): 2 sizeof(d.d3): 4 sizeof(d.d4): 1 Sum : 8 sizeof(d) : 12

sizeof(d.d1): 1 sizeof(d.d2): 2 sizeof(d.d3): 4 sizeof(d.d4): 1 Sum : 8 sizeof(d) : 12

Network Byte Order

• Festlegung der Byte Order für Nachrichten

– TCP/IP: Big Endian (höchstwertige Bits zuerst)

– Vor dem Senden müssen Daten ggf. konvertiert werden

• BSD Socket API

– C-Funktionen

– ip->len = htons(42);

9

Struktur von Netzwerknachrichten

• Häufig: Textuelle Definition (Dokument) – Alle Felder in network byte order oder IEEE 754

– Bytes 0 bis 1: Source port (unsigned int, 16 bit)

– Bytes 2 bis 3: Destination port (unsigned int, 16 bit)

– ...

• Alternative: Grafische Darstellung (z.B. in RFCs)

10

Repräsentation von Nachrichten

• Architektur- und programmiersprachenunabhängige Nachrichtenrepräsentation schwierig

• Vielzahl von Formaten, Standards, Frameworks, etc. – ASCII-basiert

– RFC 1014: External Data Representation (XDR)

– Abstract Syntax Notation One (ASN.1)

– Extensible Markup Language (XML)

– JavaScript Object Notation (JSON)

– Objektserialisierung

– Google Protocol Buffers

– Apache Thrift

– ...

11

External Data Representation (XDR)

• Ursprünglich definiert von Sun Microsystems

– Ziel: Rechnerunabhängige Darstellung von Daten

• Basis von

– Open Network Computing Remote Procedure Call (ONC RPC),

damals Sun RPC

– Network File System (NFS)

• Funktionen zum (De-)Serialisieren

– Primitive Typen (xdr_char, xdr_short, xdr_int)

– Arrays (xdr_array)

– Strings (xdr_string)

12


• Serialisierung strukturierter Daten

– Sequentieller Aufruf der Xdr-Funktionen für primitive

Datentypen

• Beispiel

13


• Vereinfachung durch Codegenerierung – Unix-Tool: rpcgen

– Definition der Datetypen in C-ähnlichem Format

– Generierung von C-Header und –Sourcedateien

• Generelles Prinzip

14


• Definition in „XDR-Sprache“ (C-ähnlich)

• Beispiel: daten.x

• Codegenerierung

– rpcgen -c -o xdrtest.c xdrtest.x

– rpcgen -h -o xdrtest.h xdrtest.x

15

xdrtest.h (Auszug)

16

xdrtest.c (Auszug)

17

Serialisierung

18

Deserialisierung

19

Abstract Syntax Notation One (ASN.1)

• Standardisiert durch ISO/IEC und ITU-T – CCITT X.409:1984, heute X.208

– Anwendungsbeispiel: X.509 Zertifikate

• Definition von Datenstrukturen in der „ASN.1 Notation“

• Verschiedene Serialisierungsformate – Basic Encoding Rules (BER)

– Canonical Encoding Rules (CER)

– Distinguished Encoding Rules (DER)

– XML Encoding Rules (XER)

– Packed Encoding Rules (PER)

– Generic String Encoding Rules (GSER)

20

ASN.1: Beispiel

• Beispiel in ASN.1 notation

• Codegenerierung in C – asn1c von http://sourceforge.net/projects/asn1c/

– asn1c -gen-PER asn1test.asn1

• Codegenerierung in Java – http://bnotes.sourceforge.net/

21

http://sourceforge.net/projects/asn1c/

ASN.1: Verschiedene Serialisierungen

• XER encoding (81 bytes) – <Data>

<d1>97</d1> <d2>100</d2> <d3>300</d3> <d4>90</d4> </Data>

• DER encoding (15 bytes) – Bytes (dec): 48 13 2 1 97 2 1 100 2 2 1 44 2 1 90

– Bytes (hex): 0x30 0xD 0x2 0x1 0x61 0x2 0x1 0x64 0x2 0x2 0x1 0x2C 0x2 0x1 0x5A

• PER encoding (7 bytes) – Bytes (dec): 97 0 100 2 1 44 90

– Bytes (hex): 0x61 0x0 0x64 0x2 0x1 0x2C 0x5A

22

Extensible Markup Language (XML)

• Auszeichnungssprache zur Darstellung

hierarchisch strukturierter Daten

– Standardisiert durch das W3C

– Maschinen- und menschenlesbare Textserialisierung

– Wohlgeformt: Korrekte Syntax

– Gültig: Folgt einer Grammatik (XML Schema, DTD,

Schematron, RELAX NG)

23


• XML Schema

Grammatik

• Gültiges Dokument

24


• Typisierte XML Dokumente ohne Schema

25


• Textuelle Repräsentation von XML nur eine Möglichkeit

• Alternativen – Fast Infoset (ITU-T Rec. X.891, ISO/IEC 24824-1, 2005)

• In ASN.1 formalisiertes Datenformat für XML Dokumente

• Keine Kenntnis des Schemas erforderlich zur (De-)Serialisierung

– Efficient XML Interchange (EXI, W3C standard) • Zwei Betriebsmodi: schemagebunden, schemalos

• Binäre Repräsentation von XML Dokumenten – Vorteile: Weniger Speicherbedarf, geringere Latenz

– Nachteile: Nicht menschenlesbar, keine weite Akzeptanz

26

JavaScript Object Notation (JSON)

• Ursprünglich zur Repräsentation von Objekten in

JavaScript verwendet

– Textbasiertes maschinen- und menschenlesbares

Datenaustauschformat

– Heute für viele Programmiersprachen verfügbar

– Vornehmlich für Web-basierte Anwendungen

– Standardisiert in RFC 4627

27

JSON-Datentypen

• Nullwert (null)

• Boolescher Wert (true, false)

• Zahlen (z.B. 100, +100, -100, 2e+6, ...)

• Strings (“Hallo, Welt“)

• Arrays ([ ])

• Objekte ({ })

28

JSON: Erweitertes Beispiel

29 Quelle: http://de.wikipedia.org/wiki/JavaScript_Object_Notation

Objektserialisierung

• In Programmiersprachen integrierte

plattformabhängige Serialisierung

• Beispiele

– Java Serializable

– .Net Remoting

• Funktionieren meist nur von VM zu VM da keine

Unterschiede in der Datenrepräsentation

30

Wahl des Serialisierungsformats

• Größe der serialisierten Daten („Payloadgröße“, Latenz)

• Maschinen- und Menschenlesbarkeit

• Validierbarkeit

• Rechenaufwand

• Komplexität der Toolchain

• Erweiterbarkeit (z.B. einzelne Felder hinzufügen)

• Versionierung

• Verbreitung (Standards, De-facto Standards)

• Programmiersprachenunabhängigkeit

• Verfügbarkeit für Programmiersprachen und Zielplattformen

• ...

31

Trennung von Nachrichten (Framing)

• Ausgangslage

– Sender schickt Nachrichten in Form eines Bytestroms

– Beispiele: TCP-Stream, serielle Schnittstelle, Dateien

– Empfänger liest Bytes aus Strom

• Problem: Streams kennen keine Nachrichtengrenzen

– Wann ist eine Nachricht vollständig empfangen?

– Wann beginnt die nächste Nachricht?

• Ziel: Zerlegung des Bytestroms in einzelne Nachrichten

• Framing: Verfahren zur Trennung

– Rahmen markiert Anfang (und Ende) einer Nachricht

– Framing ist bei Streams notwendig

32

33

Namenskonventionen

TCP UDP

Anwendungsschicht

Stream Stream Message Message

Transportschicht Segment Segment Packet Packet

Netzwerkschicht

(IP Layer) Datagram Datagram Datagram Datagram

Subnetzwerk Frame Frame Frame Frame

Message Message

Beispiel: Senderseite

• Sendet 3 Nachrichten – ABC, DEF und GHI

• Schreibt serialisierte Nachrichten auf Strom

• Betriebssystem sendet Pakete – vgl. Nagle‘s Algorithm und TCP_NODELAY

34

t

t

Nagle‘s Algorithm (nach John Nagle)

• Verhindert Versenden von zu kleinen TCP-Segmenten – Minimierung des Overheads (Header Payload)

• Algorithmus – TCP-Segment voll sofort versenden

– Sonst: Versenden wenn keine unbestätigten Pakete mehr unterwegs

• Lässt sich deaktivieren – Sinnvoll wenn geringe Latenz wichtig ist (z.B. bei SSH, Telnet, ...)

– Java: socket.setTcpNoDelay(true);

– Sockets in C • int flag = 1;

• setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, (char *) &flag, sizeof(int));

35

Beispiel: Empfängerseite

• Betriebssystem empfängt Pakete

• Betriebssystem puffert Daten

– Abhängig von Puffergröße (SO_RECVBUF)

– Schreibt diese in Strom der Applikation (wenn voll oder nach Ablauf eines Timers)

• Applikation liest immer Teile des Strom

• Applikation zerlegt Strom in Nachrichten

36

t

t

Framing-Verfahren

• Feste Länge

• Längenfeld

• Kombination feste Länge und Längenfeld

– TCP-Header und –Payload

• Trennzeichen

– Escaping

– Byte / Character Stuffing

37

Byte Stuffing (angelehnt an HDLC)

• Paketanfang

– DLE (0x10), Data Link Escape

– STX (0x02), Start of Text

• Paketende

– DLE (0x10), Data Link Escape

– ETX (0x03), End of Text

• In den Daten: Byte Stuffing von DLE-Zeichen

38

DLE STX DLE ETX Daten

Byte Stuffing Beispiel

• Daten vor Byte Stuffing

• Daten „gestuffed“

• Daten nach Byte Destuffing

39

DLE STX DLE ETX A B DLE H W

DLE STX DLE ETX A B DLE H W DLE

DLE STX DLE ETX A B DLE H W

Byte Stuffing: Implementierung

40

• Encoding

• Decoding: – https://github.com/itm/netty-handlerstack/blob/master/protocols/dlestxetx/src/main/

java/de/uniluebeck/itm/netty/handlerstack/dlestxetx/DleStxEtxFramingDecoder.java

https://github.com/itm/netty-handlerstack/blob/master/protocols/dlestxetx/src/main/ java/de/uniluebeck/itm/netty/handlerstack/dlestxetx/DleStxEtxFramingDecoder.java















https://github.com/itm/netty-handlerstack/blob/master/protocols/dlestxetx/src/main/

Wahl des Framingverfahrens

• Fehlerfreiheit des zugrundeliegenden Datenstroms

– Wichtig: Resynchronisation nach Fehlern

• Komplexität der Implementierung – Fehlerfreiheit des Codes

• Codegröße – z.B. bei ressourcenbeschränkten Geräten

• Overhead – Verdoppelung von Zeichen bei Byte Stuffing (unbekannte

Puffergröße)

41

Unterscheidung mehrerer Nachrichtentypen

• Ausgangslage – Multiplexing verschiedener Nachrichtentypen über eine (logische)

Verbindung

• Ziel – Empfänger muss Nachrichtentyp aus empfangenen Daten

erschließen können

• Typfeld vor dem oder als Teil des Payloads

• Beispiel

42

DLE STX DLE ETX Daten Typ


• Beispiel: Ethernet (Ethertype Feld)

43

http://en.wikipedia.org/wiki/Address_Resolution_Protocol


• Beispiel: IPv4-Header

– „Protocol“-Feld gibt „upper-layer“-Protokoll an

– Z.B. UDP=17, TCP=6

– Siehe http://www.iana.org/assignments/protocol-numbers

44

0 4 8 16

Version HdrLen Type of service

Identification

Time to live Protocol

19 31

Total length

Flags Fragment offset

Header checksum

Source address

Destination address

Options + padding

Data ( 65536 octets)


• Beispiel: IPv6-Header

– „Next Header“-Feld: Typ des nächsten Headers

– Z.B. UDP=17, TCP=6, Routing Extension Header=43

45

Zusammenfassung

• Protokolle benötigen Spezifikation der übertragenen Daten – Vielfalt an Möglichkeiten verfügbar

– Konkrete Wahl abhängig von Anwendungsanforderungen

– Ggf. Plattform- und Sprachunabhängigkeit wahren

• Bei stromorientierter Übertragung: Trennung mehrerer Nachrichten

• Unterscheidung von Nachrichtentypen – Muss auf Basis der Nachricht möglich sein

– Zum Beispiel über Typ-Feld als erstes Byte

46

Download - Verteilte Systeme (Uni Lübeck) - Kapitel 3 · PDF file• In den Daten: Byte Stuffing von DLE-Zeichen 38 DLE STX Daten DLE ETX . Byte Stuffing Beispiel • Daten vor Byte Stuffing

Top Related