Appendix A. Examples (Anhang A. Beispiele)
Dieser Abschnitt gibt eine Reihe kurzer Beispiele mit Nachrichtenflüssen für GET-Anfragen. Diese Beispiele demonstrieren die grundlegende Operation, die Operation bei Vorhandensein von Neuübertragungen und Multicast.
Abbildung 16 zeigt eine grundlegende GET-Anfrage, die eine Huckepack-Antwort verursacht: Der Client sendet eine Confirmable GET-Anfrage für die Ressource coap://server/temperature an den Server mit einer Message-ID von 0x7d34. Die Anfrage enthält eine Uri-Path-Option (Delta 0 + 11 = 11, Length 11, Value "temperature"); das Token bleibt leer. Diese Anfrage ist insgesamt 16 Bytes lang. Eine 2.05 (Content)-Antwort wird in der Acknowledgement-Nachricht zurückgegeben, die die Confirmable-Anfrage bestätigt und sowohl die Message-ID 0x7d34 als auch den leeren Token-Wert zurücksendet. Die Antwort enthält eine Payload von "22.3 C" und ist 11 Bytes lang.
Client Server | | | | +----->| Header: GET (T=CON, Code=0.01, MID=0x7d34) | GET | Uri-Path: "temperature" | | | | |<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d34) | 2.05 | Payload: "22.3 C" | |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | 0 | GET=1 | MID=0x7d34 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 11 | "temperature" (11 B) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 0 | 2.05=69 | MID=0x7d34 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| "22.3 C" (6 B) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 16: Confirmable-Anfrage; Huckepack-Antwort
Abbildung 17 zeigt ein ähnliches Beispiel, aber mit der Einbeziehung eines nicht-leeren Tokens (Wert 0x20) in der Anfrage und der Antwort, wodurch die Größen auf 17 bzw. 12 Bytes erhöht werden.
Client Server | | | | +----->| Header: GET (T=CON, Code=0.01, MID=0x7d35) | GET | Token: 0x20 | | Uri-Path: "temperature" | | | | |<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d35) | 2.05 | Token: 0x20 | | Payload: "22.3 C" | |
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 0 | 1 | GET=1 | MID=0x7d35 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 11 | 11 | "temperature" (11 B) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | 2 | 1 | 2.05=69 | MID=0x7d35 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0x20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 1 1 1 1 1 1| "22.3 C" (6 B) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Abbildung 17: Confirmable-Anfrage; Huckepack-Antwort
In Abbildung 18 geht die Confirmable GET-Anfrage verloren. Nach ACK_TIMEOUT Sekunden überträgt der Client die Anfrage erneut, was zu einer Huckepack-Antwort wie im vorherigen Beispiel führt.
Client Server | | | | +----X | Header: GET (T=CON, Code=0.01, MID=0x7d36) | GET | Token: 0x31 | | Uri-Path: "temperature" TIMEOUT | | | +----->| Header: GET (T=CON, Code=0.01, MID=0x7d36) | GET | Token: 0x31 | | Uri-Path: "temperature" | | | | |<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d36) | 2.05 | Token: 0x31 | | Payload: "22.3 C" | |
Abbildung 18: Confirmable-Anfrage (Neuübertragen); Huckepack-Antwort
In Abbildung 19 geht die erste Acknowledgement-Nachricht vom Server zum Client verloren. Nach ACK_TIMEOUT Sekunden überträgt der Client die Anfrage erneut.
Client Server | | | | +----->| Header: GET (T=CON, Code=0.01, MID=0x7d37) | GET | Token: 0x42 | | Uri-Path: "temperature" | | | | | X----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d37) | 2.05 | Token: 0x42 | | Payload: "22.3 C" TIMEOUT | | | +----->| Header: GET (T=CON, Code=0.01, MID=0x7d37) | GET | Token: 0x42 | | Uri-Path: "temperature" | | | | |<-----+ Header: 2.05 Content (T=ACK, Code=2.05, MID=0x7d37) | 2.05 | Token: 0x42 | | Payload: "22.3 C" | |
Abbildung 19: Confirmable-Anfrage; Huckepack-Antwort (Neuübertragen)
In Abbildung 20 bestätigt der Server die Confirmable-Anfrage und sendet eine 2.05 (Content)-Antwort separat in einer Confirmable-Nachricht. Beachten Sie, dass die Acknowledgement-Nachricht und die Confirmable-Antwort nicht unbedingt in der gleichen Reihenfolge ankommen, in der sie gesendet wurden. Der Client bestätigt die Confirmable-Antwort.
Client Server | | | | +----->| Header: GET (T=CON, Code=0.01, MID=0x7d38) | GET | Token: 0x53 | | Uri-Path: "temperature" | | | | |<- - -+ Header: (T=ACK, Code=0.00, MID=0x7d38) | | | | |<-----+ Header: 2.05 Content (T=CON, Code=2.05, MID=0xad7b) | 2.05 | Token: 0x53 | | Payload: "22.3 C" | | | | +- - ->| Header: (T=ACK, Code=0.00, MID=0xad7b) | |
Abbildung 20: Confirmable-Anfrage; Separate Antwort
Abbildung 21 zeigt ein Beispiel, bei dem der Client seinen Zustand direkt nach dem Senden einer Confirmable-Anfrage verliert (z.B. abstürzt und neu gestartet wird), sodass die später eintreffende separate Antwort unerwartet kommt. In diesem Fall lehnt der Client die Confirmable-Antwort mit einer Reset-Nachricht ab. Beachten Sie, dass das unerwartete ACK stillschweigend ignoriert wird.
Client Server | | | | +----->| Header: GET (T=CON, Code=0.01, MID=0x7d39) | GET | Token: 0x64 | | Uri-Path: "temperature" CRASH | | | |<- - -+ Header: (T=ACK, Code=0.00, MID=0x7d39) | | | | |<-----+ Header: 2.05 Content (T=CON, Code=2.05, MID=0xad7c) | 2.05 | Token: 0x64 | | Payload: "22.3 C" | | | | +- - ->| Header: (T=RST, Code=0.00, MID=0xad7c) | |
Abbildung 21: Confirmable-Anfrage; Separate Antwort (Unerwartet)
Abbildung 22 zeigt eine grundlegende GET-Anfrage, bei der Anfrage und Antwort Non-confirmable sind, sodass beide ohne Benachrichtigung verloren gehen können.
Client Server | | | | +----->| Header: GET (T=NON, Code=0.01, MID=0x7d40) | GET | Token: 0x75 | | Uri-Path: "temperature" | | | | |<-----+ Header: 2.05 Content (T=NON, Code=2.05, MID=0xad7d) | 2.05 | Token: 0x75 | | Payload: "22.3 C" | |
Abbildung 22: Non-confirmable-Anfrage; Non-confirmable-Antwort
In Abbildung 23 sendet der Client eine Non-confirmable GET-Anfrage an eine Multicast-Adresse: alle Knoten im Link-Local-Bereich. Auf dem Link befinden sich 3 Server: A, B und C. Server A und B haben eine passende Ressource, daher senden sie eine Non-confirmable 2.05 (Content)-Antwort zurück. Die von B gesendete Antwort geht verloren. C hat keine passende Antwort, daher sendet er eine Non-confirmable 4.04 (Not Found)-Antwort.
Client ff02::1 A B C | | | | | | | | | | +------>| | | | Header: GET (T=NON, Code=0.01, MID=0x7d41) | GET | | | | Token: 0x86 | | | | Uri-Path: "temperature" | | | | | | | | |<------------+ | | Header: 2.05 (T=NON, Code=2.05, MID=0x60b1) | 2.05 | | | Token: 0x86 | | | | Payload: "22.3 C" | | | | | | | | | X------------+ | Header: 2.05 (T=NON, Code=2.05, MID=0x01a0) | 2.05 | | | Token: 0x86 | | | | Payload: "20.9 C" | | | | | | | | |<------------------+ Header: 4.04 (T=NON, Code=4.04, MID=0x952a) | 4.04 | | | Token: 0x86 | | | |
Abbildung 23: Non-confirmable-Anfrage (Multicast); Non-confirmable-Antwort