*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->FreeBSD man pages -> scspd (8)              



NAME    [Toc]    [Back]

     scspd -- SCSP daemon

SYNOPSIS    [Toc]    [Back]

     scspd [-f <cfg-file>] [-d] [-T<options>]

DESCRIPTION    [Toc]    [Back]

     The scspd utility is an implementation of the Server Cache Synchronization
 Protocol (SCSP) for the Host ATM Research Platform (HARP) networking
     software.	The scspd utility synchronizes the cache(s) of server(s) running
 on a host with the caches of servers on remote hosts.  SCSP is
     defined for a number of different protocols, but the present version of
     scspd only supports ATMARP.

     By using scspd and atmarpd(8), one can provide multiple ATMARP servers in
     a single ATM LIS.	This might be useful, for example, when a LIS consists
     of a number of local-area ATM networks connected by long-distance links.
     Each local-area network could have its own ATMARP server, with all the
     servers' caches being synchronized by SCSP.  Then, if a long-distance
     link fails, hosts on a local-area network will still have connectivity to
     other local hosts (since they all use the local ATMARP server); when the
     long-distance link is restored, SCSP will re-synchronize the servers'
     caches, restoring connectivity to remote hosts.  Both scspd and
     atmarpd(8) must be running before any ATMARP cache synchronization can
     take place.

     The scspd utility implements SCSP as specified in RFC 2334, Server Cache
     Synchronization Protocol (SCSP) and draft-ietf-ion-scspd-atmarpd-00.txt,
     A Distributed ATMARP Service using SCSP.

     When scspd starts, it parses its command line and puts itself into the

TERMINOLOGY    [Toc]    [Back]

     Some of the vocabulary associated with SCSP can be confusing.  In this
     document, the following definitions are used:

     Client server or local server means the server running on the same host
     as scspd whose cache is to be synchronized with that of one or more
     remote servers.  When the word server is used alone, it means client

     Remote server means a server running on some host other than the one
     where scspd is running.

     Directly Connected Server (DCS) means a remote server that scspd communicates
 with directly.  The remote server will also be running an implementation
 of SCSP.

     Cache Alignment (CA) has two meanings.  The Cache Alignment protocol is a
     part of the SCSP protocol specification, and the Cache Alignment finite
     state machine (FSM) is a finite state machine that implements the Cache
     Alignment protocol.

OPTIONS    [Toc]    [Back]

     The command-line options are:

     -f <cfg-file>  Specifies the name of the configuration file.  If this
		    option is not specified, scspd looks for the file

     -d 	    Specifies that scspd is to be run in debug mode.  In debug
		    mode, the daemon is not put into the background.  Log messages
 are written to standard output instead of to the log
		    file specified in the configuration file.

     -T<options>    Specifies that scspd will trace specified events and messages
 as it executes.  The -T flag is followed by one or
		    more of the following options:

		    c	  trace scspd's CA Finite State Machine (FSM),
		    h	  trace scspd's Hello FSM,
		    i	  trace scspd's Client Interface FSM,
		    C	  trace CA, CSUS, CSU Request, and CSU Reply messages,
		    H	  trace Hello messages,
		    I	  trace interface messages to and from scspd's

