rfc3049.txt

<VC++网络游戏建摸与实现>源代码


RFC 3049              TN3270E Location & Balancing          January 2001


   example, if the scope name is Building-D, then the SLP session
   balancing would search all TN3270E servers in the Building-D scope to
   find the least loaded TN3270E server.

   If the scope name is blank, then the scope name is not used.  This is
   referred to as unscoped.  It should be noted as in section 4.1 above
   that any reference to unscoped services applies to Service Location
   Protocol version 1 only [1].  Service Location Protocol version 2
   doesn't allow unscoped services but does allow the use of default
   scope [4].  In this case all TN3270E servers, with or without scope
   names, can be used to satisfy the request for least loaded TN3270E
   servers.  In order to cut down on network overhead, it is recommended
   that either all servers be scoped or no servers be scoped.  Refer
   back to section 4.1 for more discussion of scope.

   DA Discovery Time Out Value

   This value is specified in milliseconds and is fully described in
   section 4.2 of this document.

   SA Multicast Time Out Value

   This value is specified in milliseconds and is fully described in
   section 4.3 of this document.

5.2 How to obtain the list of TN3270E servers supporting SLP

   A TN3270E client that implements SLP session balancing uses API calls
   to obtain the list of TN3270E servers supporting SLP session
   balancing.

   The following Service Location Version 2 API [5] calls, could be used
   with TN3270E SLP session balancing:

   SLPOpen - returns an SLPHandle handle to be used

   SLPFindSrvs - issues the query for services

   SLPFindAttrs - returns service attributes matching the attribute ids
   for the indicated service URL or service type.

   SLPClose - frees all resources associated with the handle.









Naugle, et al.              Standards Track                     [Page 8]

RFC 3049              TN3270E Location & Balancing          January 2001


5.3 TN3270E Sample Client Flow

5.3.1 Open the SLP connection

   The TN3270E client must first open a handle with the SLP User Agent.
   For Service Location Protocol version 2, SLPOpen API call [5] The SA
   multicast time out and DA discovery time out values would be passed
   as parameters to the SLPOpen API call.

5.3.2 Query the list of TN3270E servers

   The TN3270E client then queries for the list of TN3270E servers
   supporting SLP.  This is done by using the Service Request API call.

   The request string contains information that determines which type of
   TN3270E servers that this client desires to connect to.  The request
   string can contain the scope name, pool name, session type and 3270
   screen size.

   The SLPv1 query string has the following format:

   TN3270/<scope name>/LUPOOL/ == <pool name><TAB><device type>

   The <scope name> is the name of the scope that is configured for the
   TN3270E client.  If the scope is blank or null (unscoped request),
   then the scope is not inserted into the request string.

   The <pool name> is a 1 to 8 character upper case string that
   indicates the name of the pool to which the TN3270E client desires to
   connect.  For SLP session balancing, the same pool name must be
   configured on different TN3270E servers.

   The <TAB> is the '/t' tab character which is hexadecimal 0x09.  the
   <TAB> is a literal and is used as a separator.

   The <device type> can be any of the following:

    3270DSC for TN3270E device type IBM-3287-1
    3270002 for TN3270E device types IBM-3278-2 and IBM-3278-2-E
    3270003 for TN3270E device types IBM-3278-3 and IBM-3278-3-E
    3270004 for TN3270E device types IBM-3278-4 and IBM-3278-4-E
    3270005 for TN3270E device types IBM-3278-5 and IBM-3278-5-E
    * for TN3270E device type IBM-DYNAMIC








Naugle, et al.              Standards Track                     [Page 9]

RFC 3049              TN3270E Location & Balancing          January 2001


   Example:

   For a TN3270E client searching for TN3270E servers in the ENGINEERING
   scope for a model 2 screen size and LUPOOL name pool2, the following
   request SLPv1 string would be constructed:

   "TN3270/ENGINEERING/LUPOOL/ == POOL2<TAB>3270002"

   Note: The " characters before and after the string are not part of
   the request string.

