Daniel P. Berrange wrote:
The daemon has a buffer of outgoing data - and it appends to this buffer discrete 'XDR' messages. So we should be able to simply append another XDR message per notification & not have to overly worry about things being mixed up in the stream. When the client is deserializing replies during normal calls it'll have to keep an eye out for messages which arein fact notifications, rather than its expected reply, but again that should not be too hard since we're dealing with discrete XDR encoded messages. So AFAICT we don't need any OOB or piggybacking stuff - just queue up the data to send as normal.
Obviously at the moment, remote calls are completely synchronous on the client side. remote_internal.c:call() is a function which serialises the args, writes them to the socket, then sits there waiting for a reply. I guess we're not planning to make this asynchronous? (Or are we??)
Unless we change remote_internal.c, events which happen outside of calls won't be delivered upwards asynchronously, but only when the app happens to make a libvirt call.
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list