Open nhattanmai opened 8 years ago
Hello. The library should take care of that for you. If you're trying to implement it yourself, https://github.com/uber/tchannel/blob/master/docs/protocol.md#fragmentation documents the fragmentation scheme for TChannel.
Thanks for your answer, I see fragmentation scheme but I still misunderstand how to receiving parser can collect frames exactly of a message when have many frames come from other messages. Can you explain more detail? I don't realize something like fragmentation id or whatever to confirm the second frame is belong to the first frame...
The frames are received in-order and have a message ID attached to them. Using the message ID and the in-order stream of frames, the library is able to reconstruct the original request/response. All frames that have a continuation frame have a continuation bit sit. When the last message in the stream is received, the bit is unset.
It may be silly question. This is schema of "call req": flags:1 ttl:4 tracing:25 service~1 nh:1 (hk~1 hv~1){nh} csumtype:1 (csum:4){0,1} arg1~2 arg2~2 arg3~2 Schema of "call req continue": flags:1 csumtype:1 (csum:4){0,1} {continuation} I think the first frame is header + "call req" --> have message ID in header. The second frame is only "call req continue", have no message ID. Where is message ID?
All frames have a message id, including call continues; neither the call req nor call req continue frame bodies contain a message id, it is on the frame header.
Oh. I see. Thank you very much!
When send large message that is bigger than 64KiB, the message is devide to some fragments. Please tell me how to receiving parse know fragments in the same message? Using header and fragment id?