Chat Arch

AMERICA ONLINE
TECHNICAL NOTE
Overview of the Chat

Subsystem, Rel. 4.1
December 2000
Technical Note: Overview of the Chat Subsystem, Rel. 4.1
December 2000
Document Number: Project ID 9971
AOL Security Class: Confidential
Note: Applicable nondisclosure agreements must be in force for you to be authorized.
© Copyright 2000 America Online, Inc. All rights reserved.
This technical note contains valuable confidential and proprietary information of America Online, Inc. No part of this
technical note may be transmitted or distributed, or copied, photocopied, scanned, reproduced, translated,
microfilmed, or otherwise duplicated on any medium without written consent of America Online. If written consent is
given, the same confidential, proprietary, and copyright notices must be affixed to any permitted copies as were
affixed to the original.
Use of the software programs described herein and this technical note is subject to applicable license agreements and
nondisclosure agreements. Unless specifically otherwise agreed in writing, all rights, title, and interest to this
software and documentation remain with America Online.
Information in this technical note has been carefully checked and is believed to be accurate. However, this
information is subject to change without notice, and America Online assumes no responsibility for any inaccuracies
that may be contained in this technical note. In no event will America Online be liable for direct, indirect, special,
incidental, or consequential damages resulting from any defect or omission in this technical note, even if advised of
the possibility of such damages.
In the interest of continued product development, America Online reserves the right to make improvements to this
technical note and the products it describes at any time, without notice or obligation.
The trademarks, logos, and service marks ("Marks") displayed in this document are the property of America Online
or other third parties. You are not permitted to use the Marks without the prior written consent of America Online or
such third party which may own the Marks. "America Online," "AOL," and the AOL triangle logo are registered
trademarks of America Online, Inc.
Published by
America Online, Inc.
44900 Prentice Drive
Dulles, Virginia 20166
Phone: (703) 265-2100
Fax: (703) 265-2907
Printed in the United States of America
Table of Contents
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Types of Rooms.......................................................................................... 3
Who Should Use This Technical Note ....................................................... 5
More Information ....................................................................................... 5
Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Components and Processes......................................................................... 6
Naming Conventions ................................................................................ 11
Initialization.............................................................................................. 12
Optional Room Characteristics................................................................. 14
Functions and Event Flows for AOL Clients . . . . . . . . . . . . . . . . . . . . 15

Finding a Chat Room by Name................................................................ 15
Entering and Exiting a Chat Room........................................................... 17
Entering a Chat Room ........................................................................ 18
Variations for an ECR ........................................................................ 21
Variations for a Classic Chat Room ................................................... 21
Exit Room Procedure ......................................................................... 21
Chat Provider-directed Room Entry................................................... 22
Robust Room Blocking ............................................................................ 22
Auditoriums.............................................................................................. 23
Initialization........................................................................................ 24
Auditorium Entry.......................................................................... 25
Commands Issued from Chat Input Line...................................... 25
OSCAR Client Integration in AOL Chats. . . . . . . . . . . . . . . . . . . . . . . . 25

OSCAR Client Authorization................................................................... 26
Authorized OSCAR Client Entry and Participation ................................. 28
On AOLTV Clients .................................................................................. 30
Chat Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Operational Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
© America Online, Inc. 2000 1 America Online Confidential

Technical Note: Overview of the Chat Subsystem, Rel. 4.1 December 2000
Error Recovery ......................................................................................... 35

Lost Unplugs ...................................................................................... 35
Positive Acknowledgment of Inter-server Requests .......................... 35
Periodic Status Updates............................................................................ 36
Chat Switch to Room Name Servers .................................................. 36
Room Name to Chat Provider Servers ............................................... 36
Recovery from Server Crash or Restart.................................................... 37
Restart Notification ............................................................................ 37
Server ID During Restarts .................................................................. 38
Member Counts .................................................................................. 38
Who’s in Room................................................................................... 38
Chat Statistics (chat_stats)........................................................................ 38
Chat Element Definitions ................................................................... 39
Chat Configuration and SM_subs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
TCL Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
America Online Confidential 2 © America Online, Inc. 2000

List of Figures
Figure 1: Components and Processes......................................................................................... 6

Figure 2: Initialization of a Chat Provider Complex................................................................ 13
Figure 3: Finding a Chat .......................................................................................................... 16
Figure 4: Entering a Chat Room .............................................................................................. 18
Figure 5: Initialization of an Auditorium Provider Complex .................................................. 24
Figure 6: OSCAR Client Authorization................................................................................... 26
Figure 7: OSCAR Client Entry and Participation .................................................................... 28
Figure 8: Chat Verification ...................................................................................................... 32

Technical Note:
Overview of the Chat

Subsystem, Rel. 4.1
The chat subsystem allows members to participate in online chats in chat

rooms with other members.
The chat subsystem integrates Open System for Communication Access in

Realtime (OSCAR) clients such as AOL TV and AIM to support chat
communication between the different clients and AOL chat members.
The AOL back-end infrastructure can run AIM chat since the subsystem
supports multiple logins. In other words, a screen name can be logged on
through AOL and AIM at the same time, but a given screen name can be in
a room only once, since screen name is used as a key in the clients.
Chat configurability is enhanced through the use of Service Mapping

(SM_subs), a SOML subroutine package created for storing and looking up
configuration information that varies by one or more key values in
q_context.
Chat verification functionality lets members easily report Terms of Service

violations in chat rooms.
This document contains describes the following aspects of the chat

subsystem:
• Overview on page 3
• Design on page 5
• Functions and Event Flows for AOL Clients on page 15
• OSCAR Client Integration in AOL Chats on page 25
• Chat Verification on page 31
• Operational Information on page 35

December 2000 Technical Note: Overview of the Chat Subsystem, Rel. 4.1
Overview
A chat room is a real-time area of the online service where members can
hold conversations by typing text and seeing text sent by other members.
Types of Rooms
The chat subsystem supports the following types of rooms:
• Classic chat rooms include both People Connection chat rooms (rooms
found by clicking the People Connection button or through keyword:
chat) and conference rooms that allow members to chat in a setting of
up to 47 people. People Connection rooms consist of sanctioned
(public) rooms, member rooms, and private rooms.
• Auditoriums that allow large audiences to attend special events

presented by AOL
• Enhanced conference rooms (ECR) that allow members to attend chats

held in an auditorium-type setting, with up to 100 people in attendance
The chat subsystem consists of different chat complexes, each of which

supports one type of chat provider—one process that provides classic
rooms (chat_prov_classic), one for auditoriums (chat_prov_aud), and one
for ECRs (chat_prov_ecr)—and its associated chat engine. Each complex
has a suite of different types of chat rooms, depending on the nature of the
provider, as follows:
Auditoriums Allow a large audience to attend special events

presented by AOL. Each member is put into a row
upon entering the auditorium. On-stage speakers
are also present in the auditorium. The member is
able to see all chats of the members in their row
and of the members on stage. An auditorium guest
may communicate with the participants on stage
through an interact feature. The auditorium is set
up so that the text entered by those on stage is
broadcast (seen on the screen) to everyone logged
into that auditorium.

Conference rooms Allow members to chat in a setting of up to 47

people. Conference rooms are normally entered
through special buttons found in different content
areas. Conference rooms are also AOL-created
rooms.
Enhanced conference Allow members to attend chats held in an

rooms (ECR) auditorium-type setting with up to 100 people in
attendance. Each ECR has a stage area and an
audience area. Chat in either area is seen by all
members in the room. A unique function of ECRs
is the ability to be in up to six ECRs at a time.
Each room and each event has an URL associated
with it, allowing for greater configuration of the
room.
People Connection Allow members to join chat rooms of up to 23

rooms members. The rooms can be found by clicking the
People Connection button or through keyword:
chat.
There are three types of rooms in People

Connection:
• Sanctioned (public)—AOL-created rooms

that always appear on the room list and
replicate once they reach the 23 member
maximum.
• Member—member-created rooms that appear

