Appendix A. Examples (Esempi)
Appendix A. Examples (Esempi)
Questa sezione fornisce alcuni brevi esempi con flussi di messaggi per le richieste GET. Questi esempi dimostrano il funzionamento di base, il funzionamento in presenza di ritrasmissioni e il multicast.
La figura 16 mostra una richiesta GET di base che causa una risposta piggyback: Il client invia una richiesta GET Confirmable per la risorsa coap://server/temperature al server con un Message ID di 0x7d34. La richiesta include un'opzione Uri-Path (Delta 0 + 11 = 11, Length 11, Value "temperature"); il Token viene lasciato vuoto. Questa richiesta è lunga un totale di 16 byte. Una risposta 2.05 (Content) viene restituita nel messaggio Acknowledgement che conferma la richiesta Confirmable, ripetendo sia il Message ID 0x7d34 che il valore Token vuoto. La risposta include un Payload di "22.3 C" ed è lunga 11 byte.
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: Confirmable Request; Piggybacked Response
La figura 17 mostra un esempio simile, ma con l'inclusione di un Token non vuoto (valore 0x20) nella richiesta e nella risposta, aumentando le dimensioni rispettivamente a 17 e 12 byte.
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: Confirmable Request; Piggybacked Response
Nella figura 18, la richiesta GET Confirmable viene persa. Dopo ACK_TIMEOUT secondi, il client ritrasmette la richiesta, ottenendo una risposta piggyback come nell'esempio precedente.
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"
| |
Figure 18: Confirmable Request (Retransmitted); Piggybacked Response
Nella figura 19, il primo messaggio Acknowledgement dal server al client viene perso. Dopo ACK_TIMEOUT secondi, il client ritrasmette la richiesta.
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"
| |
Figure 19: Confirmable Request; Piggybacked Response (Retransmitted)
Nella figura 20, il server conferma la richiesta Confirmable e invia una risposta 2.05 (Content) separatamente in un messaggio Confirmable. Si noti che il messaggio Acknowledgement e la risposta Confirmable non arrivano necessariamente nello stesso ordine in cui sono stati inviati. Il client conferma la risposta Confirmable.
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)
| |
Figure 20: Confirmable Request; Separate Response
La figura 21 mostra un esempio in cui il client perde il suo stato (ad esempio, si blocca e viene riavviato) subito dopo l'invio di una richiesta Confirmable, quindi la risposta separata che arriva qualche tempo dopo è inaspettata. In questo caso, il client rifiuta la risposta Confirmable con un messaggio Reset. Si noti che l'ACK inaspettato viene ignorato silenziosamente.
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)
| |
Figure 21: Confirmable Request; Separate Response (Unexpected)
La figura 22 mostra una richiesta GET di base in cui la richiesta e la risposta sono Non-confirmable, quindi entrambe possono essere perse senza preavviso.
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"
| |
Figure 22: Non-confirmable Request; Non-confirmable Response
Nella figura 23, il client invia una richiesta GET Non-confirmable a un indirizzo multicast: tutti i nodi nell'ambito link-local. Ci sono 3 server sul link: A, B e C. I server A e B hanno una risorsa corrispondente, quindi inviano una risposta 2.05 (Content) Non-confirmable. La risposta inviata da B viene persa. C non ha una risposta corrispondente, quindi invia una risposta 4.04 (Not Found) Non-confirmable.
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
| | | |
Figure 23: Non-confirmable Request (Multicast); Non-confirmable Response