On its lowest level, MP communicates data as unsigned 32 bit integers in a 2'complement binary representation. However, already on this lowest level, one has to make an encoding choice: Should integers be communicated in Big Endian encoding (also called network byte order) or in Little Endian encoding? Fixing the ``endianness'' (say, to network byte order as XDR does) supports generality, but introduces unnecessary computational overhead if the two communicating parties are Little Endian.
Similar problems occur for the communication of fixed precision floating point numbers (possible encoding: IEEE, Cray, VAX, etc.), and arbitrary precision integers (GnuMP, PARI, SacLIB, BigNum, etc.) and floating point numbers (GnuMP, PARI): again, restricting the communication to one format supports generality, but significantly and unnecessarily decreases efficiency if both sides use the same non-MP format.
The solution we propose is based on a restricted form of format negotiation. The main idea is the following: At link creation time, a MP application writes a record to the link, which, for each of the critical basic data types, specifies a list of encodings which the particular application can handle, with a score in the range of 0 to 255 reflecting the efficiency with which an encoding can be handled - the native encoding is typically assigned the highest score. Furthermore, a record of the same type is read from the link containing the peer's preferences. Based on these two records, the encoding of each of the basic data types is independently and uniquely determined based on the following rule:
Choose the encoding whose sum of the scores of both records is maximal. In case of a tie, use a statically defined order as tie-breaker.Furthermore, each list must contain at least the MP-defined default member, which guarantees that it is always possible to find at least one ``common'' encoding for communication. In addition, if such an exchange of format-specifying records is impossible for a particular type of MP link (e.g., for a write-only link to a file) then the default encoding is used.
Table 3 shows the currently supported encodings of numeric MP types. We might add that these particular encodings were motivated by our practical needs and could easily be extended to include other encodings.
While the ``negotiation'' scheme outlined above might seem complex at first sight, it is totally hidden from the user of the MP API. For each application, the list of the possible encoding formats together with their respective scores are determined at compile time of the MP library. The determination of the encoding takes place without the user realizing it when a MP link is opened.