On Thu, Mar 15, 2012 at 9:43 AM, Eric Blake <eblake@xxxxxxxxxx> wrote: > 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@xxxxxxxxxx +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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list