[Libvir] RFC [0/3]: Re-factor QEMU daemon protocol to use XDR
Richard W.M. Jones
rjones at redhat.com
Fri Mar 23 12:53:12 UTC 2007
Daniel P. Berrange wrote:
> On Fri, Mar 23, 2007 at 10:02:33AM +0000, Richard W.M. Jones wrote:
>> As you say, no appreciable difference in code side before and after the
>> It's interesting to note what SunRPC gives you over XDR (which you have
>> also noted in your emails):
>> - serial numbers to correlate client requests and server responses (in
>> SunRPC these are called 'XID's)
> Unfortunately they crippled their use by only providing a single 'rm_xid'
> field. So the only way to do tracking is to mandate that the rm_xid of the
> method reply matches the rm_xid of the method call. This is why it is
> impossible to do asynchronous notifications from the server - ie let the
> server send you a message without any corresponding message having been
> received from the client.
Well ... I don't think it's "impossible". We may have to invent a magic
XID for asynchronous replies however.
I rather question why full XIDs are really necessary unless we are
proposing that the server can answer RPCs out of order. All we really
need to know is: "is this the reply for my previous request, or is it an
asynchronous message?" and for that XID != 0 / XID == 0 is fine.
>> - program numbers and versioning
> Not very different to replicate though - and in a less onerous way than
> SunRPC approach. It would seem that for every new version you need to provide
> a new set of all the marshalling methods defined by your program, even if
> you're only adding one new one.
I think you can add new procedures, because if the server doesn't
understand a procedure number then it sends back a well-defined response
(ar_stat == PROC_UNAVAIL). So this is similar to the state of the
current C API where we can add new procedures, but if we ever wanted to
change an existing procedure then we'd need a whole new version of the
>> About strings: char foo[MAX] (as you pointed out) could be replaced by
>> variable-length strings. There are at least three catches: (1) Who
>> owns/frees the strings? - I was never able to work that out. (2) NULL
>> is not supported directly, you have to use the option-looks-like-
>> a-pointer type (string *). (3) If the client and server don't trust
>> each other then you need to check the length of incoming strings
>> carefully to make sure that they aren't huge and potentially could cause
>> a DoS.
> In the XDR definition you can give a maximum size eg
> string foo<>;
> Allows an unlimited size string (MAX_INT32), while
> string foo<500>;
> Would ensure that the generated XDR routines will refuse a string larger
> than 500 bytes.
'Tis true. I'll need to check that the XDR receiving routines actually
enforce the maxima.
Emerging Technologies, Red Hat http://et.redhat.com/~rjones/
64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421
"[Negative numbers] darken the very whole doctrines of the equations
and make dark of the things which are in their nature excessively
obvious and simple" (Francis Maseres FRS, mathematician, 1759)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
More information about the libvir-list