On 03/15/2012 05:51 AM, Daniel P. Berrange wrote:
> On Thu, Mar 15, 2012 at 06:22:38AM -0500, Jesse Cook wrote:
>> Just to clarify, you would like to see:
I have not actually tried this, but based on my understanding of the RPC
famework, I'd expect:
>>
>> v0.9.10 pre-patch client talk to v0.9.10 patch server
If there are 256 or fewer names, this works as it always did.
If there are more than 256 names, then the server tries to send back
more array elements than the client is prepared to receive - the client
will treat the response as an invalid RPC, and my recollection is that
under these circumstances, the client then forcefully disconnects the
session under the assumption that the server is broken.
To avoid breaking such clients, you'd probably need some way for clients
to warn the server if they are prepared to receive more than the old max
(similar to how we had to add VIR_TYPED_PARAM_STRING_OKAY as a way for
clients to tell the server that they were prepared to handle typed
strings being returned). Basically, any time you change the RPC to
allow more data to be returned than what was previously possible, the
server should not return that additional data unless the client has
negotiated that it is aware of the additional data.
>> v0.9.10 patch client talk to v0.9.10 pre-patch server
No problem for the client. The server will never successfully return
more than 256 names. However, if the client requests more than 256
names, I'm not sure whether the server will silently truncate to 256 or
whether it will return an RPC error because it was unable to provide the
reply.
>
> And for comparison
>
> v0.9.10 pre-patch client talk to v0.9.10 pre-patch server
Should be the same behavior as a v0.9.10-patch client talking to a
pre-patch server - you can't successfully send more than 256 names, but
I'm not sure how the server will react if the client requests too many
names. Actually, it might be slightly different - the client might
reject the request up front without even contacting the server.
>
> Obviously for
>
> v0.9.10 patch client talk to v0.9.10 patch server
>
> I'd expect "just works" :-)
Of course, if both sides are prepared to handle the new RPC protocol, it
should just work.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org
v0.9.10 client did not want to play nicely with the v0.9.10 server via
qemu+ssh. I got frustrated and just tried running the test from a
client running an older version of libvirt. When connecting to
v0.9.10, it behaved the same way the pre-patched did in my cover
letter. I don't have full test results because of the communication
errors I was getting. I'll try to either figure it out tomorrow or
just use the older version as the client (pre-patch and patch).
-- Jesse