CONFIGURATION    [Toc]    [Back]

     The configuration file consists of a sequence of configuration statements.
  These statements specify information about the servers, both
     local and remote, whose caches are to be synchronized by scspd.  RFC
     2334, Server Cache Synchronization Protocol (SCSP) and
     draft-ietf-ion-scspd-atmarpd-00.txt, A Distributed ATMARP Service using
     SCSP will be valuable in understanding how to configure scspd.

     A configuration statement other than a comment is terminated by a semicolon.
  Some statements contain blocks, delimited by braces (``{'' and
     ``}'').  Configuration statement keywords are not case-sensitive, but
     some parameters (e.g. interface names) are.  Configuration statements can
     span multiple lines.

   Comments    [Toc]    [Back]
     Three types of comments are allowed:

     # comments: any characters from ``#'' to the end of the line are ignored.

     C comments: any characters between ``/*'' and ``*/'' are ignored.

     C++ comments: any characters from ``//'' to the end of the line are

   Statements    [Toc]    [Back]
     The configuration statements recognized by scspd are:

     Server <name> {
	     Protocol <protocol ID>;
	     Netif <if_name>;
	     ServerGroupID <ID>;
	     FamilyID <ID>;
	     DCS {
		     ATMaddr <ATM address>;
		     ID <host>;
		     CAReXmitInt <int>;
		     CSUSReXmitInt <int>;
		     CSUReXmitInt <int>;
		     CSUReXmitMax <cnt>;
		     HelloDead <cnt>;
		     HelloInt <int>;
		     Hops <cnt>;

     Log {
	     File <file name>;

     Where a host address needs to be specified in the configuration file,
     either a DNS name or an IP address in dotted decimal format can be used.

     ATM addresses are specified as strings of hex digits, with an optional
     leading ``0x''.  Fields within the address may be separated by periods,
     but periods are for readability only and are ignored.  ATM addresses are
     20 bytes long.  The full address, including any leading zeroes, must be
     given.  For example:


   Server Statement    [Toc]    [Back]
     The server statement specifies a client server whose cache to be synchronized
 with the caches of other servers running on remote hosts.  There
     will be one server statement in the configuration file for each client
     server whose cache is to be synchronized by scspd.  The format of the
     server statement is:

	   Server <name> { <statements> };

     A name must be specified on the server statement, but it is not used by
     scspd.  It is expected to give a brief description of the server's purpose.

     The server statement has several sub-statements that specify the details
     of the scspd's configuration.  They are:

     Protocol ATMARP;
	     The only protocol supported by the current version of scspd is
	     ATMARP.  The protocol statement must always be specified.

     Netif <intf>;
	     The netif statement specifies the name of the ATM network interface
 on which a client server is providing service.  The netif
	     statement must always be specified.

     ServerGroupID <ID>;
	     The ServerGroupID statement specifies an identifier for the group
	     of servers being synchronized by scspd.  The ID is specified as a
	     decimal number in the range 0 - 65,535.  The server group ID must
	     be the same for all servers whose caches are being synchronized
	     by an SCSP session.  That is, the server group ID for a host must
	     be the same for all Directly Connected Servers (DCSs) pointed to
	     within a server statement.  The ServerGroupID statement must
	     always be specified.

     FamilyID <ID>;
	     The familyID statement specifies an identifier for a family of
	     parallel SCSP sessions running between a group of hosts (i.e. a
	     set of SCSP sessions with different protocol IDs but the same set
	     of servers).  The ID is specified as a decimal number in the
	     range 0 - 65,535.	The family ID is currently not used by scspd.

   DCS Statement    [Toc]    [Back]
     The DCS statement is a sub-statement of the server statement that specifies
 the characteristics of a Directly Connected Server (DCS).  The
     server statement will have one DCS statement for each DCS that scspd is
     to exchange information with.  The DCS statement has a number of substatements
 that specify the details of the configuration for the DCS.
     They are:

     ATMaddr <ATM address>;
	     The ATMaddr statement specifies the ATM address of the DCS.  The
	     ATMaddr statement must always be specified.

     ID <host>;
	     The ID statement specifies the SCSP identifier of the DCS.  For
	     ATMARP, the ID is the IP address or DNS name associated with the
	     ATM interface of the DCS.	The ID statement must always be specified.

     CAReXmitInt <int>;
	     The CAReXmitInt statement specifies the interval that is allowed
	     to elapse between retransmissions of CA messages.	If a CA message
 is sent and an acknowledgement is not received within
	     CAReXmitInt seconds, the message will be retransmitted.  The
	     default value for CAReXmitInt is 3 seconds.

     CSUSReXmitInt <int>;
	     The CSUSReXmitInt statement specifies the interval that is
	     allowed to elapse between retransmissions of CSU Solicit messages.
  When a CSUS message is sent, any Cache State Advertisements
 (CSAs) requested by the CSUS that have not been received
	     within CSUSReXmitInt seconds will be requested again by another
	     CSUS message.  The default value for CSUSReXmitInt is 3 seconds.
	     Be careful not to confuse CSUSReXmitInt and CSUReXmitInt.

     CSUReXmitInt <int>;
	     The CSUReXmitInt statement specifies the interval that is allowed
	     to elapse between retransmissions of CSU Request messages.  When
	     a CSU Request message is sent, any CSAs that are not acknowledged
	     by a CSU Reply message within CSUReXmitInt seconds will be
	     retransmitted.  The default value for CSUReXmitInt is 2 seconds.
	     Be careful not to confuse CSUReXmitInt and CSUSReXmitInt.

     CSUReXmitMax <cnt>;
	     The CSUReXmitMax statement specifies the number of times that a
	     CSA will be retransmitted as described above before SCSP gives up
	     on the CSA and discards it.  The default value for CSUReXmitMax
	     is 5.

     HelloDead <cnt>;
	     The HelloDead statement specifies the Hello Dead Factor that will
	     be sent to the DCS in Hello messages.  A ``DCS down'' condition
	     will be detected when nothing is received from a DCS in HelloDead
	     * HelloInt seconds.  The default value for HelloDead is 3.

     HelloInt <int>;
	     The HelloInt statement specifies the Hello Interval that will be
	     sent to the DCS in Hello messages.  The default value for
	     HelloInt is 3 seconds.

     Hops <cnt>;
	     The Hops statement specifies the number of hops (DCS to DCS) that
	     will be specified in CSAs originating from the local server.
	     This number must be at least as large as the diameter of the
	     server group.  That is, it must be large enough for a CSA to be
	     propagated from server to server all the way across the server
	     group.  The default value for Hops is 3.

   Log Statement    [Toc]    [Back]
     The log statement specifies how scspd is to log information about its
     operation.  The scspd utility can write log information to a file, to the
     system log, or both.

     File <file name>;
	     The file statement specifies that scspd is to write its log messages
 to the named file.  Log messages will be appended to the
	     end of the file if it already exists.

	     The syslog statement specifies that scspd is to write its log
	     messages to the syslog facility.  The scspd utility writes its
	     messages to syslog with a facility code of LOG_DAEMON.

     If no log statement is specified, scspd writes log messages to the system
     log.  If both file and syslog are specified, scspd will write log messages
 to both the named file and the system log.

   Examples    [Toc]    [Back]
     An example of a simple configuration file for scspd might be:

	   server atmarp_ni0 {
		protocol ATMARP;
		netif ni0;
		ServerGroupID 23;
		DCS {
		     ATMaddr 0x47.0005.80.ffdc00.0000.0002.0001.002048061de7.00;
		     hops 2;

     This configuration would synchronize the cache of the ATMARP server operating
 on network interface ni0 with the cache of a second server running
     on a host whose IP address is  Log messages would be written to
     the system log.

SIGNAL PROCESSING    [Toc]    [Back]

     The following signals can be used to control scspd:

     SIGHUP  Reread the configuration file and restart scspd.

     SIGINT  Dump debugging information to a file.  When it receives a SIGINT
	     signal, scspd dumps a summary of its control blocks to a text
	     file (see FILES).

FILES    [Toc]    [Back]

	     scspd default configuration file name.  A different file name can
	     be specified with the -f command-line option.

	     debugging information dump file name.  The scspd utility writes a
	     summary of its control blocks to this file when it receives a
	     SIGINT signal.  <pid> is the process ID of the daemon and <seq>
	     is a sequence number which is incremented every time a dump is

	     trace file.  The scspd utility writes trace information to this
	     file if the -T option is specified on the command line.

SEE ALSO    [Toc]    [Back]

     atm(8), atmarpd(8)

     Server Cache Synchronization Protocol (SCSP), RFC 2334.

     A Distributed ATMARP Service Using SCSP,

BUGS    [Toc]    [Back]

     If scspd terminates and is restarted, there will be a period of instability
 while previously-synchronized cache entries time out and are

     Please report any bugs to <harp-bugs@magic.net>.

COPYRIGHT    [Toc]    [Back]

     Copyright (c) 1994-1998, Network Computing Services, Inc.

AUTHORS    [Toc]    [Back]

     John Cavanaugh, Network Computing Services, Inc.
     Mike Spengler, Network Computing Services, Inc.
     Joe Thomas, Network Computing Services, Inc.

ACKNOWLEDGMENTS    [Toc]    [Back]

     This software was developed with the support of the Defense Advanced
     Research Projects Agency (DARPA).

FreeBSD 5.2.1			August 21, 1998 		 FreeBSD 5.2.1
[ Back ]
 Similar pages
Name OS Title
atmarpd FreeBSD ATMARP/SCSP interface daemon
pppd HP-UX PPP daemon
ppp HP-UX PPP daemon
cslip HP-UX PPP daemon
ppl HP-UX PPP daemon
slip HP-UX PPP daemon
pfsd HP-UX PFS daemon
pfsd.rpc HP-UX PFS daemon
cron OpenBSD clock daemon
mopd OpenBSD MOP loader daemon
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service