5.3.3 Forward Looking Example for SLPv2

   For SLPv2 the scope and service type are no longer part of the query
   string.  These are now separate fields in the message.  The service
   type name is required to have the "service:" prepended.  The service
   type field would look like "service:TN3270", and the scope field
   would be a comma separated list of scopes.  A scope name is always
   required in SLPv2, if no other name is known, the scope name
   "DEFAULT" is used.  The example below uses the same parameters as
   used in above section 5.3.2.

   Example:  Service Type: service:TN3270 Scope string: ENGINEERING The
   query string would have the following format:

           (LUPOOL=<POOL2> <32700002>)

   In SLPv2 queries, all whitespace is compressed to a single space
   character during matching, so the identity of the separator character
   does not matter.  The tab character could be added for readability,
   but it will not affect the outcome of the query.

5.3.4 Determine loading of each TN3270E server

   An attribute request for "service:tn3270e" specifying the attribute
   LOAD can be made and you will get back all the available loads.  Say
   these are 35,88,78.  You can then issue a service request for all
   tn3270E servers with "LOAD<40" for instance.  Even if the load
   changes between the time you get the attribute reply and when you
   issue the request, you will still get the best the network has to
   offer.

   The TN3270E client then uses the TN3270E server's IP Host address to
   start normal Telnet TN3270E negotiation.







Naugle, et al.              Standards Track                    [Page 10]

RFC 3049              TN3270E Location & Balancing          January 2001


5.4 Recommendations

   The TN3270E client SHOULD display the IP hostname and TCP Port that
   is being used for the TN3270E connection.  This gives the user
   knowledge of which TN3270E server the session is connected to.  For
   example, the IP host address could be displayed in the window system
   status bar.

   The TN3270E client SHOULD display the resource name that is returned
   by the TN3270E server after connection and TN3270E negotiation is
   completed.  This gives the user knowledge of which LU resource name
   in the LUPOOL the session is connected to.  For example, the resource
   name could be displayed in the Windows status bar, or even in the
   3270 OIA line.

   In the event that after the TN3270E client has determined the least
   loaded server and the connection to that server fails for some
   reason, the connection should be closed and an attempt made to
   connect to other TN3270E servers in the list of least loaded servers.

   For example, a TN3270E server may reject a connection to a specific
   pool if the pool is full, or if the device type does not match what
   is available in the pool.  If this occurs, then an attempt to other
   least loaded TN3270E servers SHOULD be performed.

6. Sample Trace Flow of SLP and Session Balancing

   This sample trace flow is provided for informational purposes only.

   SLP API: Service Request: TN3270//LUPOOL == POOL2 3270002/

   SLP API: Service Reply: service:tn3270://206.109.45.139:23

   SLP API: Service Reply: service:tn3270://206.109.45.140:23

   Connecting to 206.109.45.139:23...

   TerminalType=NVT

   Connection established

   Recv <- DO TN3270E

   Send -> WILL TN3270E

   TerminalType=TN3270E

   Recv <- SEND DEVICE_TYPE



Naugle, et al.              Standards Track                    [Page 11]

RFC 3049              TN3270E Location & Balancing          January 2001


   Send -> DEVICE_TYPE REQUEST IBM-3278-2-E CONNECT POOL2

   Recv <- DEVICE_TYPE IS IBM-3278-2-E CONNECT TN8003

   Send -> FUNCTIONS REQUEST BIND_IMAGE SYSREQ

   Recv <- FUNCTIONS IS BIND_IMAGE SYSREQ

7. Service Templates and Service Registration

   The Service Location Protocol uses the "service:" URL scheme name to
   define URLs called "service: URLs".  These schemes provide a way for
   clients to obtain configuration information that is needed to
   establish a 3270 session through the TN3270E server.  The Service
   Location Protocol provides for service: URLs to be registered and
   discovered.

   Service Registration These service registrations contain a service:
   URL, and possible attributes associated with that service.  The
   service registration information are shown below for the server.

   Service Templates Service templates are documents defining in a
   formal way the attributes associated with that service that a client
   may want to use.  For more information on service templates please
   refer to, Service Templates and service:  Schemes. [2].  The server
   service template and TN3270 service templates are shown below.

