From: Technical Documentation

America Online, Inc.

Re: Technical Note: Multiple Servers Writing to a Single Form Attached is the Multiple Servers Writing to a Single Form technical note.

This technical note describes the process of multiple servers writing to a single form. The server types are discussed and developer’s notes are provided.

Please remember that only those who have signed the America Online Non-Disclosure Agreement may see this technical note.

Thank you.

Attachment

AMERICA ONLINE

TECHNICAL NOTE

Multiple Servers Writing to a Single Form

May 1997

Technical Note: Multiple Servers Writing to a Single Form

May 1997

Document Number: AOL-C-DEV-1087T

AOL Security Class: America Online Confidential

Distribution: Authorized Licensees and Internal America Online Staff Only

Note: Applicable non-disclosure agreements must be in force for you to be authorized.

Ó Copyright 1997 America Online, Inc. All rights reserved.

This manual contains valuable confidential and proprietary information of America Online, Inc. No part of this manual 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 manual is subject to applicable license agreements and non-disclosure agreements. Unless specifically otherwise agreed in writing, all rights, title, and interest to this software and documentation remain with America Online.

Information in this manual 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 manual. In no event will America Online be liable for direct, indirect, special, incidental, or consequential damages resulting from any defect or omission in this manual, 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 manual and the products it describes at any time, without notice or obligation.

The following are registered trademarks or servicemarks of America Online, Inc.: America Online, People Connection, Q-Link, PC-Link, StockLink, Download Manager, Sketchpad, Flashmail and FlashSessions. All other product names and service names referenced herein are trademarks or servicemarks of their respective companies.

Published by

America Online, Inc.

8619 Westwood Center Drive

Vienna, Virginia 22182-2285

Phone: (703) 448-8700

Fax: (703) 918-2304

Printed in the United States of America

Table of Contents

Server Types 2

Developer’s Notes 3

Strobe Messaging 5

Technical Note:

Multiple Servers Writing to a Single Form With evolving technology and capabilities, America Online has become sophisticated in the ways that information can be rendered on forms in the online service. Currently, a number of forms on America Online have a minimum of two or three servers communicating with them at all times.

Forms are the windows, or screens, that appear online. A form can contain text for members to read, blank spaces where members type information, or buttons, which are the objects that members click on with a mouse to perform actions. For additional information about form design, see the America Online manual Building an Online Service.

This technical note discusses the types of servers that send data to forms. Servers are processes that interact with each other to make up the online service that members access. Each server process performs a specific function, such as handling downloads (the download process) or managing sessions with remote host applications (the gateway process). For additional information about host processes, see the America Online manual Host Online Processes.

This technical note also provides details, including sample FDO91 streams, that you must consider to ensure that multiple servers can write their data to a single form. For additional information about writing FDO91 streams, see the America Online FDO91 Manual.

This technical note is intended to serve only as an overview of the information that you as a developer need to consider when programming multiple servers to write to a single form. An automated process is planned to streamline this function. However, an exact delivery date for this automated process has not been determined. Server Types America Online uses various server types to provide the functionality members see online. Forms on America Online are rendered by the following server types: rmg Provides a series of customized forms developed by the online service and the information provider. While the actual data resides on the information provider’s computer, the forms reside on the America Online host computer.

retriever Accesses the forms database to supply forms to the client computer.

dod Manages the storage of art and forms for the online service. It also handles client computer requests for forms stored in the host databases. Considered an unsolicited server because the wait cursor is turned off on all its forms.

ad_display Supports ad displays in various areas of the online service. Ads are often rotated on a predetermined basis. Considered an unsolicited server because the wait cursor is turned off on all its forms.

quote_form Displays continuously updated stock quotes on forms. Considered an unsolicited server because the wait cursor is turned off on all its forms.

pageman Adds content to forms that have already been created by other servers. For additional information about host server processes, see the America Online manual Host Online Processes. For additional information about the architecture of the host system, see the America Online manual Host Subsystems.

Figure 1 contains an example of three servers writing to a single form:

Figure 1 – AOL Personal Finance Screen

Following is a discussion about guidelines that you as a developer must consider when programming multiple servers to write to a single form. Developer’s Notes As a developer, you should be aware of the following details when programming multiple servers to write to a single form: With a canned forms server, you only need one global ID because you use only one iteration of the form. With canned forms, if you do not supply a global ID on the form, the server supplies it for you when the data is sent down to the server. All unsolicited servers need a set of unique, reserved stream IDs. You need to reserve a range of stream IDs that your server can cycle, or you can limit yourself to using one instance of the form. Contact Lu Lu to discuss your particular application and to reserve a range of stream IDs. A canned forms server does not send data if the global ID does not exist. If the global ID cannot be located, the server ignores the rest of the packet. When two servers are writing to a main form, ensure that the wait cursor is turned off by the main form. With the Casablanca 4.0 client, use reserved stream IDs above 16 million so that the watchdog timer is not reset within the client. Contact David Lippke to ensure that your tokens are registered with tih. You must register your tokens to ensure that they circumvent the forms timer. pageman creates its own global IDs for its forms. Ensure that all servers writing to a single form have a unique stream ID. Otherwise, your stream may be put on hold while another stream with a higher priority on the client is being processed. The following atom streams are presented as example code for you to use in your own servers. Comments are included in the code where customization is needed.

The stream to send the token to the server requesting the display appears as follows (Note that this stream can be on the form in a post-stream or it can be sent by the servers.):

atom$uni_start_stream

atom$buf_start_buffer 159

atom$buf_set_token "xx" # Needs customization.

atom$buf_add_atom_pointer_ascii "101,1;105,2" # Needs customization.

atom$de_start_extraction

atom$buf_set_data_atom 1 9

atom$de_set_data_type datatype_global_id

atom$de_get_data_value 1

atom$uni_use_last_atom_value 4 2

atom$de_end_extraction

atom$buf_close_buffer

atom$uni_end_stream

Figure 2 – Token Stream

To send data to a form from the server, you must send certain data streams to the client.

The pre-stream sent before the data appears as follows:

atom$uni_start_stream

atom$man_set_context_globalid <GID>

atom$man_is_rendered

atom$if_last_return_true_then 1

atom$man_clear_relative <RID> #RID is the relative ID of the field.

atom$uni_sync_skip 1

atom$man_set_context_relative <RID>

# Anything the server needs to do to prep the fields goes here.

atom$man_append_data

atom$man_end_context

atom$man_end_context

atom$uni_end_stream

Figure 3 – Pre-Stream Data

The data stream should be sent with the following stream:

atom$man_set_context_globalid <GID>

atom$man_set_context_relative <RID>

atom$man_append_data <your data up to 95 bytes>

atom$man_end_context

atom$man_end_context

Figure 4 – Data Stream

If your data stream contains more data than the packet can hold, you must send additional packets. You must also send packets containing data within a range of stream IDs.

For information about sending multiple packets of data, see the following section, "Strobe Messaging." Strobe Messaging A strobe message, which is similar to a queue message, is sent behind a server’s data to the tih buffer. It is used to ensure that data sent to the client is in the correct format and as a way for the client to more effectively handle incoming data. When the data clears the tih buffer, tih notifies the sending server that it is ready to receive more data. If you do not use strobe messaging, your data is held in the tih buffer and other servers sending data will queue up behind your data. If you are sending a long file without strobe messaging, you cannot do anything else on the client until the entire file is received.

Figure 5 shows the sequence of events when tih sends a strobe message:

Figure 5 – Event Flow: Strobe Messaging

The sequence of events is described as follows: 1. tih receives and processes a request from client connections.

2. tih sends the request to the berp for routing to multiple servers.

3. The berp routes the data to the multiple servers. The multiple servers write out packetized data with a strobe message appended to the end and route it to the berp. The berp passes the data and the strobe message to the tih buffer where it is held in a queue. The data being held in the tih buffer is passed down to the client. tih notifies the other servers that it is ready to receive more data when all current data in its buffer has cleared. Note that additional data delivery from the multiple servers to tih is suspended until Step 7 is completed.