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.

RpcMessage body IMap keys will be extended by following 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() rqId = RQID
2. File device will split file content to N chunks
3. N RpcResponses will be sent back to client
   • every response will have rqId == RQID
   • first N-1 responses will be sent with part==true in metadata and chunk == true + result == BLOB_DATA_n in response
   • N-th response will be sent with part == false in metadata and chunk == true + result == BLOB_DATA_n in response data

Send large file

1. client issue sendFile() with rqId == RQID + rcid == null + part == true key set in metadata.
2. device responses with some result and wait for more messages with rqId == RQID, client will take rcid list from response, we will call it RCID
3. Client will split file content to N chunks
4. N RpcResponses will be sent back to device
   • every response will have rqId == RQID + cid == RCID
   • first N-1 responses will be sent with part==true in metadata and chunk == true + result == BLOB_DATA_n in response
   • N-th response will be sent with part == false in metadata and chunk == true + result == BLOB_DATA_n in response data

Long lasting computation with progress

1. client issue heavyComputation() with rqId = RQID
2. N RpcResponses will be sent back to client
   • every response will have rqId == RQID
   • first N-1 responses will be sent with part==true in metadata and progress = PROGRESS_MAP + result == null in response
   • N-th response will be sent with part == false in metadata and result == 42 in response data

Bi-directional tunnel

1. client issue openTunnel() with rqId == RQID + rcid == null + part == true key set in metadata.
2. device will save first message cid as CID
3. Device responses with some result and wait for more messages with rqId == RQID, client will take rcid list from response, we will call it RCID
4. Client will send any data to its tunnel end as Rpcresponse with rqId == RQID + cid == RCID
5. Device will send any data to its tunnel end as Rpcresponse with rqId == RQID + cid == CID
6. Tunnel is closet if
   • Client or device send RpcResponse with part = false
   • Client or device send RpcResponse with error set