erl_ext_dist.txt

OTP是开放电信平台的简称

``The contents of this file are subject to the Erlang Public License,
Version 1.1, (the "License"); you may not use this file except in
compliance with the License. You should have received a copy of the
Erlang Public License along with this software. If not, it can be
retrieved via the world wide web at http://www.erlang.org/.

Software distributed under the License is distributed on an "AS IS"
basis, WITHOUT WARRANTY OF ANY KIND, either express or implied. See
the License for the specific language governing rights and limitations
under the License.

The Initial Developer of the Original Code is Ericsson Utvecklings AB.
Portions created by Ericsson are Copyright 1999, Ericsson Utvecklings
AB. All Rights Reserved.''

    $Id$


ERLANGS EXTERNAL FORMAT and distribution protocol
-------------------------------------------------

1.  INTRODUCTION

The external format is mainly used in the distribution mechanism of
erlang.

Since erlang has a fixed number of types, there is no need for a programmer
to define a specification for the external format used within some application.
All Erlang terms has an external representation and the interpretation of
the different terms are application specific.

In erlang the BIF term_to_binary/1,2 is used to convert a term into
the external format. To convert binary data encoding a term the BIF
binary_to_term/1 is used.

The distribution does this implicitly when sending messages across node
boundaries.

The distribution protocol is described in the chapters EPMD protocol
and Node to Node protocol.

2.  TERM ENCODING

2.1. VERSION_MAGIC (131)

The overall format of the term format is:

  1      1       N
+-----+-----+-------------+
| 131 | Tag |   Data      |
+-----+-----+-------------+

2.2. SMALL_INTEGER_EXT (97)

  1    1
+----+-----+
| 97 | Int |
+----+-----+

unsigned 8 bit integer.

2.3. INTEGER_EXT       (98)

  1       4
+----+-----------+
| 98 |   Int     |
+----+-----------+

signed 32 bit integer in big endian format (i.e MSB first)

2.4. FLOAT_EXT         (99)

  1         31
+----+----------------+
| 99 |   Float String |
+----+----------------+

A float is stored in string format. the format used in sprintf to
format the float is "%.20e"  (there are more bytes allocated than neccessary).
To unpack the float use sscanf with format "%lf".

This term is used in minor version 0 of the external format; it has been
superseded by 2.24.

2.5. ATOM_EXT          (100)

  1       2        Len
+-----+-------+-----------+
| 100 | Len   | Atom name |
+-----+-------+-----------+

An atom is stored with a 2 byte unsigned length in big endian order, followed
Len numbers of 8 bit characters that forms the atom name.
The Len MUST be limitied to 255, which means that the Len field may be
reduced to 1 byte.

2.6. REFERENCE_EXT     (101)

  1       N            4           1
+-----+-----------+-----------+----------+
| 101 |    Node   |     ID    | Creation |
+-----+-----------+-----------+----------+

Encode a reference object i.e an object generated with make_ref/0.
The Node Term is an encoded atom, i.e. ATOM_EXT, NEW_CACHE (see 2.17.) or
CACHED_ATOM (see 2.18.). The ID field contains an big endian unsigned integer,
but SHOULD be reguarded as uninterpreted data since this field is node 
specific. Creation is a byte containing a node serial number that
makes it possible to separate old (crashed) nodes from a new one.

In ID, only 18 bits are significant; the rest should be 0.
In Creation, only 2 bits are significant; the rest should be 0.

See 2.19 (NEW_REFERENCE_EXT).

2.7. PORT_EXT          (102)

  1       N            4           1
+-----+-----------+-----------+----------+
| 102 |    Node   |    ID     | Creation |
+-----+-----------+-----------+----------+

Encode a port object ( open_port/2 ).
The ID is a node specific identifier for a local port. The distribution
in 4.4 does not support port operations across node boundaries.
The Creation works just like in REFERENCE_EXT

2.8. PID_EXT           (103)

  1       N            4            4           1
+-----+-----------+-----------+-----------+----------+
| 103 |    Node   |    ID     |  Serial   | Creation |
+-----+-----------+-----------+-----------+----------+

