how to distinguish different Message Types in tcp byte stream
27 views
Skip to first unread message
Alex Syrnikov
unread,
Oct 25, 2022, 10:45:03 PM10/25/22
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Link
Report message as abuse
Sign in to report message as abuse
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Cap'n Proto
Hello.
I have (working on) Rust service and clients ( Rust and Node.js). I want service<->client cap'n'proto message exchange via Tcp socket (no HTTP). Messages will go via tcp connection, but I have different message types (each message is structs Login, or CommandGetData or Error...). So how can I distinguish which message Type I got from tcp bytes stream (and I need to know it's size too).
I decided to prefix each message with UInt32 type and size (8 bytes total). Probably JS can read raw bytes. Or I can prefix Messages with fixed size unpacked message (struct - 24 bytes).
struct MessageHeader {
type @0: UInt32;
size @1: UInt32;
}
So what is good solution for this task? I think it was already solved many times. I understand, that RPC will solve this as JSON messages. But I do not want use RPC right now.
Ian Denhardt
unread,
Oct 25, 2022, 11:18:15 PM10/25/22
Reply to author
Sign in to reply to author
Forward
Sign in to forward
Delete
You do not have permission to delete messages in this group
Link
Report message as abuse
Sign in to report message as abuse
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Alex Syrnikov, Cap'n Proto
For distinguishing the type, I would recommend wrapping your messages in
a common union type, e.g:
struct Message {
union {
login @0 :Login;
commandGetData @1 :CommandGetData;
# etc.
}
}
The rpc protocol itself does something similar on the wire; see
rpc.capnp.
For determining message size, you shouldn't need to do any extra
framing, as capnp's stream serialization already makes it possible to
determine the size of a message: