On Tue, 12 Mar 2019 18:48:29 +0000
Slavomir Kaslev <kaslevs@xxxxxxxxxx> wrote:
> > We could send:
> > int argc = 6;
> > char **argv = { "4096", "16", "33445", "33446", "33448", "33449" };
> >
> > Or, if you are not comfortable with sending ASCII and converting, what
> > about have a specific "sending an array of numbers"?
> >
> > int argc = 6;
> > int *argv = { 4096, 16, 33445, 33446, 33448, 33449 };
> >
> > Thoughts?
>
> I don't see any drawbacks of this approach (modulo a bit of
> arithmetic). I implemented it the way it is following how the listener
> is sending port numbers back to the recording process.
>
> Should we also switch the listener to use the same encoding of ports
> with protocol V3 before the next release?
Yeah, I think we can do that.
>
> How about options (which is the only other non-text use of the
> variable buffer part of messages)? Currently the only option in use is
> MSGOPT_USETCP and can become simply "tcp" on the wire.
>
> We can then have a convention that the buffer at then end of messages
> is always text and drop the second union in tracecmd_msg.
>
Sure.
Do you think there's any use to keeping the "flags" field for the args?
I was thinking that we should rename trace_req to trace_args and add a
"type" field that can be used to verify the type of arguments being
sent.
enum {
TRACE_ARGS_PORTS = 1,
TRACE_ARGS_OPTIONS,
TRACE_ARGS_ETC,
[...]
};
struct tracecmd_msg_trace_args {
be32 type;
be32 argc;
};
That way the type will define the arguments being sent, and the
other side will know what is expected of the args, and even test to
make sure they make sense.
-- Steve
|