NAME

udom − Unix domain IPC driver

DESCRIPTION

udom is a clonable STREAMS driver.  It implements the BSD UNIX domain IPC in that two processes not necessarily having a common ancestor can communicate.  Communicating parties refer to its peer by name or address.  In the BSD implementation, this name must be a path name within the file system name space.  This is not true in udom, where the name is not tied to the file system.  For instance, two processes can each open /dev/udom.  (they get different udom channels because of cloning).  One process binds the name fred to it.  Another process can then send data to the channel fred.

udom presents two abstractions for communication: “byte stream” or “datagram.” In the byte stream mode, a client creates an endpoint (via open(2)), connects to peer (via SOCK_CONNECT ioctl), and sends or receives data using read(2), write(2), send(2), or recv(2).  The server, similar to the situation in the Internet Domain, creates an endpoint, binds a well-known address (via SOCK_BIND ioctl), listens to it (via SOCK_LISTEN ioctl), and accepts connection (via SOCK_ACCEPT ioctl).  In the datagram mode, the communicating parties use sendto(2) and recvfrom(2) to transfer data.  Data sent to the udom driver is in the form of M_PROTO block followed by one or more M_DATA blocks.  The M_PROTO block encodes the address whose format is defined in <sys/un.h>. 

COMMAND FUNCTIONS

udom(7) recognizes the following ioctl commands. 

SOCK_BIND Bind the specified address to the local endpoint.  Error codes are:

[EINVAL] This endpoint has already been bound. 

[EINVAL] Address format is incorrect. 

[EADDRINUSE] Try to bind to an address which was used by another channel. 

SOCK_LISTEN Indicate the willingness to accept connection and set the limit for simultaneous pending connections.  Error codes are:

[EINVAL] The listening channel is not bound yet. 

SOCK_ACCEPT Accept a connection. 
This interface resembles the I_FDINSERT STREAMS ioctl.  An accepting scenario is as follow.  When the connection request comes in to the listening channel, The following structure encoded in the M_PROTO is sent upstream to indicate a connection request just arrives. 

typedef struct {
ulongoperation;/∗ SOCK_CONNIND here ∗/
ulongfildes;/∗ fd is accepted on ∗/
ulongseq;/∗ sequence number ∗/
intfamily;/∗ address family ∗/
union a { /∗ foreign address ∗/
struct sockaddr_in in;
struct sockaddr_un un;
} rem_addr;
} socketop_t;

Once the server decides to accept the connection, it first opens a new udom channel and puts the file descriptor in fildes. Then the server issues this ioctl (SOCK_ACCEPT), again using the argument socketop_t. The pending connection request is then associated with the new channel. A connection is now considered established.
If the SOCK_ACCEPT is done before any connection request, the ioctl is held and not acknowledged.  This effectively puts the caller to sleep (until the connection comes). 
Error codes are:

[EINVAL] The argument does not point to a correct socketop_t structure. 

[EINVAL] fildes is not a valid stream file descriptor or not associated with any udom(7) channel. 

SOCK_CONNECT Connect to another udom endpoint whose address is specified in the argument.  Error codes are:

[EINVAL] The address format is wrong. 

[EADDRNOTAVAIL] No channels have been bound to the address we want to connect. 

[ECONNREFUSED] The listening channel already has maximum number (default to 5) of pending connection requests. 

[ENOBUFS] Can not allocate internal resources used for the connection. 

SOCK_GETNAME Return the address of our own endpoint. 

SOCK_GETPEER Return the address of the peer endpoint which is connected to us. 

FILES

/dev/udom udom clone device

SEE ALSO

read(2), write(2), getmsg(2), putmsg(2), socket(2), bind(2), connect(2), send(2), sendto(2), recv(2), recvfrom(2), listen(2), accept(2), getsockname(2), getpeername(2)
streamio(7), clone(7), tcp(7)

September 02, 1992