[Gluster-devel] Usage of xdata to send anything on wire

[Raghavendra Gowdappa]

----- Original Message -----
> From: "Poornima Gurusiddaiah" <pgurusid at redhat.com>
> To: "Gluster Devel" <gluster-devel at gluster.org>, "Niels de Vos" <ndevos at redhat.com>, "Jeff Darcy"
> <jdarcy at redhat.com>, "Raghavendra Talur" <rtalur at redhat.com>, "Rajesh Joseph" <rjoseph at redhat.com>, "Pranith Kumar
> Karampuri" <pkarampu at redhat.com>, "Soumya Koduri" <skoduri at redhat.com>, "Raghavendra Gowdappa"
> <rgowdapp at redhat.com>, "Anoop Chirayath Manjiyil Sajan" <achiraya at redhat.com>
> Sent: Friday, May 13, 2016 3:18:51 PM
> Subject: Usage of xdata to send anything on wire
> 
> Hi,
> 
> In the recent past, have seen multiple instances where we needed to send some
> data along with the fop on wire. And we have been using the xdata for the
> same. Eg:
> 1. Add lease-id, transaction id to every fop.
> 2. Send the xattrs to invalidate in xdata.
> 3. Send the share flags during open.
> 
> There were concerns raised around this for the below reasons:
> 1. word-size and endianness
> 2. security issues
> 3. Backward compatibility issues i.e. old/new client and server combination.

Can you please elaborate on the above 3 points? A bit more verbose explanation of what and how the above factors cause problems will help.

> 
> Initiating this mail to arrive at a conclusion, whether we can use xdata or
> we need to find a different solution, if so what is the solution.
> Your thoughts comments are appreciated.
> 
> Solution 1:
> To get rid of sending xdata on wire, one of the solution could be to have
> protocol versioning in Gluster. With this we can modify xdr structures for
> each release and get rid of xdata. But this will be huge work.
> 
> Solution 2:
> - Change dict, to not be an opaque structure , but an array of data elements
> which is a union of (int, string etc.).
> - Backward compatibility issues is when the newer server/client adds data to
> dict but the old client/server fails to read the dict. This is the
> responsibility of the programmer to make sure, thta this case doesn't fail
> silently, op version can be used if it is done as a part of adding new
> feature/volume set. Another approach would be, if client has a list of
> capabilities(features) the server supports it can accordingly tune itself to
> access the xdata.
> 
> Regards,
> Poornima
> 
>