[AFS3-std] Unlimited array lengths

[Jeffrey Hutzelman]

On Fri, 2013-03-15 at 22:28 -0400, Benjamin Kaduk wrote:

> I do not think that there should be a hard-and-fast rule that putting 
> limit on variable-length arrays constitutes a protocol change; this would 
> not really help if (e.g.) new deployed servers must retain the old 
> (non-limited) interface for compatilibity with old clients.
> 
> The biggest issue I would be concerned with is whether imposing a limit 
> causes some functionality to be impossible.  E.g., for PT_NameToID, if 
> there is legitimiate need for more mappings than will fit in a single 
> array, the RPC can just be called again with more of the list.  But for 
> PT_ListElements or PT_ListOwned, if the list would "overflow" a fixed 
> limit, there is no other way for the truncated information to be obtained. 
> It seems like that case might require a new RPC to exist, even if the old 
> one does get a new limit imposed on it.  This is kind of the opposite of 
> what normally happens when a new RPC is added!

It's a bit tricker than that.  If you exceed the limit, the RPC will
simply fail with RXGEN_SS_UNMARSHAL or the like.  You can't really
assume that meant the limit was exceeded, and there's no way to tell
which one or what the actual limit is.  In the case of a limit on
something being returned by a server, there's no way for the server to
find out what the limit is.  So, the results don't get truncated; the
call just becomes impossible.

So yes, reducing a limit does result in a backward-incompatible change,
which in some cases might cause a serious problem.  That means that each
case where a limit is introduced requires some analysis to determine
what limit won't break things and how to handle cases where there is
more data to transfer _in a way that doesn't break old peers_.


> It kind of sounds like some person or persons are going to need to go 
> through the existing interface descriptions and look at the cases which 
> use variable-lengthe arrays.

Yup.