Ref: 11640063
Title: Using the BCASTSOCKET Keyword with XNS Under 3+Open
Date: 3/7/90

Copyright 3Com Corporation, 1991.  All rights reserved.

The OS/2 XNSNB and the DOS XNSTP drivers provided with 3+Open implement
a BCASTSOCKETn= keyword.  The BCASTSOCKET= keyword allows all broadcast
packets to a specific destination socket to be converted to packets
directed to the same socket on a specific network number and host
address.  This is most useful for sites running the 3+ Multiple Name
Service, although it may be applicable in other situations.

Up to eight specifications of this keyword may be used within a single
machine.  The syntax is

BCASTSOCKETn = socket, netnumber, "hostaddress"

where   n           is a number from 1 to 8
socket      is a broadcast socket to translate
netnumber   is the XNS network number of the specific
    server you wish to direct these packets to
        hostaddress is the station address of the specific
                    server you wish to direct these packets to

    Note:  "hostaddress" MUST be enclosed in double
                    quotes.

How do you use this in the real world?  Let's assume 3+ Multiple Name
Service is installed on our network.  3+ workstations have utility
programs to support MNS, but 3+Open DOS and OS/2 workstations must also
be configured so they too can operate in this environment and use the
existing services.

Before going further, make these preparations:

1.  Divide the 3+Open machines into multiple sets of workstations
where each set will have access to its own Name (Name and Time services)
and Locator Server.

2.  Note the Server address for each set.


We will assume our network has network number 53c25, and there are two
servers each providing Name and Locator services.  The server for Group A
has station address 02608c25eb76 and the server for Group B has station
address 02608c67be52.  We want ALL machines to get their time from the
server for Group A.

The sockets of interest to us are:

  0x464   PEP 3Name.  This is used for most Name service requests.  Any
          request that can be satisfied with a one-packet response
          will typically use this type of packet.  Login, for example,
          uses this type of packet to request and receive all relevant
          information about the user logging in.  This information is
          placed in the local LGL cache so you do not have to ask for
          the data repeatedly.

  0x466   PEP 3Time.  Time service is a component of the Name server
          software, but it listens on a separate socket from the
          actual Name service.  Login asks for the time from the server
          as part of logging in.

  0x46d   PEP Locator.  When a workstation does a heartbeat or some
          other NetBIOS function that requires data from the Locator,
          it sends a PEP packet from source socket 0x46c to
          destination socket 0x46d, where Locator is listening.  The
          local NetBIOS on the workstation listens on socket 0x46c for
          replies.

For all machines in Group A, add the following lines to those machines'
PROTOCOL.INI files, under the [XNS_NETBIOS] section in OS/2 workstations,
and the [XNS_TRANSPORT] section in DOS workstations:

    BCASTSOCKET1 = 0x464, 0x53c25, "02608c25eb76"
    BCASTSOCKET2 = 0x466, 0x53c25, "02608c25eb76"
    BCASTSOCKET3 = 0x46d, 0x53c25, "02608c25eb76"

For all machines in Group B, add the following lines to those machines'
PROTOCOL.INI file, under the [XNS_NETBIOS] section in OS/2 workstations,
and the [XNS_TRANSPORT] section in DOS workstations:

    BCASTSOCKET1 = 0x464, 0x53c25, "02608c76be52"
    BCASTSOCKET2 = 0x466, 0x53c25, "02608c25eb76"
    BCASTSOCKET3 = 0x46d, 0x53c25, "02608c76be52"

All the machines in Group A will communicate with the Group A server for
Name, Time, and Locator services, and all the machine in Group B will
communicate with the Group B server for Name and Locator services.  Group
B machines will communicate with the Group A server for Time service.

If the Name and Locator services themselves are running on 3+Open
servers, they will issue broadcasts at startup to sockets 0x464 and
0x46d to assure themselves that no other copies of these services are
already running on the network.  If they get a response, these services
will refuse to load.

To work around this problem, for each of the two servers, add the same
three BCASTSOCKETn= statements into the [XNS_NETBIOS] section of the
servers' PROTOCOL.INI file, with the hostaddress field set to the
station address of that server.  When the Name and Locator services
start, instead of sending a broadcast to see if other copies of these
services are running, the broadcasts will be converted into packets
directed back to themselves.  Other instances of these services will
never receive any broadcasts, and will not respond.