[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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 redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]