On Wed, Jul 18, 2007 at 04:13:38PM +0100, Richard W.M. Jones wrote:
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 are in 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??)
It'll be a little tricky, but I don't think we'd want to make it asynchronous. If we just adapt it so that if the packet is gets back is a notification we put it aside & read another packet for its real reply. Once its got the real reply then it can dispatch any notifications it queued up. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|