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 beenreceived 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 versioningNot 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 providea 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)
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
