child on the remote server, and the
+same is true vice versa (two persistent connections per server
+combination).
+
+lond listens to a TCP/IP port (denoted B in Fig. Overview of
+Network Communication) and forks off enough child processes to have
+one for each other server in the network plus two spare children. The
+parent process maintains the population and listens for signals to
+restart or shutdown. Client servers are authenticated by IP.
+
+When a new client server comes online, C sends a signal I
+to lonc, whereupon C tries again to reestablish all lost
+connections, even if it had given up on them before - a new client
+connecting could mean that that machine came online again after an
+interruption.
+
+The gray boxes in Fig. Overview of Network Communication denote the
+entities involved in an example transaction of the Network. The Client
+is logged into server B, while server B is her Home
+Server. Server B can be an access server or a library server, while
+server B is a library server. She submits a solution to a homework
+problem, which is processed by the appropriate handler for the MIME
+type "problem". Through C, the handler writes information
+about this transaction to the local session data. To make a permanent
+log entry, C establishes a connection to the UNIX domain
+socket for server B. C receives this command, encrypts it,
+and sends it through the persistent TCP/IP connection to the TCP/IP
+port of the remote C. C decrypts the command, executes it
+by writing to the permanent user data files of the client, and sends
+back a reply regarding the success of the operation. If the operation
+was unsuccessful, or the connection would have broken down, C
+would write the command into a FIFO buffer stack to be sent again
+later. C now sends a reply regarding the overall success of the
+operation to C via the UNIX domain port, which is eventually
+received back by the handler.
+
+=head2 Dynamic Resource Replication
+
+Since resources are assembled into higher order resources simply by
+reference, in principle it would be sufficient to retrieve them from
+the respective Home Servers of the authors. However, there are several
+problems with this simple approach: since the resource assembly
+mechanism is designed to facilitate content assembly from a large
+number of widely distributed sources, individual sessions would depend
+on a large number of machines and network connections to be available,
+thus be rather fragile. Also, frequently accessed resources could
+potentially drive individual machines in the network into overload
+situations.
+
+Finally, since most resources depend on content handlers on the Access
+Servers to be served to a client within the session context, the raw
+source would first have to be transferred across the Network from the
+respective Library Server to the Access Server, processed there, and
+then transferred on to the client.
+
+=begin latex
+
+\begin{figure}
+\includegraphics[width=0.75\paperwidth,keepaspectratio]{Dynamic_Replication_Request}
+ \caption{\label{Dynamic_Replication}Dynamic Replication}
+\end{figure}
+
+=end latex
+
+To enable resource assembly in a reliable and scalable way, a dynamic
+resource replication scheme was developed. Fig. "Dynamic Replication"
+shows the details of this mechanism.
+
+Anytime a resource out of the resource space is requested, a handler
+routine is called which in turn calls the replication routine. As a
+first step, this routines determines whether or not the resource is
+currently in replication transfer (Step B). During replication
+transfer, the incoming data is stored in a temporary file, and Step
+B checks for the presence of that file. If transfer of a resource
+is actively going on, the controlling handler receives an error
+message, waits for a few seconds, and then calls the replication
+routine again. If the resource is still in transfer, the client will
+receive the message "Service currently not available".
+
+In the next step (Step B), the replication routine checks if the
+URL is locally present. If it is, the replication routine returns OK
+to the controlling handler, which in turn passes the request on to the
+next handler in the chain.
+
+If the resource is not locally present, the Home Server of the
+resource author (as extracted from the URL) is determined (Step
+B). This is done by contacting all library servers in the author?s
+domain (as determined from the lookup table, see Fig. 1.1.2B). In Step
+B a query is sent to the remote server whether or not it is the
+Home Server of the author (in our current implementation, an
+additional cache is used to store already identified Home Servers (not
+shown in the figure)). In Step B, the remote server answers the
+query with True or False. If the Home Server was found, the routine
+continues, otherwise it contacts the next server (Step D2a). If no
+server could be found, a "File not Found" error message is issued. In
+our current implementation, in this step the Home Server is also
+written into a cache for faster access if resources by the same author
+are needed again (not shown in the figure).
+
+=begin latex
+
+\begin{figure}
+\includegraphics[width=0.75\paperwidth,keepaspectratio]{Dynamic_Replication_Change}
+ \caption{\label{Dynamic_Replication_Change}Dynamic Replication: Change} \end{figure}
+
+=end latex
+
+In Step B, the routine sends a subscribe command for the URL to
+the Home Server of the author. The Home Server first determines if the
+resource is present, and if the access privileges allow it to be
+copied to the requesting server (B). If this is true, the
+requesting server is added to the list of subscribed servers for that
+resource (Step B). The Home Server will reply with either OK or
+an error message, which is determined in Step D4. If the remote
+resource was not present, the error message "File not Found" will be
+passed on to the client, if the access was not allowed, the error
+message "Access Denied" is passed on. If the operation succeeded, the
+requesting server sends an HTTP request for the resource out of the
+C server content resource area of the Home Server.
+
+The Home Server will then check if the requesting server is part of
+the network, and if it is subscribed to the resource (Step B). If
+it is, it will send the resource via HTTP to the requesting server
+without any content handlers processing it (Step B). The
+requesting server will store the incoming data in a temporary data
+file (Step B) - this is the file that Step B checks for. If
+the transfer could not complete, and appropriate error message is sent
+to the client (Step B). Otherwise, the transferred temporary file
+is renamed as the actual resource, and the replication routine returns
+OK to the controlling handler (Step B).
+
+Fig. "Dynamic Replication: Change" depicts the process of modifying a
+resource. When an author publishes a new version of a resource, the
+Home Server will contact every server currently subscribed to the
+resource (Step B), as determined from the list of subscribed
+servers for the resource generated in Step B. The subscribing
+servers will receive and acknowledge the update message (Step
+B). The update mechanism finishes when the last subscribed server
+has been contacted (messages to unreachable servers are buffered).
+
+Each subscribing server will check if the resource in question had
+been accessed recently, that is, within a configurable amount of time
+(Step B).
+
+If the resource had not been accessed recently, the local copy of the
+resource is deleted (Step B) and an unsubscribe command is sent
+to the Home Server (Step B). The Home Server will check if the
+server had indeed originally subscribed to the resource (Step B)
+and then delete the server from the list of subscribed servers for the
+resource (Step B).
+
+If the resource had been accessed recently, the modified resource will
+be copied over using the same mechanism as in Step B through
+B, which represents steps Steps B through B in the
+replication figure.
+
+=head2 Load Balancing
+
+XC provides a function to query the server's current loadavg. As
+a configuration parameter, one can determine the value of loadavg,
+which is to be considered 100%, for example, 2.00.
+
+Access servers can have a list of spare access servers,
+C, to offload sessions depending on
+own workload. This check happens is done by the login handler. It
+re-directs the login information and session to the least busy spare
+server if itself is overloaded. An additional round-robin IP scheme
+possible. See Fig. "Load Balancing Sample" for an example of a
+load-balancing scheme.
+
+=begin latex
+
+\begin{figure}
+\includegraphics[width=0.75\paperwidth,keepaspectratio]{Load_Balancing_Example}
+ \caption{\label{Load_Balancing_Example}Load Balancing Example} \end{figure}
+
+=end latex
=head1 DESCRIPTION
Provides persistent TCP connections to the other servers in the network
through multiplexed domain sockets
- PID in subdir logs/lonc.pid
- kill kills
- HUP restarts
- USR1 tries to open connections again
+B forks off children processes that correspond to the other servers
+in the network. Management of these processes can be done at the
+parent process level or the child process level.
+
+After forking off the children, B the B executes a main
+loop which simply waits for processes to exit. As a process exits, a
+new process managing a link to the same peer as the exiting process is
+created.
+
+B is the location of log messages.
+
+The process management is now explained in terms of linux shell commands,
+subroutines internal to this code, and signal assignments:
+
+=over 4
+
+=item *
+
+PID is stored in B
+
+This is the process id number of the parent B process.
+
+=item *
+
+SIGTERM and SIGINT
+
+Parent signal assignment:
+ $SIG{INT} = $SIG{TERM} = \&HUNTSMAN;
+
+Child signal assignment:
+ $SIG{INT} = 'DEFAULT'; (and SIGTERM is DEFAULT also)
+(The child dies and a SIGALRM is sent to parent, awaking parent from slumber
+ to restart a new child.)
+
+Command-line invocations:
+ B B<-s> SIGTERM I
+ B B<-s> SIGINT I
+
+Subroutine B:
+ This is only invoked for the B parent I.
+This kills all the children, and then the parent.
+The B file is cleared.
+
+=item *
+
+SIGHUP
+
+Current bug:
+ This signal can only be processed the first time
+on the parent process. Subsequent SIGHUP signals
+have no effect.
+
+Parent signal assignment:
+ $SIG{HUP} = \&HUPSMAN;
+
+Child signal assignment:
+ none (nothing happens)
+
+Command-line invocations:
+ B B<-s> SIGHUP I
-=head1 README
+Subroutine B:
+ This is only invoked for the B parent I,
+This kills all the children, and then the parent.
+The B file is cleared.
-Not yet written.
+=item *
-=head1 PREREQUISITES
+SIGUSR1
-POSIX
-IO::Socket
-IO::Select
-IO::File
-Socket
-Fcntl
-Tie::RefHash
-Crypt::IDEA
+Parent signal assignment:
+ $SIG{USR1} = \&USRMAN;
-=head1 COREQUISITES
+Child signal assignment:
+ $SIG{USR1}= \&logstatus;
-=head1 OSNAMES
+Command-line invocations:
+ B B<-s> SIGUSR1 I
-linux
+Subroutine B:
+ When invoked for the B parent I,
+SIGUSR1 is sent to all the children, and the status of
+each connection is logged.
-=head1 SCRIPT CATEGORIES
-Server/Process
+=back
=cut