Encode a process object ( spawn/3 ).
The ID and Creation fields works just like in REFERENCE_EXT, while
the Serial field is used to improve safety.

In ID, only 15 bits are significant; the rest should be 0.

2.9. SMALL_TUPLE_EXT   (104)

  1       1        N
+-----+-------+--------------+
| 104 | Arity |    Elements  |
+-----+-------+--------------+

The x_TUPLE_EXT encodes a tuple. The Arity is an unsigned byte that
determines how many element that follows in the Elements section.

2.10. LARGE_TUPLE_EXT   (105)

  1       4        N
+-----+-------+--------------+
| 105 | Arity |    Elements  |
+-----+-------+--------------+

See SMALL_TUPLE_EXT with the exception that Arity is an unsigned 4 byte integer
in big endian format.

2.11. NIL_EXT           (106)

   1
+-----+
| 106 |
+-----+

The represenation for [].


2.12. STRING_EXT        (107)

   1     2        Len
+-----+-----+-----------------+
| 107 | Len |  Characters     |
+-----+-----+-----------------+

String does NOT have a corresponding erlang representation. But from
Erlang 4.4, lists of bytes (i.e integer in range 0..255) are displayed as
string. Since the length field is a unsigned 2 byte integer (big endian)
implementations must make sure that lists longer than 65535 elements are
encoded with the LIST_EXT (2.13.).


2.13. LIST_EXT          (108)

   1      4             
+-----+--------+---------------------+
| 108 |   n    | Elem(1) ... Elem(n) |
+-----+--------+---------------------+

Lists are stored in the same way as the LARGE_TUPLE_EXT. There is NO
short form, i.e. there is no SMALL_LIST_EXT.

2.14. BINARY_EXT        (109)

   1      4           Len
+-----+-------+---------------------+
| 109 |  Len  |      Data           |
+-----+-------+---------------------+

Binaries are generated with list_to_binary/1, term_to_binary/1 or
as input from binary ports. The Len length field is an unsigned 4 byte integer
(big endian).

2.15. SMALL_BIG_EXT     (110)

   1      1      1        n
+-----+-------+------+------------------+
| 110 |   n   | Sign |  d(0) ... d(n-1) |
+-----+-------+------+------------------+

Bignums are stored in unary form with a sign byte that is 0
if unsigned and 1 if signed. The digits are stored with the
LSB byte first. i.e d0 is stored first and to calculate the integer
the following formula may come in handy.

   where B = 256
   (-1)^Sign * (d0*B^0 + d1*B^1 + d2*B^2 + ... d(N-1)*B^(n-1))

2.16. LARGE_BIG_EXT     (111)

   1      4      1         n
+-----+-------+------+------------------+
| 111 |   n   | Sign |  d(0) ... d(n-1) |
+-----+-------+------+------------------+

See SMALL_BIG_EXT with the difference that the length field is an unsigned
4 byte integer.

2.17 NEW_CACHE         (78)

  1       1       2         Len
+----+-------+--------+-----------+
| 78 | index |  Len   | Atom name |
+----+-------+--------+-----------+

NEW_CACHE works just like ATOM_EXT, but it must also cache the atom 
in the atom cache in the location given by index.

2.18. CACHED_ATOM       (67)

   1      1
+----+-------+
| 67 | index |
+----+-------+

When the atom cache is in use, index is the slot number in which
the atom MUST be located.

2.19. NEW_REFERENCE_EXT		(114)

  1      2       N            1           N'
+-----+-----+-----------+-----------+-----------+
| 114 | Len |    Node   | Creation  |   ID  ... |
+-----+-----+-----------+-----------+-----------+

Node and Creation are as in REFERENCE_EXT.