7.1 The TN3270E Service Type Template

   The 'service:tn3270:' template defined below conforms to the grammar
   described in "Service Templates and service: Schemes".  Please refer
   to [2] for detailed explanation of the syntax.

   Name of submitters: Jim Naugle <[e-mail]>
                       Gregg Ledford <[e-mail]>
                       K. Kasthurirangan <[e-mail]>
   Language of service template: en
   Security Considerations:
   Service Location Protocol can help clients discover security services
   supported by the TN3270E server.  If security services are important
   or required, using SLP authentication, and protected scopes in
   Service Location Protocol version 1 is recommended [1]. Well known
   ciphersuite names are used in the template [3].








Naugle, et al.              Standards Track                    [Page 12]

RFC 3049              TN3270E Location & Balancing          January 2001


   Template text:
   ----------------------template begins here -------------------------

   template-type=tn3270e

   template-version=1.0

   template-description=
    The tn3270 service provides 3270 gateway access to an SNA network
    via the TN3270 protocol.  The attributes reflect the types of 3270
    devices, LU Pools, and load information available on the server.

   template-url-syntax=
   # service:tn3270://<hostname>:<port>
   # <hostname>
   # <port>

   load=integer
   # This is the load balancing quantity to use in determining the
   # least loaded TN3270E server to attach to for the service.  The
   #range of valid values is an integral 0 to 100 with 0 indicating the
   #lowest possible load and 100 the highest

   LUPool=string X M L
   # This attribute takes on one or more values as defined below.
   # The <TAB> char.  0x09 is literal and will be used as a separator.
   #
   #
   #   <pool name> = <name> / <name> "<TAB>" <dev type>
   #   <name>      = 1*ALPHANUM
   #                 "3270DSC"
   #
   #
   #
   #
   # Identifies the LU pool names of LU pools available for use on this
   # service with the associated device types supported in each pool.
   # Each value is a record where the first token is the pool name of
   # the pool and the second token is a device type supported in that
   # pool.  A pool name without a device type indicates that LUs of
   # unknown type are included in the pool.  Records associated with a
   # given pool name are repeated for each supported device type.  A
   # given pool is included in a registration request if any PU profile
   # that contributes at least one LU to the pool is active on the
   # server.  The range of valid dev_types are:
   #
   # dev_type    Meaning
   #



Naugle, et al.              Standards Track                    [Page 13]

RFC 3049              TN3270E Location & Balancing          January 2001


   # 3270002     Lu Type 2 Model 2
   #
   # 3270003     Lu Type 2 Model 3
   #
   # 3270004     Lu Type 2 Model 4
   #
   # 3270005     Lu Type 2 Model 5
   #
   # 3270DSC     Printer LU
   #

   BIND=keyword
   # The server supports the SNA bind image TN3270E function.

   DATA=keyword
   # The non-SNA 3270 data stream is supported by server.

   RESPONSES=keyword
   # The server supports SNA response mode.

   SCS=keyword
   # The server supports SNA 3270 SCS data stream.

   SYSREQ=keyword
   # The SYSREQ keyboard key is supported on server.

   RFC1576=keyword
   # RFC1576 options supported.

   RFC1646=keyword
   # RFC1646 options supported.

   RFC2355=keyword
   # RFC2355 options supported.

   security=string M
   # This is the security technique supported on the server.
   # The defined values are:
   NONE
   SSLV3

   Ciphersuites=string M
   # Cipher specifications supported by this server.
   # Additional values will be defined in future templates.
   NULL_NULL,
   NULL_MD5,
   NULL_SHA,
   RC4_MD5_EXPORT,



Naugle, et al.              Standards Track                    [Page 14]

RFC 3049              TN3270E Location & Balancing          January 2001