Appendix A. Examples (付録A. 例)
このセクションでは、GETリクエストのメッセージフローを含むいくつかの短い例を示します。これらの例は、基本動作、再送信が存在する場合の動作、およびマルチキャストを実証します。
図16は、ピギーバック応答を引き起こす基本的なGETリクエストを示しています：クライアントは、メッセージID 0x7d34でリソースcoap://server/temperatureに対するConfirmable GETリクエストをサーバーに送信します。リクエストには1つのUri-Pathオプション(Delta 0 + 11 = 11、Length 11、Value "temperature")が含まれています。Tokenは空のままです。このリクエストは合計16バイトの長さです。2.05 (Content)応答が、Confirmableリクエストを確認するAcknowledgementメッセージで返され、メッセージID 0x7d34と空のToken値の両方をエコーバックします。応答には"22.3 C"のペイロードが含まれ、11バイトの長さです。
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) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
図16: Confirmableリクエスト；ピギーバック応答
図17は同様の例を示していますが、リクエストと応答に空でないToken(値0x20)が含まれており、サイズがそれぞれ17バイトと12バイトに増加しています。
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) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
図17: Confirmableリクエスト；ピギーバック応答
図18では、Confirmable GETリクエストが失われます。ACK_TIMEOUT秒後、クライアントはリクエストを再送信し、前の例のようにピギーバック応答が得られます。
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" | |
図18: Confirmableリクエスト(再送信)；ピギーバック応答
図19では、サーバーからクライアントへの最初のAcknowledgementメッセージが失われます。ACK_TIMEOUT秒後、クライアントはリクエストを再送信します。
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" | |
図19: Confirmableリクエスト；ピギーバック応答(再送信)
図20では、サーバーはConfirmableリクエストを確認し、2.05 (Content)応答を別のConfirmableメッセージで送信します。Acknowledggementメッセージとconfirmable応答は、必ずしも送信された順序で到着するとは限らないことに注意してください。クライアントは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) | |
図20: Confirmableリクエスト；分離応答
図21は、クライアントがConfirmableリクエストを送信した直後に状態を失う(例えば、クラッシュして再起動する)例を示しており、その後しばらくして到着する分離応答は予期しないものです。この場合、クライアントはResetメッセージでConfirmable応答を拒否します。予期しないACKは静かに無視されることに注意してください。
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) | |
図21: Confirmableリクエスト；分離応答(予期しない)
図22は、リクエストと応答がNon-confirmableである基本的なGETリクエストを示しており、両方とも通知なしに失われる可能性があります。
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" | |
図22: Non-confirmableリクエスト；Non-confirmable応答
図23では、クライアントはマルチキャストアドレスにNon-confirmable GETリクエストを送信します：リンクローカルスコープ内のすべてのノード。リンク上には3つのサーバーがあります：A、B、C。サーバーAとBには一致するリソースがあるため、Non-confirmable 2.05 (Content)応答を返します。Bが送信した応答は失われます。Cには一致する応答がないため、Non-confirmable 4.04 (Not Found)応答を送信します。
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 | | | |
図23: Non-confirmableリクエスト(マルチキャスト)；Non-confirmable応答