Re: [Libvir] RFC [0/3]: Re-factor QEMU daemon protocol to use XDR
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)
Attachments:
- smime.p7s (application/x-pkcs7-signature — 3.2 KB)