[Gluster-devel] RPC help
Raghavendra G
raghavendra at gluster.com
Mon Jul 27 04:45:09 UTC 2015
On Sat, Jul 25, 2015 at 5:12 AM, chris holcombe <
chris.holcombe at canonical.com> wrote:
> Hey Everyone!
>
> I'm having trouble figuring out how the RPC mechanism works in Gluster.
> Any help would be hugely appreciated!
> When a client makes a request from the glusterd service an xdr encoded rpc
> is sent to it. From what I'm gathering by looking at the source and GDB
> the main struct to be concerned with is:
>
> struct rpc_transport_req {
> rpc_transport_msg_t msg;
> rpc_transport_rsp_t rsp;
> struct rpc_req *rpc_req;
> };
>
> From tracing it down to writev I see that the data looks as follows before
> being written out:
>
> (gdb) p req
> $4 = {msg = {rpchdr = 0x7ffff36c7c00, rpchdrcount = 1, proghdr =
> 0x7ffff36c7d20,
> proghdrcount = 1, progpayload = 0x0, progpayloadcount = 0, iobref =
> 0x7fffe4000920}, rsp = {
> rsphdr = 0x0, rsphdr_count = 0, rsp_payload = 0x0, rsp_payload_count =
> 0, rsp_iobref = 0x0},
> rpc_req = 0x555555802dac}
>
> I'm having trouble figuring out if this req variable is actually what is
> being written out to the wire.
>
> Now on the reply side the first header is the length of the reply. That
> makes sense. What I'm not getting is if the rpc_transport_req is actually
> being serialized with xdr or are parts of it being serialized? It's hard
> to tell. I need to read the __socket_proto_state_machine over again and
> understand it better. I searched around for notes or anything online and
> there's really almost zero written about this.
>
> So my questions are:
> 1. Is the rpc_transport_req being xdr encoded onto the wire?
>
No, its the contents of rpc_transport_msg_t (req->msg, defined in
rpc-transport.h) which is written onto the wire. For more details look into
functions __socket_ioq_new and __socket_ioq_churn_entry (both defined in
./rpc/rpc-transport/socket/src/socket.c).
2. Are there any good materials out there that explain the protocol?
> Figuring it out by reading the source and break pointing the code is slow
> going. Esp with the epoll threads making tracking things down hard.
>
Our rpc implementation is based on RFC 5531 [1]. To get an high level flow,
you can look at socket_submit_request and socket_submit_reply and keep
following the control flow.
[1] https://tools.ietf.org/html/rfc5531
regards,
Raghavendra.
> Thanks for the help!
> -Chris
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>
--
Raghavendra G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20150727/8cac890c/attachment.html>
More information about the Gluster-devel
mailing list