[Libvir] RFC [0/3]: Re-factor QEMU daemon protocol to use XDR

[Richard W.M. Jones]

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 
>> change.
>>
>> 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 
library.

>> 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.

Rich.

-- 
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...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070323/f25d5429/attachment-0001.bin>