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
External Data Representation (XDR)
• Serialisierung strukturierter Daten
– Sequentieller Aufruf der Xdr-Funktionen für primitive
Datentypen
• Beispiel
13
External Data Representation (XDR)
• Vereinfachung durch Codegenerierung – Unix-Tool: rpcgen
– Definition der Datetypen in C-ähnlichem Format
– Generierung von C-Header und –Sourcedateien
• Generelles Prinzip
14
External Data Representation (XDR)
• 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
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
Extensible Markup Language (XML)
• XML Schema
Grammatik
• Gültiges Dokument
24
Extensible Markup Language (XML)
• Typisierte XML Dokumente ohne Schema
25
Extensible Markup Language (XML)
• 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
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
Unterscheidung mehrerer Nachrichtentypen
• Beispiel: Ethernet (Ethertype Feld)
43
Unterscheidung mehrerer Nachrichtentypen
• 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)
Unterscheidung mehrerer Nachrichtentypen
• 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