Chapter 10 - StreetTalk Directory Assistance Services
StreetTalk Directory Assistance (STDA) is a companion service to StreetTalk that allows you to find and display the StreetTalk names of users, lists, print and file services, and any other object entered into the StreetTalk database.
Like StreetTalk services, STDA services are maintained on individual servers, although not every server in a network needs to have an STDA service on it.
Determining what information to collect and display to individual users or groups is your primary task as an administrator of STDA services.
There are two types of STDA services: master and satellite. These services work together to maintain and distribute STDA database information across the network.
Master services retrieve user names, list names, service names and nicknames from StreetTalk services, and construct a comprehensive database. When you create and start a master service, you also designate which servers you want it to poll for StreetTalk information.
Satellite services gather or download databases from master services as well as from other satellite services, and build a database designed to present a particular view of the network and its resources for users.
Both master and satellite services can be configured to arrange the data they gather for presentation to other services or viewers; however, satellite services are typically used for this task. For more information, see "Displaying Information" later in this chapter.
Master services gather StreetTalk information directly from StreetTalk databases located on Banyan servers. The process is referred to as enumeration. Enumeration occurs immediately after the service is started for the first time and continues after the database is built..
You can create as many master services as your network needs and instruct each service to poll individual StreetTalk services on the network, collecting information from any or all of them.
Master services collect (enumerate) data in the following way:
The master service visits each target server throughout the day until it collects all group data maintained by the StreetTalk service on that server. Any changes that have occurred in the targeted StreetTalk databases since the last collection time are added to the master service's database. At a time specified by the administrator, the master service rebuilds, incorporating the changes into a new database. Between rebuilds, satellite services downloading information from master services receive the most current version of the master service's database, including any changes collected since the last rebuild.
Unlike master services, satellites cannot collect information directly from StreetTalk services. Instead, satellite services download StreetTalk information from both master and other satellite services.
While master services are configured to collect large amounts of information frequently from scattered locations, satellite services are used primarily to collect information for presentation to users at local sites and for further distribution to other satellite services.
Satellite services download StreetTalk data from master services and rebuild their databases only at times specified by the administrator. When the rebuild occurs, any changes are incorporated into the rebuilt database.
As an administrator, you can create as many satellite services as your network needs. Each satellite service can be instructed to gather information from any or all of the master and satellite services.
Master and satellite services are generally organized into hierarchies with the master services at the top and the satellite services beneath them. The master services collect information and make it available to satellites, which in turn are downloaded by satellites beneath them in the hierarchy.
Unless you administer a very small network, you generally create several master services, each of which collects data from a specific set of StreetTalk services. Often all of the masters are downloaded by one or more concentrator satellites, creating multiple and redundant views of the network. These concentrator satellites are used in turn as resources by the remaining satellites, which download and filter data from them for presentation to users. For more information on concentrator satellites, see the section "Satellite Configuration Guidelines" later in this chapter.
This hierarchical organization is shown in Figure 10-1.
Inclusions, Exclusions, and Exceptions
You can customize the database of a master or satellite service with inclusion, exclusion, and exception parameters.
See Chapter 11 for the procedures on customizing an STDA database.
Inclusions -- Let you include StreetTalk and non-StreetTalk names in the database of an STDA master or satellite service. Non-StreetTalk names typically include those of users on other networks with mail gateway addresses. You can view and search for those names just as if they were StreetTalk names. After an inclusions file is submitted to an STDA service, the service rebuilds and the inclusion data is added to the service's database. When the rebuild is complete, the inclusion data is sent as part of the database whenever an STDA satellite service downloads data from the service.
Note: STDA inclusion names support the same characters in the same way as the StreetTalk Naming service.
StreetTalk and inclusion names for both master and satellite services are collected and filtered according to a set of exclusion and exception parameters specified by the administrator. These parameters are entered into an editing dialog box (StreetTalk Explorer) or a screen in the MSERVICE program associated with the STDA service you are managing.
Exclusions - Let you exclude StreetTalk names that match a particular pattern. Exclusion patterns are based on the structure of StreetTalk names.
A typical exclusion might be S*@Chicago Sales@WCTUS. This pattern excludes all StreetTalk names beginning with the letter S from the group Chicago Sales. Similarly, the exclusion parameter *@WCTUS excludes all groups at WCTUS.
Exceptions - Let you make exceptions of certain StreetTalk patterns from more general exclusions. For instance, in the previous example, to exclude every name in the group Chicago Sales except those beginning with the word "Staff," you would establish an exception to the pattern *List @Chicago Sales@WCTUS. By doing this, you could make sure that any lists maintained in the group that begin with "S," such as "Staff List," are not excluded.
A service's exclusions and exceptions must appear together in a single list. You edit the list either in StreetTalk Explorer, or the MSERVICE program, or in a text file that you create outside of the management program.
Master and satellite services apply exclusions and exceptions to STDA databases in different ways. The following sections describe how each type of service applies them and how this affects data passed on to other services.
Data collected by STDA services include StreetTalk names, inclusions, and the attributes associated with both types of data. The combined StreetTalk and inclusion data, called name space data, can be filtered by applying exclusions and exceptions, and re-distributed at every level of even the most complex STDA service configurations.
The following sections describe how data is collected and refined by each type of service.
Data Collection by Master Services
Master services collect only name space (name and attribute) information from StreetTalk databases maintained on network servers. A master service can collect data from an unlimited number of StreetTalk services.
StreetTalk services on target servers are specified from the Edit Server List in the master service's configuration menus. If you do not specify a server from which you want to retrieve name space data, the master service enumerates all available StreetTalk services on the network.
Exclusions and exceptions applied to data gathered by a master service are applied as the data is collected and before the database is built. As noted earlier, inclusions submitted to master services force the services to rebuild their databases. If no new inclusions are applied, the service merges existing inclusions into the database when the service rebuilds.
After exclusions and exceptions are applied, the master service's database is available for distribution to satellite services.
Master Service Configuration Guidelines
As a rule, you configure your master service collection either physically or logically.
Physical Collection - Divides the network into sets of servers. StreetTalk services in each set are collected by a master service. A limited number of exception and exclusion filters is applied to the data. After all master services build databases, they are downloaded by one or more satellite services.
The ability to poll specific servers through the Edit Server List lets you respond to a wide variety of network environments.
In a multinational company, for instance, you can locate a master STDA service in each geographic region where your company does business. This capability allows you greater leeway to collect data from servers located across expensive WAN links during off-peak hours. In a corporate campus or university environment, you can locate master services in specific buildings.
Even in a centralized location, if you have more than a hundred users or if your company is divided along organizational lines, consider establishing multiple master services, perhaps one to a floor or department.
Logical Collection - In the logical collection model, each master service gathers data from all StreetTalk services. Exclusion and exception filters are applied to the data as it is collected. As in the physical collection model, the data is downloaded by a satellite for further distribution to other downloading satellites.
More information on creating and configuring satellite services is available in Chapter 11.
Data Collection by Satellite Services
Satellite services download StreetTalk and inclusion data from both master and other satellite services maintained on network servers. However, they cannot download data from StreetTalk services on servers.
You can specify target servers from the Download Servers Name Spaces menu when you create the satellite service.
Note: For every server you select, you can specify which type of information you want to collect from it by selecting its name spaces; that is: StreetTalk names or inclusions or a combination of both.
Because you can specify the name spaces you want to collect, you can easily control what the service receives. The number of services from which a satellite can collect data is determined by what data you collect. A satellite can collect a total of nine data "sets." Eight of these sets can be from other services and one of them can be inclusions submitted to the service itself. At a base level, you can collect one set of StreetTalk and inclusion data for four servers. However, you can also mix and match data types, collecting StreetTalk data from one service, StreetTalk and inclusions data from another, only inclusions from a third, and so on. Based on these criteria, the maximum number of other services a single satellite can collect data from is eight, in addition to the local inclusions.
More information on creating and configuring satellite services is available in Chapter 11.
Satellite Configuration Guidelines
Satellite services are generally configured as concentrator services or as display services.
Concentrator satellites are used in conjunction with multiple master service configurations to download and focus StreetTalk and inclusion data for distribution to other satellites, which in turn display the data to users. A typical concentrator satellite configuration is shown in Figure 11-1.
Display satellites are used to gather data and configure it for local display. Attribute collection and display configuration menus available in STDA management menus together with exclusions and exceptions applied to a service's database let you construct highly refined views of the network for users.
More information on collecting and displaying attributes is available in Chapter 20.
Although both master and satellite services can display StreetTalk and inclusion names along with their attributes, satellite services are often used for this task, so as a rule, master services do not display either type of data. They usually serve as collection points instead.
Information displayed by STDA services falls into two categories:
StreetTalk and inclusion names StreetTalk and inclusion attributes
Each category has its own control and editing mechanisms.
Displaying StreetTalk and Inclusion Names
StreetTalk names are gathered and filtered using exclusion and exception parameters. After these parameters are applied and the STDA database is built or rebuilt, the filtered names appear to users who access STDA through their client program.
Because data downloaded from master services remains unchanged, the master services from which a satellite downloads data define the name space information available for display by the satellite. Data downloaded from satellite services also affects satellite displays.
In many cases, especially if you administer a large network, you may want to establish redundant master services like the ones shown in Figure 10-2. Each redundant master downloads a full view of the StreetTalk data from servers on the network for distribution to any number of requesting satellites. In this way, any satellite can poll any master and be confident of receiving the full complement of StreetTalk names on the network.
Displaying StreetTalk and Inclusion Attributes
StreetTalk and inclusion attributes can be configured for display by both master and satellite services, although they are generally only displayed by satellites.
As an administrator, you can control which attributes are collected and shown for specific classes of StreetTalk resources or inclusions from the STDA service's management menu. Constraints on the collection of StreetTalk and inclusion names also apply to their attributes. A given satellite can only show attribute information for names it downloads from other services.
While all StreetTalk and inclusion names are displayed by a master STDA service that collects them, attribute collection and display is specified by administrators for each service.
Individual services can be configured in two distinct ways to collect attributes for display to users. From the satellite's attribute management menus you can specify which attributes are:
Collected and displayed for users who want to look up information on StreetTalk resources. These lookup collections are controlled through the Define Attribute Lookup editing screen. Collected into index lists for users who want to search for StreetTalk resources based on attribute values. These index collections are controlled through the Define Attribute Indices editing screen.
Rules for editing inclusion parameter lists are discussed at length in Chapter 13. Rules for specifying attributes for collection and display are described in detail in Chapter 20.
Planning Tasks for STDA Services
Planning for STDA consists of the following tasks:
Calculating disk space requirements Locating STDA services on the network Designating download servers Scheduling rebuilds Sorting names Creating exclusions, exceptions, and inclusions
Selecting which servers run STDA determines STDA performance. After STDA is running, monitor the performance of your network and make any necessary adjustments.
Calculating Disk Space Requirements
STDA databases dynamically adjust their disk space requirements based on factors such as the size and number of attributes and the distribution of entries.
If no exclusions are applied by the front-end database (the display database) of a service to data gathered from the back-end (the collection, or enumeration, database), both databases require the same amount of disk space. Any exclusions and exceptions applied to back-end data decrease the space requirements of the front-end.
Before exclusions and exceptions are applied, the front-end and back-end databases of each STDA service both require the following amounts of disk space:
If no attributes are defined for an object, you must reserve 800 bytes of disk space to store each database entry (name). For each attribute established for a user, allocate an additional 180 bytes of disk space plus the size of the attribute. For instance, if the attribute is 400 bytes, allocate 580 bytes.
In practical terms, these requirements mean you need to allocate a base of 1600 bytes for each entry you plan to collect and display for a given STDA service. To do this, you need to add 180 bytes and the size of the attribute for each attribute you expect to add to the resource. Attributes collected and not displayed need to be allocated 800 bytes plus the combined attribute size.
If you administer a large network with a multi-leveled hierarchy of STDA services, keep in mind that STDA services at each level of the hierarchy duplicate to one degree or another the databases of those services they download from.
These figures are approximate, representing maximum rather than average requirements. Use them to calculate rough disk space requirements based on the number of users and the average number of attributes for each user.
Disk Space Requirements for StreetTalk and STDA
StreetTalk resources have disk space requirements identical to those of STDA services. For this reason, when you calculate combined disk space requirements, add an additional 800 bytes and 180 bytes plus the size of each associated attribute.
Use Table 10-1 to calculate the disk space requirement for each StreetTalk/STDA resource you add to StreetTalk and STDA services.
Before installing STDA on your network, study the topology of the network to determine the best place for the STDA master and satellite services.
Both geography and the size of the network you administer affect the placement of master and satellite services. How you distribute master and satellite services across your network depends also on the organizational structure of your company.
Although no set rules exist for organizing your STDA services based on the geography of your organization, consider the following guidelines when you plan your STDA services.
For multinational networks consider establishing a master service in each distinct geographical area in which your company does business. This model creates a logical and coherent structure for your network based on your company's operational model. In addition, because STDA services only download changes in their databases to requesting satellites, use concentrator STDA services to collect data from master services in other countries, and download the data from the concentrators to minimize collection times for StreetTalk data over WAN links.
This basic topology can be adapted for continental networks and campus networks where many users are spread through multiple buildings.
Organizational Structure and STDA
Organizational factors can also affect how you set up STDA services on your network. If your company is organized along divisional or other structural criteria rather than geography, try to design your STDA services to mimic your company's natural organization.
Many companies organized on divisional lines maintain offices in different locations that need to share the same resources. In this situation it may be more efficient to establish master services that collect information from servers based on function rather than geography. Although this model may affect performance in cases such as nationwide networks, the benefits of an STDA topology modeled on the organization of your company outweigh the costs.
Try to place each master service at the most central location in the section of network it is serving. Master services should have the shortest path (measured in the number of hops) to servers they collect from.
For better performance, satellite services should be no more than two LAN segments away from other services they download from. This recommendation also applies to satellites that download other satellite services.
Add a master service to a server when:
Geographical or organizational changes require additional master services to collect or distribute data. Redundant data collection is required for optimal reconfiguration and limited downtime in the event of a service failure. Establish duplicate master services to collect redundant information for backup in the event of service failure.
In general, every geographically distinct section of your network should have a master service.
Example Sample Master Service Implementation
Because of its multinational structure, WCT has a master STDA service in every country where it does business. Each master service collects StreetTalk information from servers in the particular country.
Given the time-sensitive nature of its business, an uninterrupted flow of data is critical to WCT. A duplicate master service is maintained in each country so that if the primary master service is disabled, a backup master service can quickly be brought on line. This master service implementation is shown in Figure 10-2.
When to Add a Satellite Service
Add a satellite service to a server when:
User requests route through two or more servers residing on different LAN segments to reach an STDA service. A server accesses the network over a transient link. If an STDA satellite service is added to the network segment where the connecting server is located, users can access the STDA database at any time, whether the link is up or down. Users who connect to the network through a specific server want or need a customized version of the STDA database. Through the use of exclusions, exceptions, and inclusions used on that server's satellite service, a group of users may use a unique version of the STDA database.
Example STDA Satellite Service Implementation
To ensure data integrity, WCT maintains a series of intermediate satellite services that concentrate data downloaded from the master services for distribution to other satellites. Each of these satellites downloads StreetTalk data from every master service and builds a complete view of the network. Like the duplicate master services, this process provides data redundancy in the event of failure by another concentrator service.
Figure 10-2 shows a portion of a network with six STDA master services and nine satellite services installed. Note the following features about this network:
Each of the three master services collects StreetTalk and inclusion data from StreetTalk services in different countries. Each master service has a backup service collecting duplicate data in the event of failure. Three concentrator STDA satellite services download a complete view of the network from the three master services. This process ensures an additional layer of data redundancy. Individual satellites download StreetTalk and inclusions with their attributes from the concentrator satellites.
Banyan networking software lets administrators restrict user access to portions of a network by establishing restricted links. When communicating across a restricted link, STDA master services only collect the names maintained in the group servername@Servers of the target server on the far side of that link.
Satellite STDA services in the group servername@Servers can be configured to download from other services beyond the link server, theoretically making these names available to users at the other end of the link. This concept is illustrated in Figure 10-3.
If you do collect names beyond the restricted server they will appear in STDA displays, but users, under most circumstances, will be unable to access them through mail. However, you can use the forced message routing feature of Intelligent Messaging to make StreetTalk or inclusion information from a service beyond the link server available to users across a restricted link.
Submit the StreetTalk or non-StreetTalk name with the routing information required by network mail as an inclusion to the STDA service on the link server. This precaution ensures that the StreetTalk or inclusion resource appears in STDA displays and that mail sent to recipients is delivered. For more information on forced message routing, see the Intelligent Messaging Administrator's Guide.
The following sections describe how STDA master and satellite services gather StreetTalk and inclusion names and attribute data from other services or from StreetTalk databases on servers.
Collecting StreetTalk Data with Master Services
STDA master services collect raw StreetTalk information from groups on specific servers. To set up a link between a master service and a StreetTalk database on a server, specify the name of the server when you create the master service. Master services can collect data from any server, including the one on which they are located.
As soon as you start a master service, it assembles a list of groups that reside on the assigned servers. The Edit Server List screen shows which servers are assigned to the master service. Based on this list, the service continuously polls each server on the list until it has collected information on all of its groups.
Each time the service locates a group and collects its StreetTalk and inclusions, it marks the group as successfully collected and continues its search. The service repeats this collection routine until it successfully collects information from every group or until the next scheduled rebuild occurs.
Use a Banyan management program to change the download server for a master service at any time. See "Scheduling Rebuilds" later in this chapter, and Chapter 11 for more information on using these programs to set rebuild schedules.
Collecting StreetTalk Data with Satellite Services
Satellite services download StreetTalk or inclusion data from either master or satellite services. To set up a link between two STDA services, specify the name of the established satellite or master service when the new STDA service is created.
As soon as you start a satellite service, it attempts to download data from the target server and construct its database. The satellite service repeats its request periodically until it reaches the target server. Thereafter, downloading occurs according to the service's schedule.
Use a Banyan management program to change the download server for a satellite service at any time. See Chapter 11 for more information on using these programs to set rebuild schedules.
Planning rebuild schedules for master and satellite services is an important administrative task. Master and satellite services are often organized hierarchically. For this reason, master services should always be rebuilt before satellites. If you have multiple master services, you should generally rebuild them simultaneously.
After the master services rebuild, specify the satellite services that download directly from the master services. If there are other levels of satellite services, specify the satellites that these services download from, and so on, until you reach the last download satellites. This order is illustrated in Figure 10-4.
If you do not allot enough time for a service to complete its rebuild before the services that download from it begin their rebuilding, the dependent services may not receive all of the newest information. Allot at least two hours from when you begin to rebuild the master database to when you rebuild the satellite service databases that download from the master service. Allot more time if your network is large or connected by many slow-speed links. Use the STDA service logs to track how long the rebuild takes. This method lets you stagger the starting times accordingly.
Schedule rebuilds when the system is not used or gets little use. How often you update an STDA service's database depends on how often your StreetTalk information changes. When a system administrator adds, deletes, or changes the names or descriptions of network users and services, it affects the rebuild of every STDA database on the network. In general, rebuilds on most networks should occur once daily.
If master and satellite services are in different time zones and different countries, scheduling rebuilds can be difficult. A download that begins in off-hours may end in a period of heavy use.
STDA lets you perform complex sorting operations on the item parts of all classes of StreetTalk names. These sorting orders determine how names appear in STDA client applications. More information on how to sort names for display in STDA is available in Chapter 14.
Creating Exclusions, Exceptions, and Inclusions
Consider these suggestions when you create exclusions, exceptions, and inclusion lists:
Exclude from master and satellite services all StreetTalk names except those you want to include. Use wildcards (for example, *@*) to exclude any names. Include on master and satellite services all non-StreetTalk names that users need, such as addresses to mail gateway services. Let your master service include all StreetTalk names. Define the exclusions on the satellite services. This lets administrators of the satellite services customize the database. The responsibility is removed from the master service. If you have a common set of exclusions, define them on the master service. Defining the common set reduces the amount of data transferred across the network and eliminates the need to exclude the same names on the individual satellites.
If you customize master and satellite services, you must also customize user profiles so that users pick up the STDA service with the StreetTalk names they need. In addition, client programs must be designed to respond to the profile information. See the Command Reference for information on the XSTD command.
As you plan your network, be aware that the following factors affect the performance of STDA:
Transient links Network size Server memory requirements
Transient links may affect how quickly the STDA service rebuilds. For example, if Server B has a dial-up link to Server A, make sure that the STDA satellite service for Server B can download its database from Server A at a time when the two are linked. In addition, check that Server B has enough link-up time to complete the download.
The master service collects names automatically when servers connect to the network across transient links, regardless of the master service's schedule. However, the collected names do not appear in the master database until after the next scheduled rebuild of the master database is complete.
If you plan to install STDA on a large network, follow these guidelines:
Place the master STDA service on a server that is not heavily loaded. STDA should be one of the few services running, in addition to the Banyan network services. In large networks, requests that are not targeted for specific STDA services may cause excessive network traffic. You may want to set specific switches to let users direct STDA requests to specific services, rather than broadcasting requests. However, these connections can only be done with client applications that are designed to respond to profile commands.
The memory requirements of STDA are similar to those of StreetTalk: they increase until they reach a plateau. In large networks, a heavily used STDA service uses as much as 100 KB more memory than the service's memory requires at startup. An example of a heavily used STDA service is a master service with about a hundred users accessing it. Typically, master services have greater memory requirements than satellite services.
For more information on how to measure the memory requirements of STDA and interpret the meaning of this information, see Monitoring and Optimizing Servers.
