[OpenAFS-devel] Some low-hanging RPC fruit vs long-term needs

[Derrick Brashear]

On Thu, Dec 16, 2010 at 2:13 PM, Steve Simmons <scs@umich.edu> wrote:
> This was originally subject "[OpenAFS] GiveUpAllCallBacks callers." I've =
moved it over to developers and kicked off a new thread.
>
> On Dec 14, 2010, at 6:50 PM, Simon Wilkinson wrote:
>
>> I think that, as responsible developers and vendors, we should not be kn=
owingly shipping new code which can crash previous stable releases. However=
, I also find myself agreeing with the various objections that have been ra=
ised to creating new capability bits, tying together unrelated RPCs, and re=
placing RPCs because of implementation faults.
>>
>> At this point, I think we should take a look at how other protocols deal=
 with the problem of avoiding triggering bugs in badly written peers. The u=
se of version string matching is pretty common in this area - witness OpenS=
SH's use of the protocol version information to avoid their client from cra=
shing other's servers, Apache's use of header matching to avoid breaking no=
n-confornmant HTTP clients, and so on.
>>
>> If we are going to have a richer AFS ecosystem, then we're going to have=
 to gain the ability to deal with these problems. I think that this means t=
hat in the future, we're going to have to produce a new versioning RPC whic=
h allows the distribution of structured vendor and version information. How=
ever, we don't have that RPC now, and it doesn't help us with already deplo=
yed servers. In the short term, I think it would be appropriate to use the =
RX version identifier.
>
> What he said. This is a problem, and solving it in any near-optimum way i=
sn't going to be easy. We should address it, write RFCs as needed, yadda, y=
adda. But we should not let the perfect be the enemy of the good here. We'r=
e not going to have that ready as part of 1.6, maybe not 1.8. In the interi=
m, I'd rather see us do a few things that I think are small/easy to impleme=
nt but will ease the current pain.
>
> One is a ping equivalent. The RPC suite that Sun developed for NFS, netin=
fo, etc, uses this as a core feature. It's a effective workaround for some =
limitations of UDP-based services, but it does more than just work around t=
hat issue. In Sun terminology (well, assuming I recall Sun terminology corr=
ectly) for every RPC type there is a reserved call 0 that's just a ping. Ma=
ke that procedure call, and it should return true immediately.

GetCapabilities will (I hope!) return a fixed vector, and so should
always be as cheap to call as we can manage. We should, if we're
pursuing this, just add that globally.


> The version report we get from rxdebug -v is useful, but as others note, =
it can and is set by various sites to reflect their local needs. A 'core ve=
rsion' flavor that strictly follows AFS releases would be useful, eg, rxdeb=
ug -coreversion would only report a string the user shouldn't muck with. An=
d yes, I know that git-ish things have to be considered, yadda, yadda. The =
devil is always in the details.

Yes, yes it is.
If you patch 1.4.12, do you report 1.4.12? What if you have all the
1.4.13 patches in when 1.4.13 releases?





--=20
Derrick