Almost all of the complexity in MPI client/server routines
addresses the question ``how does the client find out how
to contact the server?''
The difficulty, of course, is that there is no existing
communication channel between them, yet they must somehow agree
on a rendezvous point where they will establish communication ---
Catch-22.
Agreeing on a rendezvous point always involves a third party.
The third party may itself provide the rendezvous point or may
communicate rendezvous information from server to client.
Complicating
matters might be the fact that a client doesn't really care
what server it contacts, only that it be able to get in touch
with one that can handle its request.
Ideally, MPI can accommodate
a wide variety of run-time systems while
retaining the ability to write simple portable code. The following
should be compatible with MPI:
A port_name is a system-supplied string that encodes a
low-level network address at which a server can be
contacted. Typically this is an IP address and a port number, but an
implementation is free to use any protocol.
The server establishes a port_name with the
MPI_OPEN_PORT routine. It accepts a
connection to a given port with MPI_COMM_ACCEPT.
A client uses port_name to connect to the server.
By itself, the port_name mechanism is
completely portable, but it may be clumsy to use because
of the necessity to communicate port_name to
the client. It would be more convenient if a server could specify that
it be known by an application-supplied service_name so
that the client could connect to that service_name
without knowing the port_name.
An MPI implementation may allow the
server to publish a ( port_name, service_name)
pair with MPI_PUBLISH_NAME and the client
to retrieve the port name from the service name
with MPI_LOOKUP_NAME. This allows three levels
of portability, with increasing levels of functionality.
MPI does not require a nameserver, so not all implementations
will be able to support all of the above scenarios. However,
MPI provides an optional nameserver interface, and is compatible
with external name servers.
1. Applications that do not rely on the ability to publish
names are the most portable. Typically the port_name
must be transferred ``by hand'' from server to client.
2. Applications that use the MPI_PUBLISH_NAME
mechanism are completely portable among implementations
that provide this service. To be portable among all
implementations, these applications should have a fall-back mechanism
that can be used when names are not published.
3. Applications may ignore MPI's name publishing
functionality and use their own mechanism (possibly
system-supplied) to publish names. This allows arbitrary
flexibility but is not portable.
Up: Establishing Communication
Next: Server Routines
Previous: Establishing Communication
Return to MPI-2.1 Standard Index
Return to MPI Forum Home Page
MPI-2.0 of July 1, 2008
HTML Generated on July 6, 2008