On 07.02.2012 02:09, Michael Roth wrote: > guest-sync leaves it as an exercise to the user as to how to reliably > obtain the response to guest-sync if the client had previously read in a > partial response (due qemu-ga previously being restarted mid-"sentence" > due to reboot, forced restart, etc). > > qemu-ga handles this situation on its end by having a client precede > their guest-sync request with a 0xFF byte (invalid UTF-8), which > qemu-ga/QEMU JSON parsers will treat as a flush event. Thus we can > reliably flush the qemu-ga parser state in preparation for receiving > the guest-sync request. > > guest-sync-delimited provides the same functionality for a client: when > a guest-sync-delimited is issued, qemu-ga will precede it's response > with a 0xFF byte that the client can use as an indicator to flush its > buffer/parser state in preparation for reliably receiving the > guest-sync-delimited response. > > It is also useful as an optimization for clients, since, after issuing a > guest-sync-delimited, clients can safely discard all stale data read > from the channel until the 0xFF is found. > > More information available on the wiki: > > http://wiki.qemu.org/Features/QAPI/GuestAgent#QEMU_Guest_Agent_Protocol > > Signed-off-by: Michael Roth <mdroth@xxxxxxxxxxxxxxxxxx> This makes sense. And it's workable for libvirt. IIUC, client can send 0xFF to the guest agent and vice versa, right? Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list