[AFS3-std] XCB union decoding (was Re: Encoding IPvN addresses)

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6F399A27A047CFAAEE147CA8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 2/11/2011 12:12 PM, Andrew Deason wrote:
> On Fri, 11 Feb 2011 11:43:43 -0500 (EST)
> "Matt W. Benjamin" <matt@linuxbox.com> wrote:
>=20
>> XCB is structured as a "bulk" interface.  Clients receive a sequence
>> (actually sequences) of messages, where the messages are in the union
>> (ditto for results).  I understood the interesting case to be if a
>> client receives a sequence of callbacks of intermixed known and known
>> type.  I would expect clients to ignore unknown messages, but I guess
>> the point at issue is whether a sequence containing unexpected union
>> records can even be decoded.  Can it?=20
>=20
> Currently, no. But with the new union structure, yes. (And you could
> even have the application handle the unknown 'blob', if we allow the
> application to install a handler for an unknown discriminator, as jhutz=

> has mentioned)
>=20
> But in that situation with XCB, if you get an unknown callback type,
> there's not anything you can do with it, so the only thing I can see
> happening is that you drop it. And so, you've dropped a callback break,=

> which means losing information or keeping stale data around in the
> cache. I would expect that the fileserver be told that a client doesn't=

> understand a certain callback type, and so would have to work around it=

> (probably by sending a Cancelled or something).

The condition of an unknown XCB notification being issued to a cache
manager would have to be an error.  If XCB is going to support the
introduction of new notifications, the cache manager must inform the
file server what the supported notification types are ahead of time via
the Cache Manager Capabilities.  Otherwise, the file server would not be
able to send the correct notification form.

In the case that such an error condition were to occur, the cache
manager would have to treat the receipt of the notification as a generic
invalidation just as callback breaks are handled today.

Jeffrey Altman




--------------enig6F399A27A047CFAAEE147CA8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQIcBAEBAgAGBQJNVcBXAAoJEPd6c1WStpoEVFIQAJFqJ/1YPlZMLMU1S9bKcDPG
bhvtWgtKMXCnzzQy4ztpGlMDSD4S6LAmw950spAD5/I+XDyhWIT6rc4zGdv8nQC6
zAYXzadBRD26+50qcXdaQpe6zs/ctkRkpLncQjaEIw9DdB6IuTDdyACk5Lvp5Os3
QcBzVc1JKiZg0k9VBBUUbU+0Ox6nN00dm1GT7yOvNIK/wtFFMrAQpAN4kujb2BvQ
6pA53EI4ipR0u/0Vj9MWDSpDrfTcWkk8jWefGxkyhwKGY0hx8P60vsN5YU8PKGvv
WkXJlYl7bzL+SdmKIspCZXp/MXZ6X2ePXPTq57dafElv3KoAAjYnakdSXqLBlcE7
IJ/FKf8Br0ggFkxQwEZOx/Y4HrT8iDFTuXx2GRKSQUX9ZJa/YfnQE4xq35/fuzWt
dB+wYkbdeX734AZMoenkvVHVnAdHnUgXVpjUT22PLBM0nG49y0F1FstC1LRuaJm9
0CjQLzd2ASPTRYECYRHsUw64RRZp1AcHqPziUeoBgxYvQ3MyJgrnQbtddNWh+FLa
8YW6TnW4l7QnEhDjH/4dMaOBvAGWBdJKMln6nySVwbVjm+JVFg3afndw+LkeZ49d
CVsoiahvsqFQfinjRQ9/PZZwsAb7kuxM1NXiFdAG5tAXmFPvJVDKHUFuVwre6Cda
IPCuMz63K32rQsaQqBa1
=SDpn
-----END PGP SIGNATURE-----

--------------enig6F399A27A047CFAAEE147CA8--