multipart messages

DRAFT Multipart messages

First of all, the rcid idea is wrong. Caller cannot distinguish responses to own calls from tunnel/multipart messages responses. There is request ID clash possibility.

Long response result

1. Client calls method foo/bar:baz with some request ID, let say 123
2. Device can answer more responses with increasing SeqNo attribute starting at 0 and Part attribute set to true.
3. Last part has Part attribute set to 0, note that single part message can have Part attribute omitted because default value is false.

Result concatenation:

1. List, String, Blob types are appended are appended to previous
2. Map, IMap types are merged, more recent keys override the old ones.

Bi-directional tunnel

1. There is **/tunnel:create method returning tunid as String
2. Upon successful tunnel creation, the **/tunnel/tunid node exists
3. client can sen data to the tunnel calling **/tunnel/tunid:write
4. The tunnel data exchange is started by first **/tunnel/tunid:write call.
5. All responses to **/tunnel/tunid:write are send with request-id of first call, but with increasing SeqNo attribute value
6. Tunnel is closed when:
   1. **/tunnel/tunid:close is called
   2. RpcError message is sent by one of side
   3. There is no traffic for 1 minute
7. Tunnel creation and destruction is signalized by **/tunnel/tunid:ls:lsmod signal