Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

dk(3) [plan9 man page]

DK(3)							     Library Functions Manual							     DK(3)

NAME

       dk - Datakit conversations

SYNOPSIS

       bind #kname /net/dk
       bind #iname /net/dk

       ctlfd = open(".../ctl", ORDWR);
       write(ctlfd, "push dkmux", 10);
       write(ctlfd, "config csc [no]restart name nvc window", n);

DESCRIPTION

       A  Datakit  device--either  k  for the regular Datakit or i for the Incon--is a directory containing up to 256 directories, one per virtual
       circuit, named 0 through 255, and a special file named clone.  The specifier name matches the Datakit device to a physical device that  its
       virtual circuits are multiplexed over (see dkmux below).

       Normally,  the  standard routines dial, hangup, listen, and announce (see dial(2)) are used to make, listen for, and control calls over any
       network.  The routines expect the following properties of any multiplexed network, not just Datakit.

       Opening the clone file opens the ctl file of an unused virtual circuit.	Reading any ctl file returns  the  name  of  the  virtual  circuit
       directory.  For example, reading #k/17/ctl will return the string 17.

       Each virtual circuit directory contains the files:

       ctl	 to control the virtual circuit: establish a connection, hang it up, etc.

       data	 to converse with the remote end (via read and write)

       listen	 to listen for calls (after announcing; see below)

       other	 information about the conversation

       raddr	 the address of the remote end

       ruser	 the id of the user at the remote end (when applicable)

       To set up and tear down virtual circuits a process writes textual commands to the ctl file:

       connect addr	 connect to address addr.  If the connection fails, the write returns an error.

       hangup		 tear down a connected virtual circuit.

       announce name	 announce the readiness to accept calls to name.

       accept n 	 accept the call on virtual circuit n.

       reject n e	 reject the call on virtual circuit n with error code e.  E must be a number from 0 to 7.

       Once  a	virtual  circuit is set up, a process can converse with the remote service by reading and writing the data file.  Write boundaries
       are preserved.

       Accepting calls to name requires the following dance:

       1)     announce name on a virtual circuit.

       2)     open the listen file in that virtual circuit's directory.  When a call comes in on a virtual circuit for name, the open will  return
	      with the file descriptor open to the control file of the incoming virtual circuit.

       3)     accept or reject the call by writing an accept or reject command to the ctl file of the announced virtual circuit.

       A dkmux module pushed onto a stream makes that stream a multiplexed connection to a Datakit.  The subsequent config control message config-
       ures the multiplexer and matches it to a dk device.  The parameters to the config message are

       csc    the line number of the common signaling channel (must be > 0)

       nvc    the number of virtual circuits (optional; default chosen by Datakit)

       [no]restart
	      the word restart or norestart (optional; default is restart).  Restart tells the Datakit to  forget  all	previous  connections  and
	      authentications for this machine.

       name   The name used in binding dk device.

       window the default URP window size for virtual circuits on this Datakit line (default is 2048).

FILES

       #k/clone
       #k/[0-255]
       #k/[0-255]/data
       #k/[0-255]/ctl
       #k/[0-255]/listen
       #k/[0-255]/ruser
       #k/[0-255]/raddr

SEE ALSO

       stream(3), dkconfig(8), datakit(3)

SOURCE

       /sys/src/9/*/devdk.c

																	     DK(3)

Check Out this Related Man Page

NATM(4)                                                    BSD Kernel Interfaces Manual                                                    NATM(4)

NAME

     natm -- Native Mode ATM protocol layer

DESCRIPTION

     The BSD ATM software comes with a native mode ATM protocol layer which provides socket level access to AAL0 and AAL5 virtual circuits.  To
     enable this protocol layer, add
           options NATM
     to your kernel configuration file and re-make the kernel (do not forget to do ``make clean'').

NATM API

     The NATM layer uses a struct sockaddr_natm to specify a virtual circuit:

           struct sockaddr_natm {
             u_int8_t      snatm_len;              /* length */
             u_int8_t      snatm_family;           /* AF_NATM */
             char          snatm_if[IFNAMSIZ];     /* interface name */
             u_int16_t     snatm_vci;              /* vci */
             u_int8_t      snatm_vpi;              /* vpi */
           };

     To create an AAL5 connection to a virtual circuit with VPI 0, VCI 201 one would use the following:

             struct sockaddr_natm snatm;
             int s, r;
             s = socket(AF_NATM, SOCK_STREAM, PROTO_NATMAAL5);
                                  /* note: PROTO_NATMAAL0 is AAL0 */
             if (s < 0) { perror("socket"); exit(1); }
             bzero(&snatm, sizeof(snatm));
             snatm.snatm_len = sizeof(snatm);
             snatm.snatm_family = AF_NATM;
             sprintf(snatm.snatm_if, "en0");
             snatm.snatm_vci = 201;
             snatm.snatm_vpi = 0;
             r = connect(s, (struct sockaddr *)&snatm, sizeof(snatm));
             if (r < 0) { perror("connect"); exit(1); }
             /* s now connected to ATM! */

     The socket() call simply creates an unconnected NATM socket.  The connect() call associates an unconnected NATM socket with a virtual circuit
     and tells the driver to enable that virtual circuit for receiving data.  After the connect() call one can read() or write() to the socket to
     perform ATM I/O.

Internal NATM operation
     Internally, the NATM protocol layer keeps a list of all active virtual circuits on the system in natm_pcbs.  This includes circuits currently
     being used for IP to prevent NATM and IP from clashing over virtual circuit usage.

     When a virtual circuit is enabled for receiving data, the NATM protocol layer passes the address of the protocol control block down to the
     driver as a receive ``handle''.  When inbound data arrives, the driver passes the data back with the appropriate receive handle.  The NATM
     layer uses this to avoid the overhead of a protocol control block lookup.  This allows us to take advantage of the fact that ATM has already
     demultiplexed the data for us.

CAVEATS

     The NATM protocol support is subject to change as the ATM protocols develop.  Users should not depend on details of the current implementa-
     tion, but rather the services exported.

SEE ALSO

     en(4), fatm(4), hatm(4), natmip(4), patm(4)

AUTHORS

     Chuck Cranor of Washington University implemented the NATM protocol layer along with the EN ATM driver in 1996 for NetBSD.

BSD                                                              December 29, 1997                                                             BSD
Man Page