ID contains a sequence of big-endian unsigned integers (4 bytes each, so
N' is a multiple of 4), but should be regarded as uninterpreted data.

N' = 4*Len.

In the first word (four bytes) of ID, only 18 bits are significant;
the rest should be 0.
In Creation, only 2 bits are significant; the rest should be 0.

NEW_REFERENCE_EXT was introduced with distribution version 4.
In version 4, N' should be at most 12.

See 2.7 (REFERENCE_EXT).

2.20. FUN_EXT		(117)

  1      4    N1      N2      N3      N4      4*Len
+-----+-----+-----+--------+-------+------+--------------+
| 117 | Len | Pid | Module | Index | Uniq | Free vars... |
+-----+-----+-----+--------+-------+------+--------------+

Pid is process identifier as in PID_EXT. It represents the process in which
the fun was created.

Module is an encoded as an atom, using ATOM_EXT, NEW_CACHE (2.17) or
CACHED_ATOM (2.18). This is the module that the fun is implemented in.

Index is an integer encoded using SMALL_INTEGER_EXT (2.2) or INTEGER_EXT (2.3).
It is typically a small index into the module's fun table.

Uniq is an integer encoded using SMALL_INTEGER_EXT (2.2) or INTEGER_EXT (2.3).
Uniq is the hash value of the parse for the fun.

Free vars is Len number of terms, each one encoded according to its type.

2.21. NEW_FUN_EXT	(112)

  1      4      1      16      4
+-----+-----+-------+------+-------+
| 112 | Len | Arity | Uniq | Index |
+-----+-----+-------+------+-------+

     4        N1       N2        N3       N4      N5
+---------+--------+----------+---------+-----+--------------+
| NumFree | Module | OldIndex | OldUniq | Pid | Free vars... |
+---------+--------+----------+---------+-----+--------------+

Arity is the arity of the function implementing the fun.

Uniq is the 16 bytes MD5 of the significant parts of the Beam file.

Index is an index number. Each fun within a module has an unique
index. Index is stored in big-endian byte order.

Pid is process identifier as in PID_EXT. It represents the process in which
the fun was created.

Module is an encoded as an atom, using ATOM_EXT, NEW_CACHE (2.17) or
CACHED_ATOM (2.18). This is the module that the fun is implemented in.

Uniq is an integer encoded using SMALL_INTEGER_EXT (2.2) or INTEGER_EXT (2.3).
Uniq is the hash value of the parse for the fun.

OldIndex is an integer encoded using SMALL_INTEGER_EXT (2.2) or INTEGER_EXT (2.3).
It is typically a small index into the module's fun table.

Free vars is Len number of terms, each one encoded according to its type.


2.22. EXPORT_EXT	(113)

  1      N1        N2        N3
+-----+--------+----------+-------+
| 113 | Module | Function | Arity |
+-----+--------+----------+-------+

This term is the encoding for external funs: fun M:F/A.

Module and Function are atoms (encoded using ATOM_EXT, NEW_CACHE or CACHED_ATOM).

Arity is an integer encoded using SMALL_INTEGER_EXT.


2.23 BIT_BINARY_EXT	(77)

   1      4      1      Len
+-----+-------+------+----------------+
|  77 |  Len  | Bits | Data           |
+-----+-------+------+----------------+

This term represents a binary whose length is in bits is not a multiple
of 8. The Len field is an unsigned 4 byte integer (big endian).
The Bits field is the number of bits that are used in the last byte in
the data field, counting from the most significant bit towards the least
significant.


2.24. FLOAT_EXT         (70)

  1         8
+----+-----------+
| 70 |IEEE float |
+----+-----------+

A float is stored as 8 bytes in big-endian IEEE format.

This term is used in minor version 1 of the external format.

3. EPMD protocol

The protocol that EPMD (Erlang Port Mapper Daemon) talks is summarized here.

	Client (or Node)                  EPMD
        ----------------                  ----------

	ALIVE_REQ       ---------------->

	                <---------------- ALIVE_OK_RESP

	                <---------------- ALIVE_NOTOK_RESP

	ALIVE2_REQ      ---------------->

	                <---------------- ALIVE2_RESP

	ALIVE_CLOSE_REQ ---------------->

	PORT_PLEASE_REQ ---------------->

	                <---------------- PORT_OK_RESP

	                <---------------- PORT_NOTOK_RESP

	PORT_PLEASE2_REQ --------------->