Spencer E. Olson <[email protected]> wrote: > From the users' point of view, practically speaking, another advantage for not > writing these back is that a user could start up processes that create these > sockets/pipes from multiple locations without disruption. > > If you have sockets/named pipes written back to the server, can they really be > used from multiple clients? The idea of "distributed sockets/named pipes" 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, i.e. > socket/pipe data to be sent accross the file server (wouldn't it?). It 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. 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
