multipart messages

Multipart messages

New meta key part will be introduced in RpcResponse. RpcResponse without part key is considered to be the final one. This is aligned with single-part messages, which currently have not a part key.

RpcResult keys enum will be extended by next keys:

• chunk - optional, if chunk key is received, then result should be appended to result of previous chunks
  • String, Blob will be concatenated
  • List will be appended
  • Map will be merged
• progress - optional, IMap with following keys:
  • index - index of current part <0, count)
  • count - part count
  • message

Receiver of multipart message can cancel whole transfer, if it sent back Error RpcResponse, rcid must be part of RpcRequest to enable this.

Also sender can cancel whole transfer, if it will send RpcResponse with error set

What multipart messages can be good for:

• transfer big file in N chunks with progress
• keep client informed about progress of very long time lasting Rpc Call
• tunneling

Use cases

Receive large file

1. client issue getFile() with rqId == 1 for example.
2. File device will split file content to N chunks
3. N RpcResponses will be sent back to client
   • every response will have rqId == 1
   • first N-1 responses will be set with part==true in metadata and chunk == true + 'result == BLOB_DATA_n' in response
   • N-th response will be set without part in metadata or with part == false and chunk == true + 'result == BLOB_DATA_n' in response

Send large file

1. client issue getFile() with rqId == 1 for example.
2. File device will split file content to N chunks
3. N RpcResponses will be sent back to client
   • every response will have rqId == 1
   • first N-1 responses will be set with part==true in metadata and chunk == true + 'result == BLOB_DATA_n' in response
   • N-th response will be set without part in metadata or with part == false and chunk == true + 'result == BLOB_DATA_n' in response