on the room list as long as there are people in
the room. When the room is empty, it no
longer appears on the room list. Member
rooms do not replicate.
• Private rooms—member-created rooms that

do not appear on a room list. These rooms
cease to exist when the room is empty, and
they do not replicate.

Who Should Use This Technical Note

This document is intended for internal America Online employees in Host
Development, Quality Assurance (QA), and Operations who need to
understand the functions of the chat subsystem.
More Information
The characteristics of the different chat rooms are configured through the
chat_config tool. The tool populates information to chat provider
complexes that feed room information to the servers in all pods. For
information about the chat_config tool, see the Using the chat_config Tool
technical note.
For information on the host components of AOLTV, see the AOL TV

Overview.
Design
The chat subsystem consists of a multileveled series of servers that
integrates OSCAR and AOL clients.

Components and Processes

Figure 1 describes the components and processes of the chat subsystem:
Modem
Modem
Public Data Network Public Data Network
SNAC
FLAP
TCP/IP
Client Computer OSCAR Client
comm
OSCAR
BOS Grog
TIH BERP queue Authorizer ball
domain
chat
Nav Chat
WERP pod-n Grog
pod-b ball ball
pod-a
chat_list chat_sw
PCL
dracula
mail_send
chat_ chat_name
namesrv lob
whiscer
chat_config
search
chat_prov_ chat_prov_ chat_prov_
classic aud ecr
search_
chat_rrb gatherer
chat_fan chat_fan chat_fan

Legend
chat provider chat provider chat provider Server
chat_logger
complex complex complex
Host system
adb_ Bucky balls

Verifiication
Sybase switcher chimps
n Commun. event
Figure 1: Components and Processes

The chat subsystem processes and components are described as follows:
adb_switcher A standalone process that sends the chat_fan

server requests to the Sybase server.
Authorizer A server that authorizes an OSCAR client by

checking its password and getting an
authentication cookie, the IP address and port
number of a BOS server, and forwarding them to
the client. See OSCAR Client Authorization on
page 26 for more information.
BERP A UNIX-based back-end routing processor

(BERP) server that is part of the comm
subsystem. A BERP contains berp processes that
route the client messages to the appropriate host
process. BERP is the heart of the distributed
network, interfacing the FEPs (frontend
processor) on the Ethernet to the FDDI ring where
various servers are connected. UNIX-based front-
end processor (FEP) servers are part of the
communication subsystem and are the host
interface to the public data networks. A FEP
contains multiple terminal handler (tih) processes
that serve each of the client computer networked
online connections.
BOS ball The Bucky Ball server that implements Basic

OSCAR Services (BOS) such as the Login/
Logoff, Locate, Instant Message (IM), Buddy
List, and third party referral services that form the
core of the OSCAR service.
Bucky ball A single instance of a server that implements a

distributed OSCAR service. Typically the service
is distributed over a large number of bucky balls.
These processes are called bucky balls because
that is what they looked like in early design
diagrams. Bucky balls (or Buckminster
Fullerenes) are round carbon molecules named
after Buckminster Fuller, the architect of the
world's first geodesic dome.
Chat ball (Chat server) A type of OSCAR Bucky ball server that provide
a gateway between the OSCAR client and the
AOL chat subsystem. In this case, the contents of
a bucket are not individual users, but Chat rooms.

chat provider complex A grouping of processes consisting of a type of

chat provider and its chat fans; for
chat_prov_classic the complex feeds room
information to the chat_list server in all pods.
chat_config A standalone UNIX process that maintains room

configuration and chat system configuration; it
populates information to chat_fan, chat_fan_aud,
chat_prov_classic, chat_prov_aud, chat_name,
and chat_prov_ecr through TCL scripts.
chat_fan A UNIX process chat functions as the chat

engine; there are multiple chat_fan servers for
load balancing; chat_fan is a component of a chat
provider complex.
chat_list A podded UNIX process that members can

browse to see what chat rooms are available;
chat_list servers are podded.
chat_logger A server that receives formatted (ascii) room

event data from chat_fan (it can receive log
messages from many servers configured to send
data to it), and logs them to disk.
chat_namelob A switched UNIX process that controls entry into

the Town Square lobby, other heavily-used rooms,
and audience rows.
chat_namesrv A UNIX process of normal room entry and

auditorium stage entry; the room name servers are
divided by room name hash.
chat_prov_aud A UNIX chat provider process with the

information characteristics or features of
auditoriums; servers for chat_prov_aud are load
balanced.
chat_prov_classic A UNIX chat provider process with the

information characteristics or features of classic
chat rooms such as whether or not it has
configurable buttons; classic rooms consist of
people connection rooms and conference rooms;
servers for chat_prov_classic are load balanced.

chat_prov_ecr A UNIX chat provider process with the

information characteristics or features of
enhanced conference rooms; servers for
chat_prov_ecr are load balanced.
chat_rrb A server for robust room blocking (rrb). Upon

startup, chat_rrb builds its in-memory block list
and exception list from the robust room blocking
database. For more information, see Robust
Room Blocking on page 22.
chat_sw A podded UNIX process on the chat switch server

that routes requests and messages from the client
computer and the communication layer to the
servers of the chat subsystem.
Note: Room entry tokens (as opposed to other

message tokens) pass through a gateway switch
called Usher between the berp and chat_sw; this
switch functions as a gateway between Stratus
and UNIX servers.
chimps A UNIX process that keeps track of members by

master account number and a timer for members
who are permagagged from chat privileges;
chimps keeps track of the time the gag is to
remain in effect.
Permagging is a function of chimps that gags a

member from chatting in all rooms for a
designated amount of time. The offending screen
name is gagged, together with the master screen
name, all subaccounts, and any subaccounts
created after the gag goes into effect. After the
designated time period expires, a member must
sign off and sign back on to be able to chat again.
For an administrator to gag a screen name, the
screen name must be in the permagag database
(namely, the chimps server database).

dracula A UNIX computer that runs one process from a

family of distributed replicable user list server
API (SAPI) processes. Dracula processes track
member information for a given AOL subsystem
and report that information to a shared statistics
database on the AOL system. Dracula tells the
locator server (whiscer) what chat room people
are in.
FLAP (Frame Layer A low-level communications protocol that

Protocol) facilitates the development of higher-level,
record-oriented, communications layers. It is used
on the TCP connection between all OSCAR PC
clients and servers.
Grog (Generic Routing A server that is located in both the OSCAR queue
OSCAR Gateway) domain and the AOL queue domain so as to
facilitate communication between the BOSS in
the OSCAR queue domain, and the Nav and Chat
balls in the AOL queue domain.
mail_send A process interfacing the mail subsystem that is

used to target mail spammers by collecting the
screennames of persons who enter a chat along
with the other screennames of those already in the
room.
Nav ball A type of OSCAR Bucky ball server that provides

information to the OSCAR client about the
location of various chat subsystem components.
OSCAR (Open System OSCAR is an implementation of bucky

for Communication technology that supports AOL Instant Messenger,
Access in Realtime) Buddy Lists, and Locate. OSCAR server
processes are called bucky balls, because they
were represented by round shapes in early design
diagrams.
PCL A script processor for AOLTV. Script processors

build dynamic web pages based on requests
received from WERP. The dynamic web pages are
based on: scripts and additional templates from
the data station sent by way of WERP and data
from back-end servers sent by way of WERP and
BERP.

Public Data Network/ A network that includes phone lines, point of

modem presence (POP) modems, and packet switching
networks using a transmission control protocol
(TCP).
search_ gatherer A server that receives information about the open

chat rooms and the actual text of chats; chat
providers and chat fans communicate with the
search gatherer servers and their data feeds into
the search subsystem.
SNAC The basic communication unit that is exchanged

by OSCAR PC clients and servers.
TIH Multiple terminal handler (TIH) processes that

serve each of the client computer-networked
online connections. A TIH is part of the comm
subsystem and is the host interface to the public
data networks on a frontend processor (FEP)
server.
Verification Sybase The database in which the chat verification data is

stored.
WERP (Web End Gateway for AOLTV that provides Web access to
Routing Processor) exisiting AOL services such as Quotes and
Nameman. From the AOLTV client perspective,
WERP functions as Web server. From the host
infrastructure perspective, WERP manages web
services by communicating with the resources
such as the TurboWeb subsystem, the data station,
script processors, the System Update server, and
the Security server.
whiscer A server that tracks each user with information

from the dracula on the user’s location.
Naming Conventions
The chat subsystem in production follows the following conventions for
specific queue name instances.
The pods are named by letters, and the chat list and chat switch servers they
host are tagged to their respective pods. For example, the chat list server on

pod a is named chat_list-a while the chat switch server on pod c is named
chat_sw-c.
The chat name and chat fan servers are named from x01 to xNN, where x is
the first letter of the site of the server and N is an integer from 0 to n. For
example, chat_namesrv-r01 designates the 01 server located in Reston and
chat_fan-d15 designates the 15 server in Dulles.
The chat name lobby servers are named from.1 to .NN, where N is an
integer from 0 to n. For example, chat_namelob.1 or chat_namelob.3.
The chat prov servers are named from x01 to xNN, where x is the first
letter of the site of the server and N is an integer from 0 to n. For example,
chat_prov_aud-d01 designates the 01 server located in Dulles.
Initialization
During the initialization of any chat provider server (chat_prov) except for
auditoriums, the chat provider server supplies predefined room information
to the chat switch servers (chat_sw) and the chat list servers (chat_list). See
Auditoriums on page 23 for information about the way the auditorium
providers function during initialization. The chat provider server also
provides information to the chat_namesrv.

Figure 2 describes the general case for the role of a chat provider complex
during initialization:
chat
pod-n
pod-b
pod-a
chat_sw
chat_list
1 2
1 chat_namelob
chat_namesrv
3 3 4
chat_prov
Legend chat_fan
Server
chat provider
Host system complex
Communication
n
event
Figure 2: Initialization of a Chat Provider Complex
The role of the chat provider complex during initialization is described in

the numbered steps as follows:
1. The chat provider server (chat_prov) feeds multiple instances of room

information in a given category level (for example, the News, Sports &
Finance category of People Connection chat rooms) to the chat_list
server in all pods that maintains and monitors that category level.
2. The chat provider server (chat_prov) feeds multiple instances of

optional room characteristics (see Optional Room Characteristics on
page 14) to the chat_sw server in all pods.

optional room characteristics to the room name server (chat_namesrv).


optional room characteristics to a lobby name server (chat_namelob).
Optional Room Characteristics

Optional room characteristics are expected to apply to a relatively small
number of rooms. The characteristics are of the following types:
• Replicable—room automatically replicates when it fills up. Room

capacity must also be specified.
• Heavily-used—room is used heavily enough so that the member base

may be divided into n parts by queue ID (QID) and split into different
rooms, rather than trying to fill up one room before starting the next.
• User replication—instead of the automatic assigning of a room suffix

for room creation (replication), the user is allowed to specify a suffix. If
the user does not supply a suffix, the standard automatic suffix
selection occurs.
• Maximum room name length—maximum length of a room name

(needed for cases when a suffix increases the length of a room name
• Use lowest suffix—in auditoriums, the lowest available room number

suffix is automatically assigned
• Suffix not allowed—informs the chat_nameXX processes that the user

is not allowed to specify a suffix when creating a member-created
room; this prevents people from believing that this room is a replicable
sanctioned room authorized by AOL.
• Room capacity—maximum number of users in a room
• Plus group—plus group of a room (needed for the chat_switch to know

whether entry to the room is paid or free). A plus group number is a
unique number assigned to each area on the online service indicating
whether it is charged or free to members. Areas that have charges
associated with them are referred to as plus time areas. Plus group
numbers allow the system to track how many members have entered an
area, and how many hours were spent in that area. Plus time charges, or
surcharges, are additional per minute charges that appear on a
member’s bill. A negative plus group is free; a positive one is
surcharged.

Functions and Event Flows for AOL Clients

The chat subsystem lets the member perform the following actions:
• List chat rooms

• Search for a chat room by name
• Enter and exit a chat room (public, private, or conference) or an
auditorium
Finding a Chat Room by Name

This section is for People Connection rooms only.
When the member goes to keyword: chat or clicks the People Connection
button and then clicks the Find a Chat button, the Find a Chat screen
appears. This screen provides the following search and locate button
features to help members find a specific chat or see who is chatting in the
room selected:
• List Sanctioned and Member Chat Rooms—a list of all sanctioned and
member chat rooms and replicable conference rooms.
• Search All Member Chats—a searchable database listing all of the

chats on the service that are created by AOL Members.
• Who's Chatting—a listing of all members chatting in the chat selected.
• List More—an expanded listing of available chats.

Figure 3 shows the sequence of events that occurs when a member initiates
a find a chat room request:
1,7
Public Data Network

Modem
Client Computer
tih 2,6 berp

comm
chat
3
5 4
pod-n
pod-b
pod-a
4 chat_sw
chat_list
Legend
Server
Host system
Communication
n
event
Figure 3: Finding a Chat
The sequence of events for a member to find a chat room is described in the
numbered steps as follows:
1. The member initiates a find request, and the member’s client computer
sends one of the list-room tokens to the tih process running in the
comm subsystem.
2. tih sends the token to the berp for routing to the chat subsystem.
3. berp routes the token to chat_sw.
4. chat_sw forwards the token through the berp to the appropriate

chat_list server in the respective pod.

5. chat_list puts up the appropriate room list form, fills it in with the room
entries in the category, and routes it to the berp.
Only the entries that are viewable by this member (determined by view
rule) are shown. The appropriate room list form and appropriate
artwork are determined.
6. berp routes the form to the member’s client computer.
Entering and Exiting a Chat Room

This section describes the general case for entering a chat room followed
by the variations for entering or exiting particular types of chat rooms and
auditoriums.

Entering a Chat Room
Figure 4 describes the general case for entering a chat room:
1,5,6,9
Public Data Network

Modem
Client Computer
comm
2,6a
tih berp
5,6
chat
3,6a 5,6,9
pod-n
pod-a pod-b
10 chat_sw
chat_list
5,6,10 4a,6b 4b,6b 5,6,7
chat_name
chat_namesrv
lob
9
7 10
chat_prov
8
Legend
Server
chat_fan
Host system
chat provider
Communication
n complex
event
Figure 4: Entering a Chat Room
The sequence of events for a member to enter a chat room is described in

the numbered steps as follows:

1. The member initiates a room entry request and the member’s client
computer sends a room entry request through a token (or URL) to the
tih process running in the comm subsystem.
2. tih sends the token or URL to the berp for routing to the chat
subsystem.
Note: chat_sw checks if the member is already in the room. If so, it

goes through the entry process again with the chat provider that owns
the room. chat_sw also checks if the member is already in another chat
room.
4. chat_sw determines whether the room is identified as heavily-used.
a. If the room is not heavily used, then chat_sw determines which

chat_namesrv handles the room, based on the hash of the base room
name (for example, the base name of chambermusic is in
chambermusic1, chambermusic2, and chambermusic8 chat rooms).
It sends a queue message directly to that server.
b. If the room is heavily used, chat_sw forwards a queue message to

chat_namelob.
5. chat_namesrv or chat_namelob server looks up the room in its list of

active rooms and its room capacity information. If the room is full and
is not replicable, then it sends a rejection message to the member.
Note: The following steps are performed only if the room is full and is
replicable. These steps consist of asking whether the member wants to
enter a replicated room and handling the response. These steps are skipped
if the room entry is of a type that implicitly indicates acceptance of
replication, such as entry through the generic enter-lobby token or entry
into an auditorium (see Auditoriums on page 23). If the user requests entry
6. chat_namesrv or chat_namelob server records that the member is in the

process of entering the room. Then it sends a yes/no box to the
member, saying that the room is full, and asking if the member wants to
enter a room "like it." Both the "yes" and "no" buttons generate a
response.
Once the yes/no box sends the message to chat_sw, entry is deferred.
a. "Yes" or "no" response is routed to chat_sw.

b. As in step 4, chat_sw sends or forwards a queue message to the

appropriate room name or lobby name server.
If the member responded "no," then chat_namesrv or chat_namelob

server no longer retains information that the member is entering the
room. If the member responded "yes," then the server looks for a room
that has space available:
chat_namesrv looks through the entire replicated room name space

(namely, all numeric suffixes starting with 1) until it finds a room
with space.
chat_namelob looks through its assigned segment of the replicated

room name space. For example, if the chat_system.tcl file says that
there are three chat_namelob servers, then the first server tries
suffixes 1, 4, 7, and so on. The second server tries suffixes 2, 5, 8,
and so on. The third server tries 3, 6, 9, and so on.
In either case, the server either finds a room with space available or
creates a new room.
Note: In the rest of this description, if only chat_namesrv is mentioned,

then the procedure is the same whether chat_namesrv or chat_namelob
server is used. chat_namelob is explicitly mentioned only if it operates
differently from chat_namesrv. Both servers run the same software.
7. When a new room has to be created—either because the requested

room did not exist, or because all replicated rooms were full—
chat_namesrv selects one of the chat provider servers, on a round-robin
basis, and sends it a queue message requesting that the room be created
and the member be put into it.
In either case, chat_namesrv then records that the member is in the

process of entering this particular room and sets a timer.
The chat provider server determines whether the member is allowed to

enter the room. The member may not be, either because the room is full
or because the member is excluded from the room (for example, a kids
only account that is blocked by parental controls). If the member is not
allowed in the room, the chat_namesrv removes its entry and timer,
decrements the count of members in the room, and deletes its record of
the room if it is now empty.
8. chat_prov opens the room on a chat_fan (if not already open) and puts
the member into the room.

9. chat_fan initializes the room in the chat tool on the client through
chat_sw.
10. If the room is new and listable, chat_prov sends a message to all
podded chat_ list servers, adding the room to the list.
Variations for an ECR
When the room is an ECR, the following variations occur to the event flow
described in Entering a Chat Room on page 18:
1. The chat provider complex sends the appropriate room form to the
client. It appends atoms to the end of the stream, to cause a token to be
sent when the stream is completed.
2. The client sends a form-complete token to chat_sw. It includes the

fully-qualified room name.
3. chat_sw sends queue message to chat_namesrv. chat_namesrv records

that the member is completely in the room. Any error in subsequent
steps results in chat_namesrv being informed otherwise.
Variations for a Classic Chat Room
Classic chat room entry is indicated by a classic chat room entry token or
URL. chat_sw derives the fully-qualified name using the compatibility
categories information from classic chat provider.
chat_sw blocks a member from being in more than one classic chat room at
a time. If the member is already in a room and tries to enter another one, he
or she is removed from the first room.
Classic chat forms reside on chat_fan, not classic chat provider servers. A
stream-complete token is not generated.
Exit Room Procedure
The chat window close action, inserted by chat provider server, sends a
token including fully-qualified room name and room exit notification to
chat_namesrv and the chat provider server.

Chat Provider-directed Room Entry
For some chat providers, the room creation procedure may involve having
the member fill in a chat provider unique form (for example, when entering
a private room), to supply chat provider unique information.
The chat provider server forwards a server-directed-room-entry message to

chat_sw. The common part of the message contains the fully-qualified
room name. It is followed by a chat-provider-specific part. The chat_sw
and chat_namesrv servers relay the message down to the chat provider
(possibly a different switched chat provider server from the one that
handled the room-creation form). The chat-provider-specific part of the
message must contain all the information needed to create the room.
Robust Room Blocking

Robust room blocking is controlled by the chat_rrb server.
After startup chat_rrb builds its in-memory block list and exception list
from the robust room blocking database. After the lists are completely
loaded, chat_rrb periodically checks for database updates and reflects those
updates in memory. chat_rrb receives "room is blocked?" requests from
chat_prov_classic. The requests contain just a room name.
chat_rrb then looks in its block list to see if the room name is blocked
(member, private, or both) for any country codes, and makes a temporary
list of those country codes along with the private and member attributes. It
then looks in the exception list to see if the room name matches any
exceptions. If the name is excepted for private rooms for a particular
country code in the temporary list, the private attribute is cleared for that
country code. If the name is excepted for member rooms for a particular
country code in the temporary list, the member attribute is cleared for that
country code. If the country code ends up having neither the member or
private attributes set, it is removed from the temporary list.
The resulting temporary list is then sent back to chat_prov_classic.

chat_rrb supports preceding and trailing wildcards (*) in the block list and
the exception list. If a wildcard character is contained somewhere in the
middle of a block list item, it is treated as a normal character.

Auditoriums
An auditorium consists of a collection of rooms in an assigned category,
each one representing an auditorium row. The auditorium chat provider
must send optional room characteristics for its rooms. See Optional Room
Characteristics on page 14 for more information.
The auditorium stages are implemented as non-replicated private rooms to

prevent members from listing them or attempting to enter them. The
auditorium code itself also has sets of rosters of who is allowed to enter a
stage to prevent hackers from disrupting an event. The auditorium provider
(aud_prov) uses the chat provider-directed entry to route any potential
stage user to a specific instance of the auditorium provider. The use of the
chat provider-directed entry keeps the stage in a specific instance. As a
consequence, the other auditorium providers compute which of their peers
should receive the member’s questions. Provider-directed entry also allows
members to move to a specific row within an auditorium.
When people are put on stage the auditorium provider server provides
particular instances of room information to the chat switch servers
(chat_sw). The auditorium provider server also provides information to the
chat_namesrv.

Initialization
Figure 5 describes the general case for the role of an auditorium provider
complex during initialization:
1,5,6,9
Public Data Network

Modem
Client Computer
comm
2,6a
tih berp
5,6
chat
3,6a 5,6,9
pod-n
pod-a pod-b
10 chat_sw
chat_list
5,6,10 4a,6b 4b,6b 5,6,7
chat_name
chat_namesrv
lob
9
7 10
chat_prov
8
Legend
Server
chat_fan
Host system
chat provider
Communication
n complex
event
Figure 5: Initialization of an Auditorium Provider Complex
The role of the chat provider complex for auditoriums during initialization
is described in the numbered steps as follows:

1. The chat provider server (aud_prov) feeds multiple instances of

optional room characteristics (see Optional Room Characteristics on
page 14) to the chat_sw server in all pods.

optional room characteristics to the room name server (chat_namesrv).

optional room characteristics to a lobby name server (chat_namelob).
Auditorium Entry
Audience attendees are only put into rooms by chat_namelob. A member’s

initial entry into an auditorium is handled like entry into a room with
replication implicitly accepted. The rows in the auditorium always use the
heavily used optional room characteristic. Entry is handled through a
chat_namesrv for stage entry or a chat_namelob.
Commands Issued from Chat Input Line
chat_fan has to recognize auditorium commands issued on the chat input

line, and send them to the auditorium chat provider through a queue
message. This routine is only used for the auditorium stage to implement
the commands by which the stage masters control and manage the event.
OSCAR Client Integration in AOL Chats

OSCAR clients participate in AOL chats by transmitting messages in
standard FLAP and SNAC protocols over a TCP connection between the
OSCAR client and Nav ball and Chat ball bucky-style servers.
This section describes the following two aspects of OSCAR client

integration in AOL chats:
• OSCAR Client Authorization on page 26
• Authorized OSCAR Client Entry and Participation on page 28

OSCAR Client Authorization

Figure 6 shows an overview of the authorization of an OSCAR client:
SNAC
FLAP
TCP/IP
Public Data Network
Modem
3
1 OSCAR Client
4
OSCAR 6
BOS Grog
queue Authorizer ball
domain
2
AOL
Nav Chat
queue Grog
ball ball
domain
5 Legend
Server
Host system
Bucky balls
n Commun. event
Figure 6: OSCAR Client Authorization
The authorization of an OSCAR client that wants to chat proceeds as

follows:
1. Client connects to Authorizer and Authorizer checks the password of

the client in its database.
2. Authorizer gets an authentication cookie and the IP address and port

number of BOS server, and forwards them to the client.
3. The client then disconnects from Authorizer and connects to a BOS at

the provided IP address. The client sends authentication cookie directly
to selected BOS server and tells the BOS it wants to chat.
4. Client connects directly to the Nav balls.
5. Nav balls connect to Chat balls to find out what room to connect to.

Note: Communication between the OSCAR queue domain and the

AOL queue domain passes through the Grog (Generic Routing OSCAR
Gateway) servers which exist in both domains.
6. Client connects to the Chat balls for the designated rooms.
See Authorized OSCAR Client Entry and Participation on page 28 for the
event flow in the chat subsystem.

Authorized OSCAR Client Entry and Participation

Figure 7 describes how authorized OSCAR clients participate in AOL
chats:
OSCAR client
8
1,3 2,6
9
16
Nav
BOS Chat
ball 13
ball ball
7,10,11,14
17
15
4,5
chat_namesrv chat_name
lob
12
18
chat_prov
12
Legend
Server
chat_fan
Host system
Bucky ball
chat provider
n Commun. event
complex
Figure 7: OSCAR Client Entry and Participation
The sequence of events is as follows:
1. Client sends a chat_nav_reques_chat_rights message to Nav ball.
2. Nav ball responds with a chat_nav_nav_info message to the client.
3. Client sends a chat_nav_create_room message to Nav ball.

4. Nav ball sends a chat_prov_chat_is_msg_provider_validate_room to

Chat_prov.
5. Chat_prov sends back return code.
6. If the response from Chat_prov is yes, Nav ball responds with a

chat_nav_nav_info message to the client.
Note: The AOL chat system does not allow clients to set room
characteristics, or to open a room without entering it. The integrated
AOL-OSCAR chat system responds to the snac_chat_nav_create_room
message by returning the configured characteristics for the room that
the client is attempting to create. The room is not actually created until
someone tries to enter it.
7. Nav ball sends a chat_map_cookie_request message to Chat ball.

(There is no response.)
8. Client sends chat service_request to BOS.
9. BOS sends a BAT message to the Nav domain, with function ID

chat_nav_request_prereservation_func_id. The message ends up at the
Nav ball that is responsible for the user name.
10. Nav ball sends a chat_is_msg_chatball_query_cookie to Chat ball.
11. Chat ball sends the room category and type to Nav ball.
Note: Nav ball uses standard AOL chat system procedure for
determining which chat_namesrv handles the specified room. It then
sends a QMI message to that chat_namesrv, requesting a pre-
reservation. If the specified room is heavily-used (see Optional Room
Characteristics on page 14), then the Nav ball forwards the message to
the lobby name server generic name. chat_namesrv reserves a slot for
the user in the specified room, or in a replicated instance if necessary. It
then sends a QMI message response back to the Nav ball. The response
includes the name of the room in which a slot was reserved.
12. Nav ball sends a chat_is_put_user_in_room message which goes down

to the provider and fan as in a regular room (see Entering and Exiting a
Chat Room on page 17) except that in each of the reservation messages
prereservation is set to 1.
13. chat_namelob sends a response to the chat_is_put_user_in_room

message.

14. Nav ball sends Chat ball a

chat_is_msg_chatball_request_prereservation message. The message
ends up at the Chat ball that is responsible for the room name.
15. Chat ball sends a BAT message to the BOS domain, with function ID
boss_prereservation_response_func_id.
Now the BOS has the fully-resolved room name, including any
replication (instance number). So it can continue with the reservation
process, which is targeted at the Chat ball that handles that exact room
name.
16. Chat ball sees that the client made a connection to it and sends Nav ball
as chat_is_msg_oscar_client_online message.
17. Nav ball sends a message to chat_namesrv which propagates it down

the provider to chat_fan.
18. chat_fan sends a chat_is_msg_chatball_users_in_room message to

Chat ball.
The user is in the room.
Any messages send OSCAR clients go to Chat ball and are then
forwarded to chat_fan which coordinates all clients, both traditional
and OSCAR. Any chat messages sent to chat_fan are sent out to both
OSCAR clients through Chat ball as well as traditional clients.
On AOLTV Clients
AOLTV clients obtain lists of chat categories and rooms within a category
in a different way than described above. The AOLTV client gets chat
listings through the WERP and PCL AOLTV infrastructure shown in
Figure 1 on page 6. The PCL interpreter (script processor) gets the lists
from the chat_lists and formats them as HTML web pages. The web pages
are sent through the WERP to the AOLTV client.
For information on the host components of AOLTV, use a standalone

browser and see the AOLTV Overview.

Chat Verification
Chat verification lets AOL members easily report Terms of Service
violations to the Community Action Team (CAT). CAT is a highly trained
group responsible for enforcing AOL's content and conduct standards. CAT
can issue written warnings and, should the violation(s) be serious enough,
terminate an account.
Chat verification is initially implemented as a token-based extension of

chat_fan functionality for paying customers in rooms designated for paying
customers.
For each chat room, chat_fan keeps a list of as many chat messages as will
fit into the buffer allocated for the room.
When a member clicks on the Notify AOL button on a chat form, a notify
form is displayed which gives the member a chance to submit a report on
offensive or inappropriate text received through chat. The Notify form
displays a snapshot of chat text (buffered up to 64K bytes, configurable) of
the chat room when the member clicks the Notify button, a list of member
screen names who have been stored in the buffered text, and a field for
reporter’s comments. If the member clicks on the Send button on the
Notify form, the reporter, the person is reported, the chat room information
and the buffered chat text are sent to chat verify Sybase through SOMLDB
servers.
Each report is called a rat report. The rat report has an associated ratter, the
member submitting the rat report. With chat, each rat report also has a
single rattee, the person being ratted on.

Figure 8 describes chat verification:
1,5,6
Public Data Network

Modem
Client Computer
2,7 comm
tih 5 berp
chat
5
3,8 pod-n
pod-a
chat_sw
4,9 5
chat_fan
10
adb_switcher
Legend
Database
11
Server
Host system Sybase

Communication
n
event
Figure 8: Chat Verification
The notification sequence of events for a member is described in the

numbered steps as follows:
1. The member clicks Notify AOL button and the member’s client
computer sends a Notify AOL request through a TOKEN_AE to the tih
process running in the comm subsystem.

4. chat_sw routes the token to chat_fan.
5. chat_fan pops up a Notify AOL form on the client computer.
Note: A timer is set (configurable) when the Notify AOL form is sent.
If the member does not Send or Cancel the form within a configurable
amount of time, chat_fan pops up another form to the client asking if
the member wishes to continue or cancel. If the member fails to answer
this form within the specified amount of time, then another Notify AOL
form is sent to the member and the timer is reset.
6. When the member enters the violator’s screenname and clicks Send or
Cancel, the client computer sends a TOKEN_AD to the tih process
running in the comm subsystem.
9. chat_sw routes the token to chat_fan.
10. chat_fan takes different actions depending on which button the member
clicked.
a. If the member clicked Cancel, chat_fan releases the information in

its memory.
b. If the member clicked Send, chat_fan sends the information in the

data fields to ADB_switcher (SOML servers).
11. ADB_switcher sends the data to a Sybase table known as the rat report
and populates the following fields:
ReportId
Processed
ReportType
DateEntered
RatTime
RatterSn

RatterIsComLeader
RatterParentCtrl
RatterMajorVer
RatterBHardware
RatterOSFmlyVer
RatterMoCo
RatterSType
RatterMinorVer
RatterBid
RatterBrandiID
RatterCharSet
RatterComm
RatteeSn
RatterMajorVer
RatterBHardware
RatterOSFmlyVer
RatteeSType
RatteeMoCo
RatteeMinorVer
RatteeBid
RatteeBrandiID
ChatRoomName
KidOnlyRoom
RoomPartnerID

RoomChannelID
RoomCategoryID
RoomCategoryName
RatChatMsg
Operational Information
This section describes the following types of operational information:
• Error Recovery on page 35
• Periodic Status Updates on page 36
• Recovery from Server Crash or Restart on page 37
• Chat Statistics (chat_stats) on page 38
See Table A-1, Chat Configuration Information in Appendix A for a

summary of the principal configuration information.
Error Recovery
This section describes the following types of error recovery:
• Lost unplugs
• Inter-server requests
Lost Unplugs
The chat_sw servers periodically bounce a strobe message off the terminal
handler for every member in a room. Repeated lack of response indicates
that the member is no longer logged on, even though no unplug was
received. chat_sw sends to the other servers a notification that the member
is no longer in the room(s).
Positive Acknowledgment of Inter-server Requests
When one server sends a request queue message to another to put a

member into a room, the second server sends a response queue message

back to the first. If the response is not received within the timeout interval,
the requestor removes the member from the room and forwards a
notification to the member’s chat_sw. The chat_sw in turn relays it down.
Periodic Status Updates

The chat system servers periodically update the servers below them to
confirm that they all have the same list of what members are in what
rooms.
Chat Switch to Room Name Servers
chat_sw servers periodically go through their lists of members in rooms

and send confirmation messages to the appropriate chat_namesrv servers.
chat_namesrv servers give up on a member if a confirmation is not

received within the configured time interval. The "give up" interval is
longer than the confirmation interval, so that more than one confirmation
message has to be received before a member is given up on.
Once a chat_namesrv gives up on a member, it notifies the appropriate

chat_provider server.
If a chat_namesrv receives a confirmation for a member who is not in the

room, it notifies chat_sw accordingly. chat_sw removes its record of the
member being in that room.
Room Name to Chat Provider Servers
The chat provider servers give up on a member if a confirmation is not

received within the configured time interval. The give up interval is longer
than the confirmation interval, so that more than one confirmation message
has to be lost before a member is given up on.
chat_name servers periodically go through their lists of members in rooms

and send confirmation messages to the appropriate chat_provider servers.
Once a chat provider server gives up on a member, it notifies the

appropriate chat_fan.

Recovery from Server Crash or Restart

Ideally, the chat subsystem could keep all members in the rooms they were
in, in spite of the crash of any individual server. The goal, instead, is to
remove members from rooms that are affected by the crashed server, and
return the chat system to a consistent state.
Restart Notification
The following restart notifications are for cleaning up rooms that are
destroyed due to server restart:
• When chat_sw restarts, it sends a restart notification to all

chat_namesrv and chat_namelob servers, all chat provider servers, and
all chat_fan servers.
• When a chat_namesrv or chat_namelob restarts, it sends a restart

notification to all chat_sw servers and all chat provider servers.
• When a chat provider server restarts, it sends a restart notification to all

chat_namesrv and chat_namelob servers, to its configured chat_fan
servers, and all chat_sw servers.
• When a chat_fan server restarts, it sends a restart notification to the

chat provider servers of the same provider ID and all chat_sw servers.
• For auditoriums, the system sends restart notifications to all chat_sw,

chat_namesrv, and chat_namelob servers, and to their configured
chat_fan servers. Additionally, it sends restart notifications to all peer
auditorium servers to allow them to readjust their status. If the
auditorium process that crashed had any open stages, the peer
auditoriums change the logical auditorium status (for the ones
associated with those stages) to initial defaults. In other words, features
like bidding and voting are automatically turned off to prevent
synchronization problems. During the restart, the auditorium peers
share their current user status with the process restarting for any open
logical auditoriums. This sharing prevents users from voting multiple
times and to monitor their maximum question counts used to prevent
hackers from attempting to flood the stage with junk questions. The
record of a member vote persists for the life of an event.

Server ID During Restarts
The servers that are listed as receiving restart notifications send periodic
server ID messages to the servers that send the notifications. A server ID
response that differs from the last-received server ID response indicates
that the server has restarted.
Member Counts
The chat provider servers periodically send updates to the chat_list servers,
indicating how many members are in each room.
Who’s in Room
A request to list the members in a room is dispatched to chat_sw, which

passes it to chat_list, and to the chat_fan server that runs the room.
Chat Statistics (chat_stats)

The chat_fan server sends a formatted event message to the chat_logger
server through a QMI message whenever a room is created/closed or a
member is entering/exiting a room.
chat_logger changes log files at regular intervals (default is 60 minutes).

The format of the log file name is: prefix.mmddyyyy.hhmmss.unix-time.
For efficiency, chat_logger collects incoming log messages and writes

them all to disk when the collection buffer is full or when it sets an timer
expires.
As with log files, chat_logger detects a file system full error, and other
errors, and changes its internal state. Then it will log an error every 5 min
(configurable), and will not write the log until this situation is cleared.

Chat Element Definitions
Table 1 defines the chat elements:
Table 1: Chat Element Definition

Type Description
chat fan server Identifies the server name. For example,
name chat_fan_r01 or chat_fan_audd01
operation type Create Room 0
Enter Room 1
Exit Room 2
Close Room 3
operation start_time The time stamp for the start of an operation
operation end_time The time stamp for the end of an operation
member account The master account number; enables count of
number unique accounts
member subaccount Enables count of screennames
number
event name Identifies the name of the auditorium
event start time Identifies the time that the auditorium was
created.
event end time Identifies the time that the auditorium was closed.
Note: If members attended an event at 7 pm; but

the event did not actually begin until 8 pm; the
system can only track and report usage as of the 8
pm time stamp.
room category ID Identifies chat categories, for example, Town
Square, Arts and Entertainment, Friends, Life,
News, Sports, and Finance; the ID also identifies
the room type as People Connection, Member
Created, e, ECR, or Auditorium.


Type Description
room name Identifies the chat room under the chat categories.
For example, if Room Category ID = Arts and
Entertainment, then the room name may be listed
as:
Fan N Sync
Fan Mariah Carey
Fan Latin Pop
For Member Created Room Types, the Room

Name is tracked through the room category ID.
Room name does not include the room replication
number.
room language Numbers are defined in soml INTL.h file
room replication Identifies multiple occurrences of a room being
number created. A null value means there is no
replication of that particular room category ID
room requester The screenname of the AOL person that requested
that the chat room be created. Such a request
could be sent to the ISO from Account Managers,
Program Managers, or AOL Live. Room
requester is referenced in the Chat Configuration
Tool as Room Owner.
row number for The unique row number within an event ID that
auditorium enables measurement of member pathing as they
switch from row to row.
channel ID Refers to the channel that the chat room was
featured in. Enables channel name to be
associated with the channel ID based on the
channel_lookup table from Usage Reporting
Center (URC).
partner ID Refers the advertiser or partner that hosted the
chat event. Enables advertiser/partner name to be
associated with the partner ID based on the
partner_name table from Partner Information
Resource System (PIRS).
member BID ID Identifies the member BID; enables reporting of
US member chat usage.
member country ID Identifies the member's country code.


Type Description
member service Identifies whether the user is an AOL member,
type number CompuServe member, AIM member, or
Netscape.
screen name Identifies the member’s screen name
brandi ID Identifies the brandi ID which is a a field in the
Master File that is also recorded inq_context, that
describes what service and what subset of that
service a member has.
closed_group Identifies a bit in the q_contex file which is used
along with brandi ID to identify a Starbright
account


Appendix A:
Configuration Information
The chat_system.tcl file contains configuration information of various

kinds.
Chat Configuration and SM_subs

The chat_sm_initial_room.tcl file is an SM_subs dataset that lets the initial
room (lobby) for a given user to be selected using most fields in q_context.
The chat_sm_cat_list.tcl file contains all chat_system_bid_category_order

statements.
Chat configurability is enhanced through the use of Service Mapping

(SM_subs), a SOML subroutine package created for storing and looking up
configuration information that varies by one or more key values in
q_context. Some likely key values include Brandi, service type, member
country code, client country code, and UI Group ID. The configuration
information is name/value pairs, where the values can be text or numbers.
The configuration information that SM_subs uses is defined entirely in tcl

files. There can be multiple, separate such tcl files, some of which can be
subsystem-specific. For example, there could be one for system-wide
information, one for newsgroups, and one for mail. One notable feature of
SM_subs is that the key value(s) used can be changed in the tcl file, without
rebuilding the server(s).
For more information about SM_subs, see the Service Mapping

Subroutines (SM_subs) web pages at the Host Development documentation
library at Keyword: techdoc.

December 2000
TCL Configuration Summary

Table A-1 summarizes the principal chat configuration information in the
chat_system.tcl file:
Table A-1: Chat Configuration Information

Type Description
global ID and chat_system_base_gid and chat_system_cap_gid
stream ID define the global ranges assigned to the chat system;
range
chat_system_base_sid and chat_system_cap_sid
define the stream ranges for the chat system
global ID and num_gids_per_server describes the number of global
stream ID IDs per server;
number
num_sids_per_server describes the number of stream
IDs per server;
physical chat_system_common_server names the queue name
queue name for each non-podded server
of common
non-podded
servers
physical chat_system_podded_server identifies the pod and
queue name queue name for each podded server
of podded
servers
generic queue chat_system_generic_server names the generic queue
name (for example, the tih queue or edit_token queue)
names in the chat system, and the corresponding
physical queue names
chat provider chat_system_chat_provider IDs of 1 refer to classic
ID and chat rooms; chat_system_chat_provider IDs of 2 refer
generic queue to auditoriums;
name
switch servers chat_system_switch_server describes the generic
queue name of the chat switch (chat_sw) servers
lobby name chat_system_lobby_name_server describes the
servers generic queue name of the chat_namelob servers
physical chat_system_fan_server describes the physical queue
queue name name of the chat_fan for each chat provider server
of the
chat_fan
servers

December 2000 Overview of the Chat Subsystem, Rel. 4.1

Type Description
category chat_system_category_name describes the name for
name and each category; the number is the canned text ID in the
description chat_category.ct file, giving the category’s
description in the various international languages; the
string is an English description
chat_list chat_system_category_list_server describes the
generic server chat_list generic server that handles each category
category view chat_system_category_viewrule describes the view
rule rule that controls access to each category; the view
rule may be specified either by number or name
category chat_system_bid_category_order describes the order
order for each business ID (BID) in which categories are
visible to members
search servers that receive information about the open chat
gatherer rooms and the actual text of chats; chat providers and
server chat fans communicate with the search gatherer
servers and their data feeds into the search subsystem.
The room information and del_room_info messages
from the chat_providers and the chat_msg messages
from the chat_fans are stored in memory in the
chat_search server. Once a minute (configurable) the
chat_search server creates a PLS container file
including the last 3 minutes (also configurable) of
conversation.These files are then indexed once a
minute using a shell script and cpltestmt (PLS
technology).
chat ball chat_system_chat_ball_servers provides a list of Chat
server ball servers
nav ball chat_system_nav_ball_servers provides a list of Nav
server ball servers
configuration chat_system_config_servers provides a list of chat
server configuration servers
robust room rrb_add_block_item <ctry_code> <block_string>
blocking (rrb) <member_attr> <private_attr> adds an item to the
block list. The item disappears as soon as chat_rrb is
bounced, as it is not contained in the rrb database.
rrb_is_blocked <room_name> returns a list of
country codes for which 'room_name' is blocked.
rrb_list_dbs lists the database indexes that chat_rrb is
currently configured to talk to.

December 2000

Type Description
rrb_add_except_item <ctry_code> <except_string>
<member_attr> <private_attr> adds an item to the
exception list. The item disappears as soon as
chat_rrb is bounced, as it is not contained in the rrb
database.
rrb_stats displays statistics about requests that
chat_rrb has processed.
rrb_delete_except_item <ctry_code> <except_str>
<except_member> <except_private> deletes private,
member, or both attributes for a particular exception
list item.
rrb_add_db <db_index> Adds a database index for
chat_rrb to use.
rrb_delete_block_item <ctry_code> <block_str>
<block_member> <block_private> deletes private,
member, or both attributes for a particular block list
item.
rrb_db_stats prints histogram chart on database
transaction times and also shows the number of
database read successes and failures.
chat_system_category_country_code specifies an
owner of a category. (For example,
chat_system_category_country_code {37,2,21} US.
chat_private_room_country_code_sensitive is a
variable; if this value is set to 1 it means that if a
private room is blocked for any country code, it is
blocked for all country codes.
chat_prov_add_rrb_server adds a chat robust room
block queue name.
chat_prov_del_rrb_server deletes a chat robust room
block queue name.
chat_prov_list_rrb_server lists robust room block
queue names
chat entry chat_channel.tcl contains channel config entries.
message
chat_partner.tcl :contains partner config entries.
cpc_room_config_category.tcl calls
cpc_room_config_member_private.tcl.
pc_room_config_partner.tcl contains default
attributes for partners such as entry room message.

December 2000 Overview of the Chat Subsystem, Rel. 4.1

Type Description
ccpc_room_config_channel.tcl contains default
attributes for channels such as entry room message.
chat_fan chat_sl_enable_stats_log (Boolean) is a flag that
statistics controls whether chat_fan sends event data to
chat_logger. If the flag is set to true, chat_fan sends
event data to chat_logger; otherwise, chat_fan does
not send event information. The default value is:
TRUE
chat_sl_send_msg_type (Int ) is a message type that
chat_fan uses to send event message.
Note: The value of message type must be defined in

$TOP/include/message_types.h file, also it must be
same as the message type defined in
chat_logger_pre.tcl. The default value is: 103
(msg_interprocess_request).
chat_sl_null_pad_str_for_logger is the padding string
for a NULL field for chat_logger. The default value
is: ' ' (space).
chat_sl_null_pad_num_for_logger (Int ) is the
padding number for a NULL field for
chat_logger.default value is: -1
chat_sl_delimit_for_logger (string ) is the delimit for
the formatted log message. The default value is: ';'.
chat_sl_log_name_prefix_for_marketing is the prefix
for event log file (event data generated based on
marketing people's request). The default value is:
'chat_mkt'.
chat_sl_chat_logger_queue_name (string) is the
chat_logger's queue name that chat_fan (or other chat
server) talks to. The default value is: 'chat_logger'
chat_sl lists chat stats to logger commands
chat_sl_info lists tag/version, configuation, and
commands for chat_sl.
chat_logger chat_lg_append_newline (Boolean) is a flag to
statistics control whether a newline needs to append to the log
record. The default value is: TRUE.
chat_lg_num_of_iov_per_write (Int) is the number of
IOVs per write for log buffer. Its range is 1 - 16.
default vaule is: 15.

December 2000

Type Description
chat_lg_change_log_file_interval_in_mins is the time
interval for change log file. Its range is 1 - 60*24*7
mins. The default value is 60 mins.
chat_lg_check_error_interval_in_mins (Int) is the
time interval to check error condition after an error
occures. The default value is 5 mins.
chat_lg_rec_msg_type (Int) is the message type that
chat_logger receives from the other server. The
default value is: 103 (msg_interprocess_request).
chat_logger chat_logger lists the chat_logger tcl commands
tcl commands
chat_logger_info lists the tag/version, configuration,
and commands for chat_logger.
chat_logger_stats lists chat_logger log stats.

chat_logger_zero resets chat_logger log stats.
chat_logger_add_dir adds a directory to chat_logger's
dir list. chat_logger_del_dir marks the specified dir as
deleted. chat_logger_show_dir displays chat_logger's
dir list. chat_logger_show_config displays
chat_logger's config parameters.
chat_logger_show_filelist displays chat_logger's
currently opened file list. chat_logger_shutdown
shutdown chat_logger. chat_logger_stop_log changes
its internal state to 'STOP', and stop logging in case
operation people need to stop logging for some
reason. After the stop_log is issued, all incoming
messages are dropped. chat_logger_start_log changes
its internal state to 'work', and start to log. This is
used after stop_log is issued or an error occured.

Index
A C
adb_switcher category
description, 7 name and descripti o n45,
auditorium order, 45
commands from chat input line, 25 view rule, 45
description, 3 chat
entry, 25 _config, 8
functions, 23 _fan, 8
initialization, 24 statistics, 47
authorizer verification, 31
description, 7 _list, 8
generic server, 45
B
_logger, 8
ball
statistics, 47
BOS, 7
tcl commands, 48
bucky, 7
_namelob, 8
chat, 7
_namesrv, 8
Nav, 10
_nav_request_prereservation_func_id, 29
BERP
_prov_aud, 8
description, 7
_prov_classic, 8
BOS
_prov_ecr, 9
ball, 7
_rrb, 9
bucky
_sm_cat_list.tcl, 43
ball, 7
_sm_initial_room.tcl, 43
buttons
_sw, 9
Find a Chat, 15
_system.tcl file
List More, 15
entering room, 20
List Sanctioned and Member Chat
_system_bid_category_order, 43
Rooms, 15
ball
People Connection, 15
description, 7
Search All Member Chats, 15
server list, 45
Who’s Chatting, 15

entry message description, 7

configuration, 46 Find a Chat
provider how to, 15
auditorium, 23 FLAP (Frame Layer Protocol)
chat_prov_ecr, 9 description, 10
complex, 8
directed room entry, 22 G
entering room, 19 grog
exiting room, 21 description, 10
ID generic queue name, 44 I
member count, 38 ID
restart notification, 37 global and stream
statistics (chat_stats) number, 44
chat element definitions, 39 range, 44
description, 38 initialization
verification, 31 auditoriums, 24
chimps chat provider server, 12
description, 9 inter-server requests
Community Action Team (CAT) acknowledgement, 35
chat verification, 31
configuration K
server, 45 keyword
chat, 3
D finding room, 15
design People Connection, 4
components and processes ,5
initialization, 12 L
naming conventions, 11 List More
optional room characteristics, 14 how to, 15
dracula
M
description, 10
mail_send
E description, 10
enhanced conference room (ECR) member counts
description, 4 description, 38
error recovery modem
types, 35 point of presence (POP), 11
F N
FEP (frontend processor) naming

conventions, 11 SM_subs, 43
nav queue name
ball generic, 44
description, 10 chat provider ID, 44
server list, 45 physical
networks, public data, 11 chat_fan servers, 44
notify AOL non-podded servers, 44
verification, 31
R
O rat report
operational description, 31
error recovery ,35 fields, 33
inter-server requests, 35 recovery/restart
lost unplugs, 35 member counts, 38
periodic status updates, 36 notification, 37
chat switch to room name, 36 server crash, 37
room name to chat provider , 36 server ID ,38
recovery from server crash/restart, 37 Who’s in Room, 38
OSCAR robust room blocking (rrb)
client configuration, 45
authorization, 26 functions, 22
entry and participation, 28 server description, 9
description, 10 room
auditorium, 3
P
capacity, 14
PCL
conference, 4
description, 10
description, 3
People Connection
enhanced conference room (ECR), 4
button, 4
entering, 17
finding, 15
exiting, 18, 32
room, 4
finding by name ,15
physical
heavily used ,14
queue name
maximum name length, 14
podded servers, 44
People Connection, 4
plus group
plus group, 14
description, 14
replicatible, 14
Public Data Network/modem, 11
S
Q
search
q_context

_ gatherer verification, 33
description, 11 _AE
all member chats ,15 chat notify, 32
gatherer server token
configuration, 45 room entry, 9
server
ID U
restarts, 38 unplugs
lobby name ,44 lost, 35
switch, 44 user
service replication, 14
_request, 29 usher
Service Mapping (SM_subs) description, 9
chat_sm_cat_list.tcl, 43 V
chat_sm_initial_room.tcl, 43 verification
SNAC Verification Sybase
SOML
SM_subs, 43 W
suffix WERP
use, 14 description, 11
Sybase whiscer
rat report, 31 description, 11
verification, 11 Who’s Chatting
description, 15
T Who’s in Room
TOKEN description, 38
_AD

Chat Arch

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Chat Arch

Caricato da

Copyright:

Formati disponibili

AMERICA ONLINE

Overview of the Chat

Document Number: Project ID 9971

AOL Security Class: Confidential

Note: Applicable nondisclosure agreements must be in force for you to be authorized.

© Copyright 2000 America Online, Inc. All rights reserved.

Functions and Event Flows for AOL Clients . . . . . . . . . . . . . . . . . . . . 15

OSCAR Client Integration in AOL Chats. . . . . . . . . . . . . . . . . . . . . . . . 25

© America Online, Inc. 2000 1 America Online Confidential

Error Recovery ......................................................................................... 35

Chat Configuration and SM_subs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

TCL Configuration Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

America Online Confidential 2 © America Online, Inc. 2000

Figure 1: Components and Processes......................................................................................... 6

© America Online, Inc. 2000 1 America Online Confidential

Overview of the Chat

The chat subsystem allows members to participate in online chats in chat

The chat subsystem integrates Open System for Communication Access in

Chat configurability is enhanced through the use of Service Mapping

Chat verification functionality lets members easily report Terms of Service

This document contains describes the following aspects of the chat

• Functions and Event Flows for AOL Clients on page 15

• OSCAR Client Integration in AOL Chats on page 25

• Chat Verification on page 31

• Operational Information on page 35

© America Online, Inc. 2000 2 America Online Confidential

• Auditoriums that allow large audiences to attend special events

• Enhanced conference rooms (ECR) that allow members to attend chats

The chat subsystem consists of different chat complexes, each of which

Auditoriums Allow a large audience to attend special events

© America Online, Inc. 2000 3 America Online Confidential

Conference rooms Allow members to chat in a setting of up to 47

Enhanced conference Allow members to attend chats held in an

People Connection Allow members to join chat rooms of up to 23

There are three types of rooms in People

• Sanctioned (public)—AOL-created rooms

• Member—member-created rooms that appear

• Private rooms—member-created rooms that

America Online Confidential 4 © America Online, Inc. 2000

Who Should Use This Technical Note

For information on the host components of AOLTV, see the AOL TV

© America Online, Inc. 2000 5 America Online Confidential

Components and Processes

chat_fan chat_fan chat_fan

adb_ Bucky balls

Figure 1: Components and Processes

America Online Confidential 6 © America Online, Inc. 2000

The chat subsystem processes and components are described as follows:

adb_switcher A standalone process that sends the chat_fan

Authorizer A server that authorizes an OSCAR client by

BERP A UNIX-based back-end routing processor

BOS ball The Bucky Ball server that implements Basic

Bucky ball A single instance of a server that implements a

© America Online, Inc. 2000 7 America Online Confidential

chat provider complex A grouping of processes consisting of a type of

chat_config A standalone UNIX process that maintains room

chat_fan A UNIX process chat functions as the chat

chat_list A podded UNIX process that members can

chat_logger A server that receives formatted (ascii) room

chat_namelob A switched UNIX process that controls entry into

chat_namesrv A UNIX process of normal room entry and

chat_prov_aud A UNIX chat provider process with the