3. 例
このセクションでは、ブロック単位のGET、およびPUTまたはPOSTのメッセージフローを含むいくつかの短い例を示します。これらの例は、基本的な操作、再送信が存在する場合の操作、およびブロックサイズネゴシエーションの操作の例を示しています。
これらすべての例において、Blockオプションは、Blockオプションの種類（1または2）を示し、その後にコロンが続き、ブロック番号（NUM）、モアビット（M）、およびブロックサイズ指数（2**(SZX+4)）がスラッシュで区切られた分解された方法で示されます。たとえば、Block2オプション値33は2:2/0/32として示され、Block1オプション値59は1:3/1/128として示されます。
[RFC7252]と同様に、「MID」は「Message ID」（メッセージID）の略語として使用されます。
3.1. Block2の例
最初の例（図2）は、3つのブロックに分割されたGETリクエストを示しています。サーバーは128のブロックサイズを提案し、クライアントは同意します。最初の2つのACKにはそれぞれ128バイトのペイロードが含まれ、3番目のACKには1から128バイトのペイロードが含まれます。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:1/0/128 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/128 |
| |
| CON [MID=1236], GET, /status, 2:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.05 Content, 2:2/0/128 |
図 2: 単純なブロック単位のGET
2番目の例（図3）では、クライアントはブロック単位の転送を予期し（たとえば、リンク形式の記述[RFC6690]のサイズ表示のため）、ブロックサイズの提案を送信します。最後を除くすべてのACKメッセージは64バイトのペイロードを伝送し、最後のメッセージは1から64バイトを伝送します。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/64 |
| |
| CON [MID=1235], GET, /status, 2:1/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:1/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:4/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:4/1/64 |
| |
| CON [MID=1239], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1239], 2.05 Content, 2:5/0/64 |
図 3: 早期ネゴシエーションを伴うブロック単位のGET
3番目の例（図4）では、クライアントはブロック単位の転送が必要なことに驚き、サーバーによって一方的に選択されたサイズに不満を持っています。最初はサイズ提案を送信しなかったため、ネゴシエーションは2番目のメッセージ交換以降のサイズにのみ影響します。クライアントはすでに最初の128バイトの交換で最初の64バイトブロックと2番目の64バイトブロックの両方を取得しているため、3番目の64バイトブロック（「2/0/64」）のリクエストに進みます。サーバーはこれを理解する必要はなく（理解する必要もありません）、リクエストに最善を尽くして応答するだけです。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
| |
| CON [MID=1236], GET, /status, 2:3/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.05 Content, 2:3/1/64 |
| |
| CON [MID=1237], GET, /status, 2:4/0/64 ------> |
| |
| <------ ACK [MID=1237], 2.05 Content, 2:4/1/64 |
| |
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
図 4: 後期ネゴシエーションを伴うブロック単位のGET
これらすべての（および次の）ケースにおいて、再送信はCoAPメッセージ交換層によって処理されるため、ブロック操作には影響しません（図5および6）。
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GE///////////////////////// |
| |
| (timeout) |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
図 5: 後期ネゴシエーションと失われたCONを伴うブロック単位のGET
CLIENT SERVER
| |
| CON [MID=1234], GET, /status ------> |
| |
| <------ ACK [MID=1234], 2.05 Content, 2:0/1/128 |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| //////////////////////////////////tent, 2:2/1/64 |
| |
| (timeout) |
| |
| CON [MID=1235], GET, /status, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1235], 2.05 Content, 2:2/1/64 |
: :
: ... :
: :
| CON [MID=1238], GET, /status, 2:5/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.05 Content, 2:5/0/64 |
図 6: 後期ネゴシエーションと失われたACKを伴うブロック単位のGET
3.2. Block1の例
次の例はPUT交換を示しています。POST交換は同じように見えますが、原子性/べき等性に関する要件が異なります。GETと同様に、リクエストBlock1オプションにモアビットがあるリクエストへのレスポンスは暫定的であり、レスポンスコード2.31（Continue）を伝送することに注意してください。最終的なレスポンスのみが、PUTが成功したことをクライアントに伝えます。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
図 7: 単純なアトミックブロック単位のPUT
リソースをその場で（ステートレスに）単に構築/更新するステートレスサーバーは、レスポンスでモアビットを設定しないことでこれを示すことができます（図8）。この場合、レスポンスコードは更新される各ブロックに対して個別に有効です。もちろん、これは、メッセージ交換シーケンスの実行中に存在する潜在的な不整合が問題につながらない場合（たとえば、作成または変更されているリソースがまだ、または現在使用されていないため）にのみ、サーバーの許容可能な動作です。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.04 Changed, 1:0/0/128 |
| |
| CON [MID=1235], PUT, /options, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.04 Changed, 1:1/0/128 |
| |
| CON [MID=1236], PUT, /options, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128 |
図 8: 単純なステートレスブロック単位のPUT
最後に、ブロック単位のPUTまたはPOSTを受信するサーバーは、より小さなブロックサイズの優先順位を示したい場合があります（図9）。この場合、クライアントはより小さなブロックサイズで続行すべきです（SHOULD）。そうする場合、そのより小さなサイズで正しくカウントするようにブロック番号を調整しなければなりません（MUST）。
CLIENT SERVER
| |
| CON [MID=1234], PUT, /options, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/32 |
| |
| CON [MID=1235], PUT, /options, 1:4/1/32 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:4/1/32 |
| |
| CON [MID=1236], PUT, /options, 1:5/1/32 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:5/1/32 |
| |
| CON [MID=1237], PUT, /options, 1:6/0/32 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:6/0/32 |
図 9: ネゴシエーションを伴う単純なアトミックブロック単位のPUT
3.3. Block1とBlock2の組み合わせ
Blockオプションは、単一の交換の両方向で使用できます。次の例は、ブロック単位のPOSTリクエストを示しており、その結果、別のブロック単位のレスポンスが生成されます。
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 2:0/1/128, 1:2/0/128 |
| |
| CON [MID=1237], POST, /soap, 2:1/0/128 ------> |
| (no payload for requests with Block2 with NUM != 0) |
| (could also do late negotiation by requesting, |
| e.g., 2:2/0/64) |
| |
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/128 |
| |
| CON [MID=1238], POST, /soap, 2:2/0/128 ------> |
| |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/128 |
| |
| CON [MID=1239], POST, /soap, 2:3/0/128 ------> |
| |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/128 |
図 10: ブロック単位のレスポンスを伴うアトミックブロック単位のPOST
このモデルは、以下に示すように、Block2ブロック単位の転送への早期ネゴシエーション入力を提供します。
CLIENT SERVER
| |
| CON [MID=1234], POST, /soap, 1:0/1/128 ------> |
| |
| <------ ACK [MID=1234], 2.31 Continue, 1:0/1/128 |
| |
| CON [MID=1235], POST, /soap, 1:1/1/128 ------> |
| |
| <------ ACK [MID=1235], 2.31 Continue, 1:1/1/128 |
| |
| CON [MID=1236], POST, /soap, 1:2/0/128, 2:0/0/64 ------> |
| |
| <------ ACK [MID=1236], 2.04 Changed, 1:2/0/128, 2:0/1/64 |
| |
| CON [MID=1237], POST, /soap, 2:1/0/64 ------> |
| (no payload for requests with Block2 with NUM != 0) |
| |
| <------ ACK [MID=1237], 2.04 Changed, 2:1/1/64 |
| |
| CON [MID=1238], POST, /soap, 2:2/0/64 ------> |
| |
| <------ ACK [MID=1238], 2.04 Changed, 2:2/1/64 |
| |
| CON [MID=1239], POST, /soap, 2:3/0/64 ------> |
| |
| <------ ACK [MID=1239], 2.04 Changed, 2:3/0/64 |
図 11: ブロック単位のレスポンスを伴うアトミックブロック単位のPOST、
早期ネゴシエーション
3.4. ObserveとBlock2の組み合わせ
次の例では、サーバーは最初に、最初のGETリクエストへの直接レスポンス（Observeシーケンス番号62350）を送信します（結果のブロック単位の転送は図4と同じであるため、省略されています）。2番目の転送は、最初のブロックのみを含む2.05通知（Observeシーケンス番号62354）によって開始されます。その後、クライアントは残りのブロックの取得に進みます。
CLIENT SERVER
| |
+----->| Header: GET 0x41011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: (empty)
| |
|<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62350
| | ETag: 6f00f38e
| | Payload: [128 bytes]
| |
| | (Usual GET transfer left out)
...
| | (Notification of first block)
| |
|<-----+ Header: 2.05 0x4145af9c
| 2.05 | Token: 0xfb
| | Block2: 0/1/128
| | Observe: 62354
| | ETag: 6f00f392
| | Payload: [128 bytes]
| |
+- - ->| Header: 0x6000af9c
| |
| | (Retrieval of remaining blocks)
| |
+----->| Header: GET 0x41011637
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 1/0/128
| |
|<-----+ Header: 2.05 0x61451637
| 2.05 | Token: 0xfc
| | Block2: 1/1/128
| | ETag: 6f00f392
| | Payload: [128 bytes]
| |
+----->| Header: GET 0x41011638
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 2/0/128
| |
|<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc
| | Block2: 2/0/128
| | ETag: 6f00f392
| | Payload: [53 bytes]
図 12: ブロック単位のレスポンスを伴うObserveシーケンス
（この例でのトークン0xfcの選択は任意であることに注意してください。トークンはこの例で、追加ブロックのリクエストがObservation関係のトークンを利用できないことを示すためにのみ表示されています。トークンに関する一般的なコメントとして、ブロック単位の転送は他のCoAP交換と同様にトークンを処理するため、このドキュメントではトークンについて他に言及していません。通常どおり、クライアントは各交換のトークンを自由に選択できます。）
次の例では、クライアントは早期ネゴシエーションを使用して、ブロックサイズを64バイトに制限します。
CLIENT SERVER
| |
+----->| Header: GET 0x41011636
| GET | Token: 0xfb
| | Uri-Path: status-icon
| | Observe: (empty)
| | Block2: 0/0/64
| |
|<-----+ Header: 2.05 0x61451636
| 2.05 | Token: 0xfb
| | Block2: 0/1/64
| | Observe: 62350
| | ETag: 6f00f38e
| | Max-Age: 60
| | Payload: [64 bytes]
| |
| | (Usual GET transfer left out)
...
| | (Notification of first block)
| |
|<-----+ Header: 2.05 0x4145af9c
| 2.05 | Token: 0xfb
| | Block2: 0/1/64
| | Observe: 62354
| | ETag: 6f00f392
| | Payload: [64 bytes]
| |
+- - ->| Header: 0x6000af9c
| |
| | (Retrieval of remaining blocks)
| |
+----->| Header: GET 0x41011637
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 1/0/64
| |
|<-----+ Header: 2.05 0x61451637
| 2.05 | Token: 0xfc
| | Block2: 1/1/64
| | ETag: 6f00f392
| | Payload: [64 bytes]
....
| |
+----->| Header: GET 0x41011638
| GET | Token: 0xfc
| | Uri-Path: status-icon
| | Block2: 4/0/64
| |
|<-----+ Header: 2.05 0x61451638
| 2.05 | Token: 0xfc
| | Block2: 4/0/64
| | ETag: 6f00f392
| | Payload: [53 bytes]
図 13: 早期ネゴシエーションを伴うObserveシーケンス