Chat rooms work with any Java-enabled browser. A chat
room is part of a normal browser page, so you can use standard HTML to
place advertisements or other material around the chat area.
| Operations Documentation | Non-Programmer's Guide | General Information | WCMS Operation | Chat | Specialized Interfaces | Software Development & Scripting |
Visit the
Chat rooms work with any Java-enabled browser. A chat
room is part of a normal browser page, so you can use standard HTML to
place advertisements or other material around the chat area.
You can provide multiple "tables" per room or
cafe, so users can table hop to find interesting places.
WebX can create overflow tables automatically, so a single table
doesn't get too large (e.g. you might choose to start a new table every 50 users).
You can see a list of users at your current table, and a count of
read-only lurkers.
You can send private
messages to other users at your table.
You can invite other users
to enter a private 1-on-1 table.
Hosts can eject obnoxious users.
Hosts can broadcast to all
users in a room regardless of their table.
Access lists are part of
each chat table, so you can restrict access as desired.
Access rights can be host (read/write/eject/broadcast), participant
(read/write), read-only, or none. Web Crossing registration/login is used
to authenticate registered users. Unregistered guests can have separate
access rights, and can be totally excluded if desired.
Automatic e-mail validation is available for new users.
In conjunction with access lists, this allows you to control your community and
to eject people if required.
User's can select their own message color to be used for displaying
their messages to all users in the chat room.
Essentially unlimited number of users,
depending on your license, by setting up multiple
cooperating fanout servers. The design goal for chat is to run with 100,000
simultaneous users.
For a hosted
auditorium-style event, each end-user can be in two chat
rooms simultaneously: one (read/only) in which the guest is speaking, and
one (read/write) in which they can converse and ask questions of the guest.
Chat monitors in the various read/write end-user rooms forward questions to
the speaker in a separate (private) chat area, from which the speaker can
choose the questions to which to respond.
Java source-code for the
client is available for license.
A room with one table
In a room with one table, users don't see the table per se. They come into the room and talk, and the table and the room merge into one place.
Sample interface with one table
The default chat room layout shows the chat messages on the left, a list of users at the table on the right, a place to type a new message below, and a pull-down menu of commands. The room layout is highly configurable to match your needs on a room-by-room basis.
The pull-down menu allows users to send private messages, ignore a bozo user, or invite someone to join them in a private room. Chat room hosts can also eject users who are not adhering to the community guidelines.
A room with multiple tables
In a room with multiple tables, a user enters the room and joins one of the tables. He or she can then table hop to check out other discussions.
Sample interface with multiple tables
In the default interface, a list of tables is shown at the top right. Clicking on a table name will move the user to that table. You can chose to configure the room without the list of tables, and users can still table-hop via the pull-down menu.
In a multiple-table room, chat hosts can broadcast messages to all of the tables.
The Web Crossing server accepts Web (HTTP) requests originating at the user's Web browser, and returns HTML pages for display to the user.
The Control Room manages and allocates all of the chat resources. The Web Crossing server sends user requests to enter a chat room to the Control Room, and gets back information about how the user is to connect to the room.
Fanout Servers actually handle chat room messages. A Java APPLET running on the user's machine will make a TCP/IP connection to a Fanout Server to actually enter a chat room.
Single server chat configuration
In this configuration, a single Web Crossing server is providing both discussion and chat services.
In a distributed environment, there is a single Control Room to manage all chat room assignments, but you can have as many Web Crossing and Fanout Servers as required:
Distributed server chat configuration
In a distributed environment, the various servers communicate through TCP/IP connections instead of through an internal communications channel. The Control Room server may still include a Web Crossing and/or a Fanout Server if desired.
Note that each server may run on a separate machine, or may run as another process on the same machine. Most Unix systems limit the number of TCP/IP connections per process to 256, in which case multiple processes are required to support more than 256 users. You specify the maximum number of TCP/IP connections for each fanout server as part of its configuration setup, so you can tailor this to your hardware and software capabilities.
The control room always places users in the same room on the same fanout server, until that fanout server reaches its TCP/IP connection limit. Then the control room connects additional fanout servers together in a ring architecture to allow more users to join that chat room.
The Control Room uses two ports, one for Web Crossing server connections and the other for Fanout Server connections.
Each Fanout Server uses two ports, one for clients to call and join a chat room, the other to accept connections from other fanout servers. You can have multiple Fanout Servers running on the same machine, as long as they each have their own unique port assignments.
Due to Java security requirements, applets must be downloaded from the same IP address that they will use to connect to their Fanout Server. So the configuration setup for each Fanout Server includes the URL to be used to download Java applets for that server, allowing you to ensure that this requirement is met.
Communications data flow
When a URL linking to a chat room is received, the Web Crossing service requests the Control Room to assign a Fanout Server for the user. The Control Room responds with the information required for the Java APPLET tag, and the Web Crossing service then constructs and returns the HTML page to enter the chat room.
The control room also tells the assigned Fanout Server about the chat client, so that when the client calls the Fanout Server the call is authorized and the user enters the correct room with the proper access rights.
On the client side, the returned page includes a Java APPLET tag. The user's Web browser will download the applet from the server and start it running. The applet then calls the Fanout Server to enter the chat room.
After configuring this Web Crossing server to include chat services, you will see an Add Chat button in the sysop toolbar. Click this button to create a new chat room, then click on the room to enter it and chat.
Note that a chat certificate is only required on the Control Room server. All of the Fanout Servers will automatically share this certificate. (A Web Crossing discussion certificate is required on each Web Crossing server that is also providing discussion services.)
A typical SOCKS-enabled configuration
In this diagram, the control room connects to both fanout servers, in order to place users into the correct fanout server. The two fanout servers are connected together so that chat messages flow between them, and thus between the chat users inside and outside the firewall.
To set up chat across a firewall, you must perform the following steps:
Now, users in the socks group will normally enter the chat room through the SOCKS firewall. They will also have the ability to enter the chat rooms when they are at a computer outside the firewall, by clicking on the [Enter from outside the firewall] link next to each chat room. Users who are not in the socks group always enter the chat rooms from outside the firewall.
You can manage access to the chat rooms in other ways by using the Web Crossing Template Language.
You must also configure this same server to provide direct HTTP service on port 80, so that the Java client can be downloaded from the same IP address as the chat service (required by Java security rules on the client).
Recommended settings for Web (HTTP) service is to set port to 80, and the directory for HTML files to the Images directory. This will prevent any files in the Web Crossing server directory from being served.
Also set the chat fanout client port to 80, and set the Java applet URL to pick up files directly from WBChat (assuming you've configured the base HTTP directory to be Images, as suggested above).
After you've added a room, you just click on the room to enter it and chat. You will also see an Edit button next to the link to the room. You can click on this Edit button to change the room/table settings, including its access list. There is also a delete button at the end of the Edit Chat Room form.
Note that the Edit button only shows for hosts and the sysop. It does not show for regular users.
Step 2. To add tables to the new room, you first need to get the unique ID of the room. You can get this from the URL used to enter or edit the chat room. For example, if you click on the Edit button, the URL you visit will look something like the following:
Copy the chat room unique ID to the clipboard so it is available later.
Step 3. Create another room using the Add Chat button, and make its title the name of a table in the room. Click on the OK button.
Step 4. Click on the Edit button next to the table entry, paste the chat room unique ID into the Common room field, and click on the OK button at the bottom of the form.
Repeat steps 3 and 4 as often as desired.
When a user click on the link to a table, they will join the discussion in progress that table, and will be able to hop to other tables if they choose.
As overflow tables are created, users can table-hop to all of the tables, including overflow tables.
To set the overflow table count, use the Edit Chat Room form by clicking on the Edit button next to the chat room.
| Access | Rights |
|---|---|
| host | read/write/eject/broadcast |
| participant | read/write |
| read/only | read-only lurker |
| moderated | automatic moderation of "bad" words |
| none | no access at all.
A user with no access rights will not even see the chat room or table. |
To attach an Access List to a specific chat room or table, click on the Edit button to the right of the link, then click on the Access List button at the bottom of the form and follow directions in the form.
You can also attach an access list to a folder containing multiple chat rooms and/or tables. The access list for a folder will apply to all chat rooms and tables in that folder and all nested folders. If a chat room/table has its own access list, then that access list completely overrides any containing folder's access list.
Many sites limit access to registered users. By excluding guest users, you can control membership in your community and ensure that everyone has a positive experience. Instead of setting access lists on each table or folder, you can completely exclude guest users from your site through the sysop Control Panel, using the Guest User Access form.
Through the use of the "Moderated Word List" located in the "General Settings" panel of the Web Crossing sysop control panel, moderated rooms will automatically disallow the use of any of these words on the list. Anytime a user types a "moderated" word, the message is returned to the user with a warning prepended to it. For example, if a user types "bad word," the chat server will return the following message only to the originating user: "Possible objectionable message NOT sent: "bad word" ".
To run a hosted event in Web Crossing, you need to create three chat tables:
Each member of the audience is in two tables: the host table (as read/only), and an audience table (as read/write).
Each chat host is in two tables: the audience table, and the backstage table. Actually, as audience tables overflow, each chat monitors may have multiple overflow tables up, scanning them all for messages to pass to the host. Chat monitors can also broadcast messages to the audience tables as desired.
To set up pages with multiple tables in them or make other changes, see the Customizing your chat room section of the SDK documentation.
You can set up a chat table to playback a recording on either a one-time or continuous loopback basis. Use the Playback fields in the Edit Chat Room form.
Note that in a multiple-table room, the status panel just shows initial entry counts, not current usage after any table hopping.
With e-mail validation turned on, new users are marked as provisional and an e-mail message is sent to them. A user confirms his/her address by replying to the message. Upon receipt of the reply, Web Crossing upgrades the user to have the full access rights of a registered user.
You can enable this feature through the sysop Register user access panel. The content and layout of the e-mail validation message can be specified by you.
If you enable this feature, you must regularly check the logEmail file, in the same directory as the webx.db database, for any problems that need to be handled manually.
In conjunction with automatic e-mail validation, you can specify a list of e-mail addresses or domains that are not allowed register. This allows you to eject disruptive users and keep them out permanently and automatically (until they get a new e-mail address). To permanently eject someone with a specific e-mail address, use the List of e-mail addresses that cannot auto-register setting at the end of the Registered user access panel.
The methodology is to run additional copies of Web Crossing on other machines in your network or on the Internet. Each of these additional copies can be instructed to emulate actual users, with each of the emulated users periodically sending messages and table hopping. While these emulated users are running, you can enter the same chat room and confirm that it is responsive.
To start running emulated users, you need to configure a Port for direct database access in the sysop General Settings panel on the control room Web Crossing server. This direct-access service is called by each test user to enter the chat room.
Then send the following URL to your test Web Crossing servers:
where
For example:
will start one test user, calls the control room at 38.8.21.2:5000 to get the room setup, enters the <.ee6b345> table, starts within a 1 minute interval, runs for 5 minutes, shuts down within one minute of the 5 minute run interval, sends a message every 3 seconds on average, and table hops every 60 seconds on average.
You can send multiple test user URLs to the same test server, and each set of users will run simultaneously.
To shut down all test users, send the following URL to each test server:
There are 2 known limitations under Windows or Macintosh (but not on Unix):
As a result of these two limits, you may well see in the status panel that not all the users you were expecting actually arrived. (The log file will indicate what happened to each test user, and will also tell the number of messages sent and table hops taken.)
You may want to add 50 to 100 users at a time with a very long run time and see how the server load looks. You can add more users on the user test server(s) as often as you like, and the prior ones will continue to run.