On Tue, Feb 23, 2010 at 2:21 AM, Derrick Brashear <[email protected]> wrote: > Currently, this as well as the 2 types above it are unused and as far > as I can tell, have been unused since at least afs 3.2. > > I'd like to propose the use of this for a peer to share its network > and packet settings using registered tags and values, notably the > number of jumbogram fragments a side is prepared to send and receive, > and the maximum fragment size a side is prepared to receive (the goal > being large packets) > > Before I write up a formal proposal on this I thought I'd float a > trial balloon. Brief discussion in Edinburgh did not yield any major > dissent though the proposal lacked any real meat at the time. >
Hi Derrick, This is intriguing. I have a few questions regarding interop. Given that this packet type won't get a response from contemporary clients, is the idea to handle this as an asynchronous negotiation, upgrading if/when we receive a reply? Detecting peer version upgrades with this scheme seems relatively easy: just resend the params packet occasionally. However, I'm not entirely sure how to deal with peer version downgrades. Do you have any ideas? Are we simply anticipating that all uses of this negotiation scheme will lead to the peer sending an abort if it downgrades to an earlier rx implementation? Cheers, -Tom _______________________________________________ AFS3-standardization mailing list [email protected] http://michigan-openafs-lists.central.org/mailman/listinfo/afs3-standardization
