Menu
▾
▴
Re: [Libtirpc-devel] Proposed enhancement to libtiroc
|
From: Chuck L. <chu...@or...> - 2026-01-23 18:47:13
|
On 1/22/26 4:00 AM, Yair Lenga wrote:
> David Hayden suggested that I will post additional information about the
> motivation for the new xdr_fixedstring.
>
> The main motivation for putting xdr-fixedstring is efficiency. In my
> project we are using rpc for Hugh speed communication between c
> programs. Most developers do not understand the underlying encoding so
> that will write
>
> Struct Foo {
> Char s[100]
> }
>
> To represent a string without realizing this will result in send 400
> bytes on the wire, even for
> Strcpy(Foo.s, "USD")
> clnt_call(..., &foo...)
This behavior might be because that is how rpcgen deals with arrays
defined the way you do it here.
Each array element is aligned to 32-bits. So any element type that is
shorter than that, or whose size is not aligned to 4 octets, wastes
space in the wire representation.
IMHO libtirpc should stick with providing the XDR types that are
defined and specified in RFC 4506. That will provide the best
guarantee of interoperability between heterogeneous platforms.
> With xdr_fixedstring on foo.s, - it gets compacted to 8 bytes (1 int for
> the size, then 1 int for 3 bytes, zero padded). Very similar encoding
> like the xdr_wrapstring - in term of size. In my project, when we moved
> to the fixedstring xdr functions, we have realized dramatic performance
> improvement - order of magnitude. At this time, the solution need some
> "support" - we use macro on the ".x" to simplify the flow for
> developers, so that they can write
>
> Struct Foo {
> fixedchar(s, 100) ;
> }
>
> Which gets translated to xdr_fixedstring(xdrs, obj->s, sizeof(obj->s))
> in the generated stub. No magic - just some C macros.
There is a string type specified in RFC 4506 that does not have
the array packing problem. Can that be used instead?
> Hope this explanation/example provides useful context..
>
> Thanks,
> Yair
>
> On Sat, Jan 17, 2026 at 10:03 PM Yair Lenga <yai...@gm...
> <mailto:yai...@gm...>> wrote:
>
> Hi,
>
> Attached is the patch for xdr_fixedstring. Will appreciate if you
> can take a look at it.
>
> I need some points for:
> * Which file should have the man entry (could not find where
> xdr_string, xdr_wrapstring are defined)
> * What should I do with the map file - (src/libtirpc.map.in <http://
> libtirpc.map.in>). Add a new entry at the end with new version ?
> * Test cases - is there a place to commit ?
>
> Yair
>
> On Sat, Jan 17, 2026 at 6:31 PM Yair Lenga <yai...@gm...
> <mailto:yai...@gm...>> wrote:
>
> Steve,
>
> It's been a long time since my proposal - but I'm still
> interested in this improvement. We are being forced to update
> our system, including alignment with tirpc.
> I've pulled the code from git://git.linux-nfs.org/projects/
> steved/libtirpc.git <http://git.linux-nfs.org/projects/steved/
> libtirpc.git>
> But I'm not exactly sure how to build.
>
> Following from autgen.sh - I've installed automake, libtool, and
> I opted out from gssapi (--disable-gssapi) - got the library to
> work.
> Anything else I'm missing ?
>
> For the commit - do you want me to commit a feature branch - add
> PR, or just a patch file. Not sure if anything changed since 2022.
>
> Regards,
> Yair
>
> On Fri, Aug 5, 2022 at 6:35 PM Steve Dickson <st...@re...
> <mailto:st...@re...>> wrote:
>
>
>
> On 8/4/22 4:01 AM, Thorsten Kukuk via Libtirpc-devel wrote:
> >
> > Hi,
> >
> > On Sun, Jul 17, Steve Dickson wrote:
> >
> >> Hey!
> >>
> >> On 7/17/22 12:33 AM, Yair Lenga wrote:
> >
> >>> It will be implemented by new xdr function:
> >>>
> >>> bool_t
> >>> xdr_fuxedstring(xdrs, sp, maxsize) XDR *xdrs; char *sp;
> u_int maxsize;
> >>>
> >>> Note that when deserializing, EVERY character beyond the
> length will be
> >>> set to null to result in consistent behavior.
> >>>
> >>> Implementation is about 50 lines of addition code to
> rpcgen, and 30
> >>> lines of code to the xdr code (above function).
> >>>
> >>> Looking for feedback.
> >>>
> >> A couple thoughts... One, is there a man page?
> >> Secondly if we add this function does the SONAME
> >> need to be bumped?
> >
> > If you add a function, you need to assign a new symbol
> version to it,
> > but you don't need to bump the SONAME.
> > You only need to bump the SONAME, if you change a function
> interface
> > in an incompatible way or if you remove a function.
> Thank you for that clarification!
>
> Yair, please feel free to post the needed patches.
>
> steved.
>
>
>
> _______________________________________________
> Libtirpc-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libtirpc-devel
--
Chuck Lever
|
