On 09/18/2017 05:55 AM, Dr. David Alan Gilbert wrote: >>> I think we have other quite simple ways to solve the "unexpected >>> reply" and "per-client-id duplication" issues you have mentioned. >>> >>> Firstly, when client gets unexpected replies ("id" field not in its >>> own request queue), the client should just ignore that reply, which >>> seems natural to me.
That's probably reasonable, if we document it. >> >> The trouble is that it may legitimately use the same "id" value for >> new requests. And I don't see a simple way to handle that without >> races. > > Under what circumstances can it reuse the same ID for new requests? Libvirt uses distinct id's for every message on a single connection, but there is always the possibility that it will use id 'libvirt-0' on one connection, then restart libvirtd, then use id 'libvirt-0' on the second connection (there's nothing that I saw in libvirt code that saves the current 'mon->nextSerial' value in XML to survive libvirtd restarts). > Can't we simply tell it not to? Since use of OOB handling will require client opt-in, yes, we can make part of the opt-in process be a contract that the client has to do a better job of avoiding duplicate id's across reconnects, if we think that is easier to maintain. >>> >>> Then, if client disconnected and reconnected, it should not have the >>> problem to generate duplicated id for request, since it should know >>> what requests it has sent already. A simplest case I can think of is, >>> the ID should contains the following tuple: >> >> If you assume the "same" client will recover its state, yes. >> >>> >>> (client name, client unique ID, request ID) >>> >>> Here "client name" can be something like "libvirt", which is the name >>> of client application; >>> >>> "client unique ID" can be anything generated when client starts, it >>> identifies a single client session, maybe a UUID. >>> >>> "request ID" can be a unsigned integer starts from zero, and increases >>> each time the client sends one request. >> >> This is introducing session handling, and can be done in server side >> only without changes in the protocol I believe. The 'id' field can be _any_ JSON object - libvirt currently sends a string, but could just as easily send a dict, and then libvirt could supply whatever it wanted in the dict, including uuids, to ensure that future reconnects don't reuse the id of a previous connection. But right now, 'id' is opaque to qemu (and should stay that way) - if qemu is going to do any work to ensure that it doesn't send a stale reply to a new connection, then that has to be tracked externally from whatever 'id' is passed in; or we just document that clients wanting to use OOB handling have to be careful of their choice of 'id' (and leave it up to the client to avoid confusion, because qemu doesn't care about it). I'm also fine with requiring that clients that opt-in to OOB handling be documented as having to ignore unknown 'id' responses, since we already document that clients must be able to ignore unknown 'event' messages. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature