Protocols/AOL/Technical/Online Host Processes and Architecture

	AOL-Files	Articles	Downloads	FDO91

TODO Move to official documentation

The AOL Manager Subsystem

aol_manager is the master subsystem and host online process that communicates with and controls all other subsystems within the aol_manager-based system. aol_manager starts and monitors all processes defined in the system configuration database. To modify the configuration database or communicate with aol_manager, system administrators use the configure tool.

Informational and error messages that result from actions taken with the configure tool are written to the system log file and either displayed on the Stratus command line or sent to the notify list. The notify list is a list of Stratus login accounts that aol_manager broadcasts log messages to if a system, subsystem or host online process has a configuration change or problem.

Base Subsystem

The base subsystem manages information about member session activity and attributes of network connections. the base subsystem supports the following functionality:

1. Managing host system statistics.
2. Managing session time and plus group activity.
3. Managing inactive processes.

The base subsystem include Obsolete, Shared_stats, and Stats. Obsolete monitors and reads queues for processes that have been turned off. Processes that have been turned off are pointed to Obsolete, which in turn functions as a "bit bucket" receptacle for these processes.

Shared_stats accepts real-time statistics broadcasts from other processes and moves the statistics into the shared_stats database for access by tools such as userlist_util. Stats controls a statistical database of member session time and plus group activity. It also writes session and summary status records to daily files.

Comm Subsystem

The comm subsystem provides terminal handling through connections in a distributed network. comm manages the servers, network control, and memory needed to support a high volume of member connections to the host system.

Comm also provides connection to the Internet. The external Internet connection is supported by the domain name system (DNS) server that maps IP addresses to the members' screen names. An IP address is a unique 32-bit number specified as four 8-bit numbers(represented as integers) called octets,the four octets are connected by periods. The numbers must be in the range 0-255. base subsystem has berp, dns_agent, ip_tunnel, net_mux, rejector, switchboard, tih, and tih_monitor.

A berp (back-end routing processor) functions as a controller and network router for tih (terminal handler) messages in a distributed network architecture. They ensure easy monitoring of tih FEPs (front-end processors) and write information to the system log file when system problems occur or when the FEP portion of tih crashes. dns_agent determines the IP addresses assigned to screen names by the ip_tunnel. It can also perform the inverse query by determining screen names from IP addresses.

dns_agent performs this task by emulating a standard DNS (doman name system) server on the Internet.

ip_tunnel is configured at approximately one per two BERPs. It also multiplexes and demultiplexes IP datagrams between the Internet and user datagrams.

A datagram is one packet (unit) of information and associated delivery information, such as the destination address, that is routed through a packet-switching network. Additionally, the ip_tunnel functions as a gateway to the Internet. Ip_tunnel exchanges messages with the user IP stack (AOLSOCK) throught normal server-to-client messaging. It also sends session records to unix_stats.

net_mux is the brdige between the UNIX TCP/IP-based queue message network and the Stratus queue message system. rejector is configured one per BERP. When the BERP cannot reach a host queue for one reason or another, it forwards the member request to rejector for handling. rejector contains per-token configuration information that allows it to "reject" the request and free the member to go on to other activities. switchboard loads token, queue, and other related tables to provide a central point for information to be passed on to tih through berps.

tih controls the communications connection between the client and the host system. It also provides a message routing function and accumulates session statistics for members. There are two existing tih processes: x25_tih and tcp_tih.

tih identifies and tracks each member communication that it handles by assigning a unique ID to a connection when a session begins. tih_monitor performs background support operations for tih, such as writing data to disk, that allow tih to maintain optimum performance. When a tih detects certain events, it captures important information and sends the data to tih_monitor, which stores the data in centrally located event files for later analysis. the actual location of these files is dependent upon system configuration.

tih_monitor also monitors when a tih is restarted or when an X.25 line is down. tih restart monitoring will not be used when tih_monitor is ported to UNIX.

Login Subsystem

The login subsystem controls the user interface and screens responding to members who are sigining on or off the host system. Its operation is dependent upon the initial client computer connection established by the comm subsystem. Especially, login subsystem supports the following functionality:

1. Monitoring member connection time and login activity.
2. Updating the master account and activity databases with current usage activity for billing data.
3. Updating member software.
4. Providing promotional features through the Welcome Screen.

The login subsystem has the following processes: activity, back_porch, drul, promo_manager,update_800, and update_disk. activity separates raw activity billing records into separate raw activity files based on business IDs and writes them out to the appropriate version of the raw_activity.[yy-dd-mm] file. back_porch manages login and logout control and processing , manages popups, and determines when a member needs an update disk operation (UDO).

A popup is a message that a member sees before the Welcome Screen appears. Popups are only seen once by each master account. Popups are used during the login process for a variety of purposes, such as soliciting beta testers to test beta versions of America Online software, to sell America Online merchandise, or to conduct member surveys.

drul tracks member sessions, including sign on and sign off times. back_porch queries drul to see if an account is logged in. berp adds druls. drul automatically senses the BERPs it is connected to and the BERP automatically adds the new drul to its list of login and logout state subscribers. buddy_list receives screen names from drul that appear in th buddy_list. drul_brdge issues a request to drul to get a copy of the member's context. Context is information stored by individual processes that tracks what a member did previously in his or her current session.

This "memory" keeps queue message traffic down because the processes are not sending tracking information back and forth. shared_stats receives information from drul and places it into a shared virtual memory region. tih notifies drul whenever a member signs on or signs off the online service and assigns a unique queue ID to each session. drul forwards this information to back_porch.

back_pporch adds information about the member from the master database and updates tih with the information. tod issues a single subscribe query to drul to get the tool information and display it to the member. userlist_util is a tool that sends messages to drul to set or clear mail flags. usher sends a message to drul to indicate that a member has entered or exited a chat room. wathc reads the information sent from drul to shared_stats.

whisper queries drul to get information for sending instant messages to members. promo_manager creates and schedules promotions. A promotion is a marketing effort designed to attract new members from specific market segments to the online service. promo_manager manages the adding, deleting, updating, and listing of promotions on the Welcome Screen.

update_800: back_porch notifies update_800 when a member logs in with an account through an 800 number. update_800 solicits information from the member to determine a list of likely access numbers. These numbers are presented to the member, who choose the best one. The PC database is updated to use the chosen numbers. update_disk performs UDOs only. files in the database and tool directories are updated in this manner.

update_disk receives a request from back_porch to do UDOs for a member who has a Macintosh client computer. update_disk sends UDOs back to the member's Macintosh client computer vis tih. update_disk performs tool updates and DOD transfers the information to the member's Macintosh client computer.

Reg Subsystem

The reg subsystem implements and controls the user interface and screens in response to members signing on or off the host system. It also authorizes credit card charges from members. Specifically, the reg subsystem supports the following functionality:

1. Adding and deleting member screen names.
2. Caching unused account number.
3. Building the master account database records during initial registration to the online service.
4. managing promotional features through the Welcome Screen.
5. Authorizing credit card charges from members through an outside credit card processing vendor in real-time(<10 s). There are AcctNumbers, nameman, Register, Register_at processes.

AcctNumbers process caches unused account numbers in Billing subsystem. nameman adds and deletes screen names for members and manages the chat control function. in Signon/Signoff subsystem. Register receives member information that is used to build the master database records during the initial registration to the online service. Register_at was designed for Maiil Interface Protocol for the registration procedure instead of host-based forms and scripts. Register_at was developed for PDA.

MIS Subsystem

The mis subsystem manages member accounts and maintains online stores.

Navigation Subsystem

The navigation subsystem manages database search and retrieval.

Mail Subsystem

The mail subsystem manages all e-mail sent and received by members as well as e-mail traffic to and from the Internet.

Software Subsystem

The software subsystem manages the software libraries on the online service and the background activities needed to upload and download files to these libraries. Specifically, the software subsystem supports the following functionality:

1. Compiles inforamton about files eing uploaded such as the file's subject and author, as well as any required equipment and a description of the file.
2. Maintains the software library records and provides a list of the documents that can be downloaded by a member.
3. Initiates file transfer
4. Allows members to read descriptions of files that they can download.

Xfer Subsystem

The xfer subsystem manages file transfers.

Chat Subsystem

the chat subsystem allows members to create online rooms that are linked to a central area, where they can conduct real-time conversations.

Message Board Subsystem

The msg_boards subsystem allows members to read and post messages to the message boards area of the online service. Members with special privileges may also delete messages and create topics or categories in these areas.

IP Subsystem

The ip subsystem manages the information provider areas on the online service.

Gateways Subsystems

The gateways subsystem manages sessions with remote host applications, including the Internet.

Games Subsystems

The games subsystems manages gaming areas on the online service.

Host Online Process Communication

Host online processes communicate with each other constantly by sending messages through queues. A queue is a waiting area for messages being sent to processes. Each process can have one or more queues to receive messages. The process pulls messages off the incoming queue in a FIFO order. Communication can be one-way or two-way. If it is one-way, a message is sent by a process, and the process does not wait for or expect a response. If it is two-way, a response is expected after a message is sent.

When a message is sent by a process to another process, the queue is called a requester or sender queue. when a message is received by a process from another process, the queue is called a server queue. Most processes communicate in one-way direct queues except a few specific cases. Each process has its own direct queue, which is how the process receives information from other processes. A process's queue is named using the program module name with a .Q extension. For example, the mbox_send process (mbox_send.pm) has an mbox_send.q associated with it. This direct queue is know as the input source for the process.