|
From: Yair L. <yai...@gm...> - 2026-01-22 09:00:49
|
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...)
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.
Hope this explanation/example provides useful context..
Thanks,
Yair
On Sat, Jan 17, 2026 at 10:03 PM Yair Lenga <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). 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...> 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
>> 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...> 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.
>>>
>>>
|