[OpenAFS-devel] When is an AFS request-response completed?

[Andrew J Klosterman]

(thanks for reminding everyone about channel number being embedded in the
cid, I just took the 32-bit quantity for granted since I understood that
it needed to be the same to identify a request-response pair.)

Hmm.  Based on this, I am seeing what I believe is some strange behavior
during a client-server interaction.

I am observing (epoch, cid) pairs issued as AFS operations with various,
sequential callNumbers without any response packets from the server that
contain any data, only ACKs.  After the ACKs, the client increments the
callNumber and issues an additional operation.

Thus, there appears to be more than one call at a time that should be in
progress at the server -- only one of which is actually replied to.
(multiple outstanding operations (no response data send from server, only
ACKs) issued on same (epoch, cid) pair with different callNumbers)

This seems, to me, to violate one of the points from your document:
	"Although only _one_call_can_use_a_channel_at_one_time_, the call
	number allows peers to distinguish packets on the same channel
	that belong to different calls."
because more than one call is appearing on a channel (low 2 bits of cid)
at a time.  Is the client misbehaving in this situation?

What is the correct action for a server to take in this case?  Only
respond to the last AFS Operation sent along that (epoch, cid) pair?
(This puts a heavy burden on the server -- it has to work on each call and
interrupt processing of earlier ones and start servicing the new ones.)

Any insights or ways I could further clarify the situation?

On Fri, 2 Nov 2001, Nickolai Zeldovich wrote:
> > I used the mentioned document to help out with determining the tuple of
> > (epoch, cid, callNumber) for uniquely identifying the client's request.
> > It was extremely helpful in that regard.
>
> Ah, cool.  Glad to see it's helpful in some way :-)
>
> > The next question becomes, how are the responses to a request identified?
>
> The short answer is, I believe, "the response must come back on the same
> Rx connection and channel, and have the same call number".
>
> When a client wants to make an Rx call over an existing Rx connection, it
> allocates an available channel to that call, and a new call number within
> that channel.  The first packet then goes out on that channel with the new
> call number, and this informs the server that this channel is in use again.
>
> Once the client has finished sending its data on that channel, the server
> can switch into sending mode, and send the response back, over the same
> channel.  Since Rx channels exist in the context of an Rx connection, the
> response packets must come back on the same Rx connection (identified by
> epoch/CID) and channel (identified by the lower two bits of CID).  The
> call number must also stay the same on all the packets associated with
> this Rx call.
>
> > From other sources, I have come to believe that the a client's requests
> > are uniquely identified by three fields of the Rx header: epoch, cid,
> > callNumber.
>
> That's almost the case; the channel number must also be included for this
> to be unique.  (I guess it's part of CID, if you look at all 32 bits.)
> Since call numbers are allocated per-channel, I could have call # 2 on
> channel 1 and call # 2 on channel 3 at the same time.
>
> Hope that helps,
>
> -- kolya
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>


--Andrew J. Klosterman
andrew5@andrew.cmu.edu
http://www.ece.cmu.edu/~andrew5