On 05/22/2012 08:05 AM, Peter Krempa wrote:
>> +
>> +struct remote_connect_list_all_domains_ret {
>> + remote_nonnull_domain domains<>;
>
> This is an unbounded array; we aren't using any of these anywhere else.
> I wonder if reusing REMOTE_DOMAIN_ID_LIST_MAX would be reasonable
> instead. Then again, we are returning more information per domain: a
> name, uuid, and id, so maybe REMOTE_DOMAIN_NAME_LIST_MAX is the best we
> can do (currently 1024, but then again there is the pending patch to
> raise that limit). The name element may make us run into RPC limits
> even if we don't otherwise enforce a limit.
>
I chose the unbounded array intentionaly as I don't see any point in
applying two limits on the size of the RPC message. I agree that the
global message size limit is good for avoiding DoS attacks.
Interesting point - maybe it's worth re-evaluating which of our existing
limits should be made unbounded, under the umbrella of the overall RPC
limits being good enough.
I'll add the limit to conform with the rest of the code and hopefuly
nobody will need more than 1024 machines soon.
Yeah, if we decide to go with unbounded structs within the scope of a
bounded maximum message, we should probably do it across the entire .x
file at once.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org