Re: [Libtirpc-devel] Proposed enhancement to libtiroc

[Yair L. <yai...@gm...>]

Hi.

I agree with you about the "long chain to pull". There is no practical
option of changing the RFC, or to convince ALL the implementations out
there to accept new functions.

On the flip side, I believe that there is value in enhancing the library
(in a way that does not break backward compatibility). The benefit I see
(for this improvement, and potentially other improvements) is for actively
developed applications, which are based on actively developed distributions
(Ubunton, RedHat, ...).

So I can see two options - I can make another fork of TIRPC - enhance it,
and hope that users will find the change, evaluate it and will take the
risk of jumping from a vendor supported version into unknown fork (VERY
UNLIKELY), or try to work with the main TIRPC repos which are used by most
platform - and get the change accepted - which is what I'm trying to do.

You are correct that making it part of RPCGEN (as opposed to using #define
macros) will make it easier to adapt this function. I believe Thorsten
Kukuk, who took over maintaining RPCGEN (when glibc removed the
RPCGEN/SUNRPC) is on this mailing list. I am very HOPEFUL that there can be
a similar path to also evolve RPCGEN - but this is not required for this
feature to be usable.

Emphasizing:
* No plan to get TIRPC/RPCGEN to "compete" with protobuf, AVRO or any of
the other modern implementations. Goal is to extend the life of existing
applications that use RPCGEN/SUNRPC - to benefit from significant
performance improvements with minimal effort, without having to go through
massive rewriting.
* I've already implemented the changes on my own systems (with forked
RPCGEN). My motivation is make it easy for other application to leverage
those benefits with minimal effort.

Regards,
Yair

On Sun, Jan 25, 2026 at 7:33 PM Chuck Lever <chu...@or...> wrote:

> There are multiple independent implementations of the TI-RPC API
> on various operating systems. Are you planning to introduce this
> new feature for those as well?
>
> RPC applications that use special features that are not available
> everywhere immediately become non-portable.
>
> There is no standard fixed-string type in the XDR language (RFC
> 4506 appendix II) . Do you have plans to modify rpcgen to recognize
> the new type and generate code for it?
>
> I think you should provide the facility you need for your own
> application. The process of creating a fixed-string standard type
> (updating RFC 4506) and then getting other TI-RPC implementations
> to adopt it, then creating documentation... that's a very long
> chain to pull.
>
>
> On 1/24/26 3:52 AM, Yair Lenga wrote:
> > Chuck,
> >
> > Thanks for feedback.
> >
> > From my experience, the behavior of the array serialization is
> understood by experienced developers with understanding of the underlining
> protocol. But this is not true for the “average” c developer, who view the
> rpcgen/xdr as a “black box”. For those, very easy to fall into the “trap” I
> described, resulting in inefficient network transfer, with no clear
> documented alternative.
> >
> > The xdr-string that you mentioned works only with dynamically allocated
> strings (malloc based). In many application, the overhead of
> strdup/free/malloc, and the complexities for remembering to free any string
> / risk of leaking memory are too high, and there is strong preference to
> use char [n] - no malloc, no leaks, simple strcpy/strlcpy. The
> xdr-fixed-string will extend the benefit of this encoding to char[x]
> strings.
> >
> > Just an example. In financial application the type “currency”, will be
> char[4] - 16 bytes with xdr-array, 8 bytes for xdr-string and the new
> xdr-fixed string.
> >
> > Out of curiosity - are you using xdr/rpc in an application context ? I’m
> trying to get a feeling of how many applications are “out there” using
> rpcgen/xdr.
> >
> > Regards,
> > Yair.
> >
> > Sent from my iPad
> >
> >> On Jan 23, 2026, at 20:47, Chuck Lever via Libtirpc-devel <
> lib...@li...> wrote:
> >>
> >> 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?
>
> --
> Chuck Lever
>