On 03/29/2016 01:11 AM, Wouter Verhelst wrote: > On Mon, Mar 28, 2016 at 07:59:15AM -0600, Eric Blake wrote: >> Although the proper use of the handle field during transmission >> phase was implied, it never hurts to make it more explicit that >> clients should alter the handle on each message, and the server >> repeat the handle unchanged, in order for the client to track >> when the server is sending replies out of order. >> >> >> Replies need not be sent in the same order as requests (i.e., requests >> -may be handled by the server asynchronously). >> +may be handled by the server asynchronously). Clients SHOULD send a >> +different value of handle for each request, and the server MUST use the >> +same value for handle as was sent by the client for each request that >> +the server is replying to, so that the client may correlate which >> +request is receiving a response. > > NAK. This implies that a client should not ever reuse handles, while it > is legal for a client (and in fact the kernel does this) to reuse > handles once the server has ack'd the request. Nothing a little word-smithing can't fix. I'll try a v2, probably along the lines of: Clients SHOULD use a handle that is distinct from all other currently pending transactions, but MAY reuse handles that are no longer in flight; handles need not be consecutive. In each reply, the server MUST use the same value for handle as was sent by the client in the corresponding request. In this way, the client can correlate which request is receiving a response. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature