Re: [Libtirpc-devel] Proposed enhancement to libtiroc

[Chuck L. <chu...@or...>]

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