Given the current state of the chapter, this new proposal
should only be considered if there is overwhelming sentiment
that the current proposal is flawed and this one solves its
problems. My own view is that this is the case.
But it is important that a large number of people
declare their support for the proposal, if we want to
reopen the discussion. In other words, I think we have to consider
the proposal dead unless proven otherwise. So if you
prefer it to the current one, speak up!
One observation about the current port_open/accept/connect
section is that we don't have any good examples of how this
might be implemented as anything other than thin wrappers
on the corresponding socket calls. I spent a little time
looking into DCE mechanisms, but became totally confused (apparently
a common reaction with DCE). CORBA is another possibility,
but I have not seen any ideas.
A possible criticism of the above proposal is that MPI has tried
to avoid mandating implementation details (such as requiring sockets).
We should keep in mind, though, that:
- no implementors have proposed using something other than sockets,
and indeed the current spec may be so restrictive as to require them.
- using sockets is not a performance issue, because the original
socket can be used to bootstrap other communication
- sockets are actually a generic mechanism that can be built
on top of different protocols (TCP, unix sockets, active messages,
etc).
Sockets have the advantage that their behavior is well-understood,
and we have had difficulty specifying the precise behavior
of connect/accept. Moreover, they are arguably more portable and
more flexible than port_open/connect/accept, and not much more
difficult to use.
I think the proposal for this call is motivated by the recent
discussion of IACCEPT, in which it became more clear that
we had only brushed under the rug some issues that are
already handled well by the unix socket interface. Those
issues being:
- implementors (or some of them) have no idea how they would
implement iaccept
- the main alternatives to iaccept are
o nothing - this leaves us with no possibility of client/server
o listen - this begs the question of why we are reinventing
the wheel, if it is not a better one.
> MPI_NAME_PUBLISH
> MPI_NAME_GET
> have no clear mapping and are unlikely to be implemented in most environments.
> Other mechanisms are probably better, and should be under user control anyway.
These are likely to be implemented in a LAM or PVM environment,
where there are daemons, and a well-defined namespace. Having these
functions doesn't interfere with user control for a user
who wants to use his/her own publishing mechanism.
I'm not sure what "other mechanisms" the author of this sentence
was thinking of.
Since these functions are orthogonal to port_open/accept/connect,
perhaps they should be considered separately.
Bill