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
+
+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
+
+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 *
+
+SIGUSR1
+
+Parent signal assignment:
+ $SIG{USR1} = \&USRMAN;
+
+Child signal assignment:
+ $SIG{USR1}= \&logstatus;
+
+Command-line invocations:
+ B B<-s> SIGUSR1 I
+
+Subroutine B:
+ When invoked for the B parent I,
+SIGUSR1 is sent to all the children, and the status of
+each connection is logged.
+
+
+=back
+
+=cut
500 Internal Server Error
Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator at
root@localhost to inform them of the time this error occurred,
and the actions you performed just before this error.
More information about this error may be available
in the server error log.