[libvirt] [PATCH] Increased upper limit on lists of pool names

[Eric Blake]

On 03/15/2012 11:48 AM, Daniel P. Berrange wrote:
> Using the sequence of RPC calls to iterate over this is only
> addressing that second part of memory usage. So I'm not really
> feeling that's a huge win, given the complexity it introduces.
> 
> I'm inclined to say, that if people are creating setups with
> 1000's of volume & guests, then they can probably spare the
> extra memory for us to increase the main RPC message payload
> limit somewhat.

Our own docs/internals/rpc.html.in states:

>       Although the protocol itself defines many arbitrary sized data values in the
>       payloads, to avoid denial of service attack there are a number of size limit
>       checks prior to encoding or decoding data. There is a limit on the maximum
>       size of a single RPC message, limit on the maximum string length, and limits
>       on any other parameter which uses a variable length array. These limits can
>       be raised, subject to agreement between client/server, without otherwise
>       breaking compatibility of the RPC data on the wire.

Increasing limits makes sense, as long as we have a sane way to do it
while ensuring that on version mismatch, a large packet from the sender
doesn't crash an older receiver expecting the smaller limit.

In our XDR, should we be converting some of our 'type name<LIST_MAX>'
over to 'type name<>' notations, to state that they are effectively
unlimited within the larger bounds of the overall packet size?  Is 256k
for overall packet size still okay for the problem at hand?

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120315/84e3b879/attachment-0001.sig>