This document describes how one can implement ones own carrier protocol for the erlang distibution. The distribution is normally carried by the TCP/IP protocol. Whats explained here is the method for replacing TCP/IP whith another protocol.
The document is a step by step explanation of the uds_dist
example
application (seated in the kernel applications examples
directory).
The uds_dist
application implements distribution over Unix domain
sockets and is written for the Sun Solaris 2 operating environment. The
mechanisms are however general and applies to any operating system erlang
runs on. The reason the C code is not made portable, is simply readability.
To implement a new carrier for the erlang distribution, one must first make the protocol available to the erlang machine, which involves writing an erlang driver. There is no way one can use a port program, there has to be an erlang driver. Erlang drivers can either be statically linked to the emulator, which can be an alternative when using the open source distribution of erlang, or dynamically loaded into the erlang machines address space, which is the only alternative if a precompiled version of erlang is to be used.
Writing an erlang driver is by no means easy. The driver is written as a couple of callback functions called by the erlang emulator when data is sent to the driver or the driver has any data available on a file descriptor. As the driver callback routines execute in the main thread of the erlang machine, the callback functions can perform no blocking activity whatsoever. The callbacks should only set up file descriptors for waiting and/or read/write available data. All I/O has to be non blocking. Driver callbacks are however executed in sequence, why a global state can safely be updated within the routines.
When the driver is implemented, one would preferrably write an
erlang interface for the driver to be able to test the
functionality of the driver separately. This interface can then
be used by the distribution module which will cover the details of
the protocol from the net_kernel
. The easiest path is to
mimic the inet
and gen_tcp
interfaces, but a lot of
functionality in those modules need not be implemented. In the
example application, only a few of the usual interfaces are
implemented, and they are much simplified.
When the protocol is available to erlang throug a driver and an
erlang interface module, a distribution module can be
written. The distribution module is a module with well defined
callbacks, much like a gen_server
(there is no compiler support
for checking the callbacks though). The details of finding other
nodes (i.e. talking to epmd or something similar), creating a
listen port (or similar), connecting to other nodes and performing
the handshakes/cookie verification are all implemented by this
module. There is however a utility module, dist_util
, that
will do most of the hard work of handling handshakes, cookies,
timers and ticking. Using dist_util
makes implementing a
distribution module much easier and that's what we are doing in
the example application.
The last step is to create boot scripts to make the protocol
implementation available at boot time. The implementation can be
debugged by starting the distribution when all of the system is
running, but in a real system the distribution should start very
early, why a bootscript and some command line parameters are
necessary. This last step also implies that the erlang code in the
interface and distribution modules is written in such a way that
it can be run in the startup phase. Most notably there can be no
calls to the application
module or to any modules not
loaded at boottime (i.e. only kernel
, stdlib
and the
application itself can be used).
Although erlang drivers in general may be beyond the scope of this document, a brief introduction seems to be in place.
An erlang driver is a native code module written in C (or
assembler) which serves as an interface for some special operating
system service. This is a general mechanism that is used
throughout the erlang emulator for all kinds of I/O. An erlang
driver can be dynamically linked (or loaded) to the erlang
emulator at runtime by using the erl_ddll
erlang
module. Some of the drivers in OTP are however statically linked
to the runtime system, but that's more an optimization than a
necessity.
The driver datatypes and the functions available to the driver
writer are defined in the header file erl_driver.h
(there
is also an deprecated version called driver.h
, dont use
that one.) seated in erlang's include directory (and in
$ERL_TOP/erts/emulator/beam in the source code
distribution). Refer to that file for function prototypes etc.
When writing a driver to make a communications protocol avalable to erlang, one should know just about everything worth knowing about that particular protocol. All operation has to be non blocking and all possible situations should be accounted for in the driver. A non stable driver will affect and/or crash the whole erlang runtime system, which is seldom what's wanted.
The emulator calls the driver in the following situations:
ErlDrvEntry
struct,
which should be properly filled in (see below).
open_port
call from erlang). This routine should set up internal data
structures and return an opaque data entity of the type
ErlDrvData
, which is a datatype large enough to hold a
pointer. The pointer returned by this function will be the first
argument to all other callbacks concerning this particular
port. It is usually called the port handle. The emulator only
stores the handle and doues never try to interpret it, why it can
be virtually anything (well anything not larger than a pointer
that is) and can point to anything if it is a pointer. Usually
this pointer will refer to a structure holding information about
the particular port, as i t does in our example.
driver_output
available to all
drivers). There is also a way to talk in a syncronous way to
drivers, described below. There can be an additional callback
function for handling data that is frgmented (sent in a deep
io-list). That interface will get the data in a form suitable for
Unix writev
rather than in a single buffer. There is no
need for a distribution driver to implement such a callback, so
we wont.
driver_select
. The mechanism of driver select makes it
possible to read non blocking from file descriptors by calling
driver_select
when reading is needed and then do the actual
reading in this callback (when reading is actually possible). The
typical scenario is that driver_select
is called when an
erlang process orderes a read operation, and that this routine
sends the answer when data is available on the file descriptor.
driver_select
. When the descriptor is readu for output,
this callback is called an the driver can try to send the
output. There may of course be queueing involved in such
operations, and there are some convenient queue routines available
to the driver writer to use in such situations.
driver_failure_XXX
routines. This
routine should clean up everything connected to one particular
port. Note that when other callbacks call a
driver_failure_XXX
routine, this routine will be
immediately called and the callback routine issuing the error can
make no more use of the data structures for the port, as this
routine surely has freed all associated data and closed all file
descriptors. If the queue utility available to driver writes is
used, this routine will however not be called until the
queue is empty.
erlang:driver_control/2
,
which is a syncronous interface to drivers. The control interface
is used to set driver options, change states of ports etc. We'll
use this interface quite a lot in our example.
driver_set_timer
. When such timers expire, a
specific callback function is called. We will not use timers in
our example.
The driver used for erlang distribution should implement a reliable, order mainataining, variable length packet oriented protocol. All error correction, resending and such need to be implemented in the driver or by the underlying communications protocol. If the protocol is stream oriented (as is the case with both TCP/IP and our streamed Unix domain sockets), some mechanism for packaging is needed. We will use the simple method of having a header of four bytes containing the length of the package in a big endian 32 bit integer (as Unix domain sockets only can be used between processes on the same machine, we actually dont need to code the integer in some special endianess, but i'll do it anyway brcause in most situation you do need to do it. Unix domain sockets are reliable and order maintaining, so we dont need to implement resends and such in our driver.
Lets start writing our example Unix domain sockets driver by declaring prototypes and filling in a static ErlDrvEntry structure.
( 1) #include <stdio.h> ( 2) #include <stdlib.h> ( 3) #include <string.h> ( 4) #include <unistd.h> ( 5) #include <errno.h> ( 6) #include <sys/types.h> ( 7) #include <sys/stat.h> ( 8) #include <sys/socket.h> ( 9) #include <sys/un.h> (10) #include <fcntl.h> (11) #define HAVE_UIO_H (12) #include "erl_driver.h" (13) /* (14) ** Interface routines (15) */ (16) static ErlDrvData uds_start(ErlDrvPort port, char *buff); (17) static void uds_stop(ErlDrvData handle); (18) static void uds_command(ErlDrvData handle, char *buff, int bufflen); (19) static void uds_input(ErlDrvData handle, ErlDrvEvent event); (20) static void uds_output(ErlDrvData handle, ErlDrvEvent event); (21) static void uds_finish(void); (22) static int uds_control(ErlDrvData handle, unsigned int command, (23) char* buf, int count, char** res, int res_size); (24) /* The driver entry */ (25) static ErlDrvEntry uds_driver_entry = { (26) NULL, /* init, N/A */ (27) uds_start, /* start, called when port is opened */ (28) uds_stop, /* stop, called when port is closed */ (29) uds_command, /* output, called when erlang has sent */ (30) uds_input, /* ready_input, called when input descriptor (31) ready */ (32) uds_output, /* ready_output, called when output (33) descriptor ready */ (34) "uds_drv", /* char *driver_name, the argument (35) to open_port */ (36) uds_finish, /* finish, called when unloaded */ (37) NULL, /* void * that is not used (BC) */ (38) uds_control, /* control, port_control callback */ (39) NULL, /* timeout, called on timeouts */ (40) NULL /* outputv, vector output interface */ (41) };
On line 1 to 10 we have included the OS headers needed for our
driver. As this driver is written for Solaris, we know that the
header uio.h
exists, why we can define the preprocessor
variable HAVE_UIO_H
before we include erl_driver.h
at line 12. The definition of HAVE_UIO_H
will make the
I/O vectors used in erlangs driver queues to correspond to the
operating systems dito, which is very convenient.
The different callback functions are declared ("forward declarations") on line 16 to 23.
The driver structure is similar for statically linked in
drivers an dynamically loaded. However some of the fields
should be left empty (i.e. initialized to NULL) in the
different types of drivers. The first field (the init
function pointer) is always left blank in a dynamically loaded
driver, which can be seen on line 26. The NULL on line 37
should always be there, the field is no longer used and is
retained for backward compatibility. We use no timers in this
driver, why no callback for timers is needed. The last field
(line 40) can be used to implement an interface similar to
Unix writev
for output. There is no need for such
interface in a distribution driver, so we leave it with a NULL
value (We will however use scatter/gather I/O internally in
the driver).
Our defined callbacks thus are:
erlang:port_control/2
callback, which
will be used a lot in this implementation.
The ports implemented by this driver will operate in two major modes, which i will call the command and data modes. In command mode, only passive reading and writing (like gen_tcp:recv/gen_tcp:send) can be done, and this is the mode the port will be in during the distribution handshake. When the connection is up, the port will be switched to data mode and all data will be immediately read and passed further to the erlang emulator. In data mode, no data arriving to the uds_command will be interpreted, but just packaged and sent out on the socket. The uds_control callback will do the switching between those two modes.
While the net_kernel
informs different subsystems that the
connection is coming up, the port should accept data to send, but
not receive any data, to avoid that data arrives from another node
before every kernel subsystem is prepared to handle it. We have a
third mode for this intermediate stage, lets call it the
intermediate mode.
Lets define an enum for the differnt types of ports we have:
( 1) typedef enum { ( 2) portTypeUnknown, /* An uninitialized port */ ( 3) portTypeListener, /* A listening port/socket */ ( 4) portTypeAcceptor, /* An intermidiate stage when accepting ( 5) on a listen port */ ( 6) portTypeConnector, /* An intermediate stage when connecting */ ( 7) portTypeCommand, /* A connected open port in command mode */ ( 8) portTypeIntermediate, /* A connected open port in special ( 9) half active mode */ (10) portTypeData /* A connectec open port in data mode */ (11) } PortType;
Lets look at the different types:
gen_tcp
socket.
Now lets look at the state we'll need for our ports. One can note that not all fields are used for all types of ports and that one could save some space by using unions, but that would clutter the code with multiple indirections, so i simply use one struct for all types of ports, for readability.
( 1) typedef unsigned char Byte; ( 2) typedef unsigned int Word; ( 3) typedef struct uds_data { ( 4) int fd; /* File descriptor */ ( 5) ErlDrvPort port; /* The port identifier */ ( 6) int lockfd; /* The file descriptor for a lock file in ( 7) case of listen sockets */ ( 8) Byte creation; /* The creation serial derived from the ( 9) lockfile */ (10) PortType type; /* Type of port */ (11) char *name; /* Short name of socket for unlink */ (12) Word sent; /* Bytes sent */ (13) Word received; /* Bytes received */ (14) struct uds_data *partner; /* The partner in an accept/listen pair */ (15) struct uds_data *next; /* Next structure in list */ (16) /* The input buffer and it's data */ (17) int buffer_size; /* The allocated size of the input buffer */ (18) int buffer_pos; /* Current position in input buffer */ (19) int header_pos; /* Where the current header is in the (20) input buffer */ (21) Byte *buffer; /* The actual input buffer */ (22) } UdsData;
This structure is used for all types of ports although some fields are useless for some types. The least memory consuming solution would be to arrange this structure as a union of structures, but the multiple indirections in the code to access a field in such a structure will clutter the code to much for an example.
Let's look at the fields in our structure:
driver_XXX
calls from the driver back to the emulator.
epmd
), which is contacted when a distributed
node starts. The lockfile and a convention for the UDS
listen socket's name will remove the need for
epmd
when using this distribution module. UDS
is always restricted to one host, why avoiding a port
mapper is easy.
unlink
) when the
socket is closed.
sent
.
The distribution drivers implementation is not completely covered in this text, details about buffering and other things unrelated to driver writing are not explained. Likewise are some peculiarities of the UDS protocol not explained in detail. The chosen protocol is not important.
Prototypes for the driver callback routines can be found in
the erl_driver.h
header file.
The driver initialization routine is (usually) declared with a
macro to make the driver easier to port between different
operating systems (and flavours of systems). This is the only
routine that has to have a well defined name. All other
callbacks are reached through the driver structure. The macro
to use is named DRIVER_INIT
and takes the driver name
as parameter.
(1) /* Beginning of linked list of ports */ (2) static UdsData *first_data; (3) DRIVER_INIT(uds_drv) (4) { (5) first_data = NULL; (6) return &uds_driver_entry; (7) }
The routine initializes the single global data structure and
returns a pointer to the driver entry. The routine will be
called when erl_ddll:load_driver
is called from erlang.
The uds_start
routine is called when a port is opened
from erlang. In our case, we only allocate a structure and
initialize it. Creating the actual socket is left to the
uds_command
routine.
( 1) static ErlDrvData uds_start(ErlDrvPort port, char *buff) ( 2) { ( 3) UdsData *ud; ( 4) ( 5) ud = ALLOC(sizeof(UdsData)); ( 6) ud->fd = -1; ( 7) ud->lockfd = -1; ( 8) ud->creation = 0; ( 9) ud->port = port; (10) ud->type = portTypeUnknown; (11) ud->name = NULL; (12) ud->buffer_size = 0; (13) ud->buffer_pos = 0; (14) ud->header_pos = 0; (15) ud->buffer = NULL; (16) ud->sent = 0; (17) ud->received = 0; (18) ud->partner = NULL; (19) ud->next = first_data; (20) first_data = ud; (21) (22) return((ErlDrvData) ud); (23) }
Every data item is initialized, so that no problems will arise
when a newly created port is closed (without there being any
corresponding socket). This routine is called when
open_port({spawn, "uds_drv"},[])
is called from erlang.
The uds_command
routine is the routine called when an
erlang process sends data to the port. All asyncronous
commands when the port is in command mode as well as
the sending of all data when the port is in data mode
is handeled in thi9s routine. Let's have a look at it:
( 1) static void uds_command(ErlDrvData handle, char *buff, int bufflen) ( 2) { ( 3) UdsData *ud = (UdsData *) handle; ( 4) if (ud->type == portTypeData || ud->type == portTypeIntermediate) { ( 5) DEBUGF(("Passive do_send %d",bufflen)); ( 6) do_send(ud, buff + 1, bufflen - 1); /* XXX */ ( 7) return; ( 8) } ( 9) if (bufflen == 0) { (10) return; (11) } (12) switch (*buff) { (13) case 'L': (14) if (ud->type != portTypeUnknown) { (15) driver_failure_posix(ud->port, ENOTSUP); (16) return; (17) } (18) uds_command_listen(ud,buff,bufflen); (19) return; (20) case 'A': (21) if (ud->type != portTypeUnknown) { (22) driver_failure_posix(ud->port, ENOTSUP); (23) return; (24) } (25) uds_command_accept(ud,buff,bufflen); (26) return; (27) case 'C': (28) if (ud->type != portTypeUnknown) { (29) driver_failure_posix(ud->port, ENOTSUP); (30) return; (31) } (32) uds_command_connect(ud,buff,bufflen); (33) return; (34) case 'S': (35) if (ud->type != portTypeCommand) { (36) driver_failure_posix(ud->port, ENOTSUP); (37) return; (38) } (39) do_send(ud, buff + 1, bufflen - 1); (40) return; (41) case 'R': (42) if (ud->type != portTypeCommand) { (43) driver_failure_posix(ud->port, ENOTSUP); (44) return; (45) } (46) do_recv(ud); (47) return; (48) default: (49) return; (50) } (51) }
The command routine takes three parameters; the handle
returned for the port by uds_start
, which is a pointer
to the internal port structure, the data buffer and the length
of the data buffer. The buffer is the data sent from erlang
(a list of bytes) converted to an C array (of bytes).
If Erlang sends i.e. the list [$a,$b,$c]
to the port,
the bufflen
variable will be 3
ant the
buff
veriable will contain {'a','b','c'}
(no
null termination). Usually the first byte is used as an
opcode, which is the case in our driver to (at least when the
port is in command mode). The opcodes are defined as:
One may wonder what is meant by "one packet of data" in the 'R' command. This driver always sends data packeted with a 4 byte header containing a big endian 32 bit integer that represents the length of the data in the packet. There is no need for different packet sizes or soime kind of streamed mode, as this driver is for the distribuion only. One may wonder why the header word is coded explicitly in big endian when an UDS socket is local to the host. The answer simply is that I see it as a good practice when writing a distribution driver, as distribution in practice usually cross the host boundaries.
On line 4-8 we handle the case where the port is in data or
intermediate mode, the rest of the routine handles the
different commands. We see (first on line 15) that the routine
uses the driver_failure_posix()
routine to report
errors. One important thing to remember is that the failure
routines make a call to our uds_stop
routine, which
will remove the internal port data. The handle (and the casted
handle ud
) is therefore invalid pointers after a
driver_failure
call and we should immediately
return. The runtime system will send exit signals to all
linked processes.
The uds_input routine gets called when data is available on a
file descriptor previously passed to the driver_select
routine. Typically this happens when a read command is issued
and no data is available. Lets look at the do_recv
routine:
( 1) static void do_recv(UdsData *ud) ( 2) { ( 3) int res; ( 4) char *ibuf; ( 5) for(;;) { ( 6) if ((res = buffered_read_package(ud,&ibuf)) < 0) { ( 7) if (res == NORMAL_READ_FAILURE) { ( 8) driver_select(ud->port, (ErlDrvEvent) ud->fd, DO_READ, 1); ( 9) } else { (10) driver_failure_eof(ud->port); (11) } (12) return; (13) } (14) /* Got a package */ (15) if (ud->type == portTypeCommand) { (16) ibuf[-1] = 'R'; /* There is always room for a single byte (17) opcode before the actual buffer (18) (where the packet header was) */ (19) driver_output(ud->port,ibuf - 1, res + 1); (20) driver_select(ud->port, (ErlDrvEvent) ud->fd, DO_READ,0); (21) return; (22) } else { (23) ibuf[-1] = DIST_MAGIC_RECV_TAG; /* XXX */ (24) driver_output(ud->port,ibuf - 1, res + 1); (25) driver_select(ud->port, (ErlDrvEvent) ud->fd, DO_READ,1); (26) } (27) } (28) }
The routine tries to read data until a packet is read or the
buffered_read_package
routine returns a
NORMAL_READ_FAILURE
(an internally defined constant for
the module that means that the read operation resulted in an
EWOULDBLOCK
). If the port is in command mode, the
reading stops when one package is read, but if it is in data
mode, the reading continues until the socket buffer is empty
(read failure). If no more data can be read and more is wanted
(always the case when socket is in data mode) driver_select is
called to make the uds_input
callback be called when
more data is available for reading.
When the port is in data mode, all data is sent to erlang in a
format that suits the distribution, in fact the raw data will
never reach any erlang process, but will be
translated/interpreted by the emulator itself and then
delivered in the correct format to the correct processes. In
the current emulator version, received data should be tagged
with a single byte of 100. Thats what the macro
DIST_MAGIC_RECV_TAG
is defined to. The tagging of data
in the distribution will possibly change in the future.
The uds_input
routine will handle other input events
(like nonblocking accept
), but most importantly handle
data arriving at the socket by calling do_recv
:
( 1) static void uds_input(ErlDrvData handle, ErlDrvEvent event) ( 2) { ( 3) UdsData *ud = (UdsData *) handle; ( 4) if (ud->type == portTypeListener) { ( 5) UdsData *ad = ud->partner; ( 6) struct sockaddr_un peer; ( 7) int pl = sizeof(struct sockaddr_un); ( 8) int fd; ( 9) if ((fd = accept(ud->fd, (struct sockaddr *) &peer, &pl)) < 0) { (10) if (errno != EWOULDBLOCK) { (11) driver_failure_posix(ud->port, errno); (12) return; (13) } (14) return; (15) } (16) SET_NONBLOCKING(fd); (17) ad->fd = fd; (18) ad->partner = NULL; (19) ad->type = portTypeCommand; (20) ud->partner = NULL; (21) driver_select(ud->port, (ErlDrvEvent) ud->fd, DO_READ, 0); (22) driver_output(ad->port, "Aok",3); (23) return; (24) } (25) do_recv(ud); (26) }
The important line here is the last line in the function, the
do_read
routine is called to handle new input. The rest
of the function handles input on a listen socket, whinc means
that there should be possible to do an accept on the
socket, which is also recognized as a read event.
The output mechanisms are similar to the input. Lets first
look at the do_send
routine:
( 1) static void do_send(UdsData *ud, char *buff, int bufflen) ( 2) { ( 3) char header[4]; ( 4) int written; ( 5) SysIOVec iov[2]; ( 6) ErlIOVec eio; ( 7) ErlDrvBinary *binv[] = {NULL,NULL}; ( 8) put_packet_length(header, bufflen); ( 9) iov[0].iov_base = (char *) header; (10) iov[0].iov_len = 4; (11) iov[1].iov_base = buff; (12) iov[1].iov_len = bufflen; (13) eio.iov = iov; (14) eio.binv = binv; (15) eio.vsize = 2; (16) eio.size = bufflen + 4; (17) written = 0; (18) if (driver_sizeq(ud->port) == 0) { (19) if ((written = writev(ud->fd, iov, 2)) == eio.size) { (20) ud->sent += written; (21) if (ud->type == portTypeCommand) { (22) driver_output(ud->port, "Sok", 3); (23) } (24) return; (25) } else if (written < 0) { (26) if (errno != EWOULDBLOCK) { (27) driver_failure_eof(ud->port); (28) return; (29) } else { (30) written = 0; (31) } (32) } else { (33) ud->sent += written; (34) } (35) /* Enqueue remaining */ (36) } (37) driver_enqv(ud->port, &eio, written); (38) send_out_queue(ud); (39) }
This driver uses the writev
system call to send data
onto the socket. A combination of writev and the driver output
queues is very convenient. An ErlIOVec structure
contains a SysIOVec (which is equivalent to the
struct iovec
structure defined in uio.h
. The
ErlIOVec also contains an array of ErlDrvBinary
pointers, of the same length as the number of buffers in the
I/O vector itself. One can use this to allocate the binaries
for the queue "manually" in the driver, but we'll just fill
the binary array with NULL values (line 7) , which will make
the runtime system allocate it's own buffers when we call
driver_enqv
(line 37).
The routine builds an I/O vector containing the header bytes
and the buffer (the opcode has been removed and the buffer
length decreased by the output routine). If the queue is
empty, we'll write the data directly to the socket (or at
least try to). If any data is left, it is stored in the que
and then we try to send the queue (line 38). An ack is sent
when the message is delivered completely (line 22). The
send_out_queue
will send acks if the sending is
completed there. If the port is in command mode, the erlang
code serializes the send operations so that only one packet
can be waiting for delivery at a time. Therefore the ack can
be sent simply whenever the queue is empty.
A short look at the send_out_queue
routine:
( 1) static int send_out_queue(UdsData *ud) ( 2) { ( 3) for(;;) { ( 4) int vlen; ( 5) SysIOVec *tmp = driver_peekq(ud->port, &vlen); ( 6) int wrote; ( 7) if (tmp == NULL) { ( 8) driver_select(ud->port, (ErlDrvEvent) ud->fd, DO_WRITE, 0); ( 9) if (ud->type == portTypeCommand) { (10) driver_output(ud->port, "Sok", 3); (11) } (12) return 0; (13) } (14) if (vlen > IO_VECTOR_MAX) { (15) vlen = IO_VECTOR_MAX; (16) } (17) if ((wrote = writev(ud->fd, tmp, vlen)) < 0) { (18) if (errno == EWOULDBLOCK) { (19) driver_select(ud->port, (ErlDrvEvent) ud->fd, (20) DO_WRITE, 1); (21) return 0; (22) } else { (23) driver_failure_eof(ud->port); (24) return -1; (25) } (26) } (27) driver_deq(ud->port, wrote); (28) ud->sent += wrote; (29) } (30) }
What we do is simply to pick out an I/O vector from the queue
(which is the whole queue as an SysIOVec). If the I/O
vector is to long (IO_VECTOR_MAX is defined to 16), the vector
length is decreased (line 15), otherwise the writev
(line 17) call will
fail. Writing is tried and anything written is dequeued (line
27). If the write fails with EWOULDBLOCK
(note that all
sockets are in nonblocking mode), driver_select
is
called to make the uds_output
routine be called when
there is space to write again.
We will continue trying to write until the queue is empty or the writing would block.
The routine above are called from the uds_output
routine, which looks like this:
( 1) static void uds_output(ErlDrvData handle, ErlDrvEvent event) ( 2) { ( 3) UdsData *ud = (UdsData *) handle; ( 4) if (ud->type == portTypeConnector) { ( 5) ud->type = portTypeCommand; ( 6) driver_select(ud->port, (ErlDrvEvent) ud->fd, DO_WRITE, 0); ( 7) driver_output(ud->port, "Cok",3); ( 8) return; ( 9) } (10) send_out_queue(ud); (11) }
The routine is simple, it first handles the fact that the output select will concern a socket in the buissiness of connectiong (and the connecting blocked). If the socket is in a connected state it simply sends the output queue, this routine is called when there is possible to write to a socket where we have an output queue, so there is no question what to do.
The driver implements a control interface, which is a
syncronous interface called when erlang calls
erlang:driver_control/3
. This is the only interface
that can control the driver when it is in data mode and it may
be called with the following opcodes:
The control interface gets a buffer to return its value in,
but is free to allocate it's own buffer is the provided one is
to small. Here is the code for uds_control
:
( 1) static int uds_control(ErlDrvData handle, unsigned int command, ( 2) char* buf, int count, char** res, int res_size) ( 3) { ( 4) /* Local macro to ensure large enough buffer. */ ( 5) #define ENSURE(N) \ ( 6) do { \ ( 7) if (res_size < N) { \ ( 8) *res = ALLOC(N); \ ( 9) } \ (10) } while(0) (11) UdsData *ud = (UdsData *) handle; (12) switch (command) { (13) case 'S': (14) { (15) ENSURE(13); (16) **res = 0; (17) put_packet_length((*res) + 1, ud->received); (18) put_packet_length((*res) + 5, ud->sent); (19) put_packet_length((*res) + 9, driver_sizeq(ud->port)); (20) return 13; (21) } (22) case 'C': (23) if (ud->type < portTypeCommand) { (24) return report_control_error(res, res_size, "einval"); (25) } (26) ud->type = portTypeCommand; (27) driver_select(ud->port, (ErlDrvEvent) ud->fd, DO_READ, 0); (28) ENSURE(1); (29) **res = 0; (30) return 1; (31) case 'I': (32) if (ud->type < portTypeCommand) { (33) return report_control_error(res, res_size, "einval"); (34) } (35) ud->type = portTypeIntermediate; (36) driver_select(ud->port, (ErlDrvEvent) ud->fd, DO_READ, 0); (37) ENSURE(1); (38) **res = 0; (39) return 1; (40) case 'D': (41) if (ud->type < portTypeCommand) { (42) return report_control_error(res, res_size, "einval"); (43) } (44) ud->type = portTypeData; (45) do_recv(ud); (46) ENSURE(1); (47) **res = 0; (48) return 1; (49) case 'N': (50) if (ud->type != portTypeListener) { (51) return report_control_error(res, res_size, "einval"); (52) } (53) ENSURE(5); (54) (*res)[0] = 0; (55) put_packet_length((*res) + 1, ud->fd); (56) return 5; (57) case 'T': /* tick */ (58) if (ud->type != portTypeData) { (59) return report_control_error(res, res_size, "einval"); (60) } (61) do_send(ud,"",0); (62) ENSURE(1); (63) **res = 0; (64) return 1; (65) case 'R': (66) if (ud->type != portTypeListener) { (67) return report_control_error(res, res_size, "einval"); (68) } (69) ENSURE(2); (70) (*res)[0] = 0; (71) (*res)[1] = ud->creation; (72) return 2; (73) default: (74) return report_control_error(res, res_size, "einval"); (75) } (76) #undef ENSURE (77) }
The macro ENSURE
(line 5 to 10) is used to ensure that
the buffer is large enough for our answer. We switch on the
command and take actions, there is not much to say about this
routine. Worth noting is that we always has read select active
on a port in data mode (achieved by calling do_recv
on
lin 45), but turn off read selection in intermediate and
command modes (line 27 and 36).
The rest of the driver is more or less UDS specific and not of general interest.
To test the distribution, one can use the
net_kernel:start/1
function, which is useful as it starts
the distribution on a running system, where tracing/debugging
can be performed. The net_kernel:start/1
routine takes a
list as it's single argument. The lists first element should be
the node name (without the "@hostname") as an atom, and the second (and
last) element should be one of the atoms shortnames
or
longnames
. In the example case shortnames
is
preferred.
For net kernel to find out which distribution module to use, the
command line argument -proto_dist
is used. The argument
is followed bu one or more distribution module names, with the
"_dist" suffix removed, i.e. uds_dist as a distribution module
is specified as -proto_dist uds
.
If no epmd (TCP port mapper daemon) is used, one should also
specify the command line option -no_epmd
, which will make
erlang skip the epmd startup, both as a OS process and as an
erlang dito.
The path to the directory where the distribution modules reside
must be known at boot, which can either be achieved by
specifying -pa <path>
on the command line or by building
a boot script containing the applications used for your
distribution protocol (in the uds_dist protocol, it's only the
uds_dist application that needs to be added to the script).
The distribution will be started at boot if all the above is
specified and an -sname <name>
flag is present at the
command line, here follows two examples:
$ erl -pa $ERL_TOP/lib/kernel/examples/uds_dist/ebin -proto_dist uds -no_epmd Erlang (BEAM) emulator version 5.0 Eshell V5.0 (abort with ^G) 1> net_kernel:start([bing,shortnames]). {ok,<0.30.0>} (bing@hador)2>
...
$ erl -pa $ERL_TOP/lib/kernel/examples/uds_dist/ebin -proto_dist uds \ -no_epmd -sname bong Erlang (BEAM) emulator version 5.0 Eshell V5.0 (abort with ^G) (bong@hador)1>
One can utilize the ERL_FLAGS environment variable to store the complicated parameters in:
$ ERL_FLAGS=-pa $ERL_TOP/lib/kernel/examples/uds_dist/ebin \ -proto_dist uds -no_epmd $ export ERL_FLAGS $ erl -sname bang Erlang (BEAM) emulator version 5.0 Eshell V5.0 (abort with ^G) (bang@hador)1>
The ERL_FLAGS
shuld preferrably not include the name of
the node.