[OpenAFS-devel] Re: on sockets and devices in AFS

[Tom Keiser]

Spencer E. Olson <olsonse@umich.edu> wrote:
> From the users' point of view, practically speaking, another advantage fo=
r not
> writing these back is that a user could start up processes that create th=
ese
> sockets/pipes from multiple locations without disruption.
>
> If you have sockets/named pipes written back to the server, can they real=
ly be
> used from multiple clients? =A0The idea of "distributed sockets/named pip=
es" as

Personally, I don't think it's posix-ly correct for multiple
independent instantiations of the same stream socket/pipe vnode to
exist in parallel.  That being said, I fully concede that what Derrick
proposes is a very useful first-pass at socket/pipe/device support.


> Tom Keiser pointed out would require implementation in the file server, =
=A0i.e.
> socket/pipe data to be sent accross the file server (wouldn't it?). =A0It=
 also

Not necessarily.  Hypothetically, support for such a thing would
merely require that the server act as the coordinator--there may be
circumstances where we could bypass the server for bulk data flows.


> seems that this kind of solution would require some new type of knowledge=
 on
> the part of the software that reads/writes to/from the sockets/pipes. =A0=
This

The whole point would be to provide complete location independence;
given that we have a global namespace, location transparence should
(ideally) hold for reading from/writing to sockets/pipes.  More to the
point, Posix provides the API--we would merely do the right thing on
vop_read, vop_write, etc...


> seems a bit more of a stretch in terms of purpose/goals of AFS.
>

Disagree.  Location transparence is an important goal of AFS-3;
diverging from this goal is something which should be done with
careful thought and consideration.  My biggest concern is that some
sites may come to depend upon the machine locality semantics: N nodes
using a single path to N separate distributed socket/pipe circuits,
thereby--despite its technical feasibility--making it quite difficult
to deploy distributed pipes/sockets (for purely political reasons).
IMHO, that would be a lamentable outcome.

Cheers,

-Tom