semi合集-English.pdf - 第1593页

SEMI E37-0303 © SEM 1995, 2003 15 whose SType is equal to 0, but is otherwi se specified for all other S Type values. The message tex t formatt ing is defined by the PType as well, but only for da ta messages. Subsidiary…

SEMI E37-0303 © SEMI 1995, 2003 14

separated by a substantial period of time, the Network

Intercharacter Timeout (T8) is defined.

T8 is similar in purpose to the SECS-I T1 timer except

that the communications issues which necessitate T8

are not entirely in the control of the sender of the

message. Therefore, it is defined only in terms of the

receiver of the message. In particular, if after receipt of

a partial message, the T8 timeout period expires prior to

receipt of the complete message, the receiving entity

shall consider such case as a communications failure, as

defined above.

9.2.4 Multiple Connection Requests Directed to a

Single Published Port — Once a passive entity has

accepted a connection on its published port, TCP/IP

permits (though does not require) the entity to listen for

and accept additional connections directed to the same

published port.

HSMS permits (though does not require) entities to

operate in this manner. However, for the purposes of

HSMS compliance, each connection so formed must

exhibit the behavior defined in the HSMS state diagram

as if it were completely independent of any other

connection to the same published port.

9.2.4.1 Rejection of Additional Connection Requests by

a Passive Mode Entity — A passive mode entity unable

to service more than a single TCP/IP connection for

HSMS communications will follow one of these three

procedures with respect to additional connection

requests.

a. Accept the connection, but always respond to any

subsequent HSMS select procedures with the

Communication Already Active response code. For

the purpose of the HSMS State Diagram, the

connect procedure terminates successfully (enters

CONNECTED state), but HSMS communications

are never established (remain in NOT SELECTED

substate). This is the preferred option in that it can

provide the most information to the remote entity

as to why the connection is refused (see HSMS

Select Procedure), but places an addition

implementation requirement on the local entity.

b. Actively reject the connection request. This can be

done in a TLI implementation using the t_snddis

procedure. This will cause the connect procedure in

the remote entity to terminate unsuccessfully. This

option may not be available to all implementations

because some API’s, notably some

implementations of BSD Sockets, do not provide

for initiating an active reject. Note, however, that

all TCP/IP implementations, including BSD

Sockets, properly respond to an active reject from

the remote entity.

c. Refuse to listen for or accept the connect request.

No action is taken in the local entity: the remote

entity’s connect procedure will eventually time out.

This option is permitted, but not recommended, as

it can cause considerable delay on the part of the

remote entity. However, it may be the only

alternative available to implementations with

network resource limitations.

The documentation of the passive local entity shall

indicate which means it uses to refuse connections.

9.3 HSMS-Specific Considerations

9.3.1 Control Transactions T6 Control Timeout — A

number of the control messages are part of procedures

which require a message exchange or transaction:

<xx>.req from the initiator of the control service,

followed by an <xx>.rsp from the receiver of the

<xx>.req in response to it. A control transaction is

considered open from the time the <xx>.req request is

sent until the time the <xx>.rsp is received.

The time a control transaction may remain open is

subject to the T6 control transaction timeout. Upon

initiation of a control transaction, the local entity should

set a timer whose duration is equal to the T6 timeout

value. If the transaction is properly closed prior to the

expiration of the timer, the timer should be canceled. If

the timer expires prior to the proper closing of the

transaction, the transaction shall be considered closed

by the initiator and considered an HSMS

communications failure.

9.3.2 Procedures and “Stateless” Transactions —

Most of the HSMS control procedures involve a

transaction: the initiator sends a request message to the

responding entity and waits for a response message.

The responding entity receives the initiator' s request

message and sends a reply.

Note that such transactions are “stateless” in the

following sense: while the initiator of a transaction is

waiting for a response, it may receive a message other

than that response, and this message may be any

message valid for the state the initiator was in at the

time the original transaction was initiated. For example,

the two entities may simultaneously initiate

transactions. As a result, no states for

“TRANSACTION OPEN” or “TRANSACTION NOT

OPEN” are reflected in the HSMS state machine. The

use of such state information in an implementation is

strictly a local entity-specific issue.

9.3.3 Alternative Message Types and Header Byte

Values — The HSMS standard does not completely

define all possible enumerated values of either the

PType or SType field. Further, Header bytes 2 and 3

have a format determined by the PType for messages

SEMI E37-0303 © SEM 1995, 2003 15

whose SType is equal to 0, but is otherwise specified

for all other SType values. The message text formatting

is defined by the PType as well, but only for data

messages.

Subsidiary standards must be consistent with this

convention. In particular, for SType = 0, subsidiary

standards defining PType values not equal to 0 may

specify both the message text encoding and the

interpretation of header bytes 2 and 3. For STypes not

equal to 0 but otherwise specified in this standard,

PType must = 0, and no message text may be

transmitted. For STypes defined in subsidiary

standards, the meaning of header bytes 2 and 3 may be

specified on a per SType value basis, and these STypes

may optionally define message text as long as the

PType field is used in a manner consistent with the

preceding paragraph.

9.4 SECS-II Considerations — The SECS-II standard

(SEMI E5) makes certain references to SECS-I (SEMI

E4). This section addresses issues specific to SECS-II

when HSMS is used to transport SECS-II messages.

9.4.1 Reply Matching — When a Sender sends a

Primary Message with W-Bit 1 (Reply Expected), the

Sender should expect a Reply message whose header

meets the following requirements.

The SessionID of the Reply must match the

SessionID of the Primary Message.

The Stream of the Reply must match the Stream of

the Primary Message.

The Function of the Reply must be one greater than

the Function of the Primary Message, or else the

Function of the Reply must be 0 (Function Zero

Reply).

The System Bytes of the Reply must match the

System Bytes of the Primary Message.

9.4.1.1 T3 Reply Timeout — The T3 reply timeout is a

limit on the length of time that the HSMS message

protocol is willing to wait for a Reply message.

After sending a Primary Message with W-bit 1 (Reply

Expected), the sender must begin a reply timer,

initialized to the T3 value. If the sender does not

receive the Reply Message before the reply timer

expires, then a T3 Timeout Error has occurred. The

sender should close the transaction and no longer

expect the Reply Message.

Each open transaction for which a Reply is expected

requires a separate reply timer.

9.4.2 Stream 9 Messages — The SECS-II standard

defines error messages S9F1, S9F3, S9F5, S9F7, S9F9,

and S9F11, with message text containing the SECS-II

Data Items MHEAD or SHEAD, which are defined to

contain a 10-byte SECS-I block header.

When using SECS-II with HSMS, MHEAD and

SHEAD should contain the ten bytes of the HSMS

Message Header.

10 HSMS Documentation

An HSMS implementation is required to document the

following information:

1. Method for setting protocol parameters (see

Section 10.1).

2. Range allowed and resolution for each parameter.

3. The option used for refusing incoming connection

requests if the implementation uses the passive

mode for TCP/IP connection establishment.

4. Maximum message size which can be received.

5. Maximum expected size of messages sent.

6. Maximum number of supported concurrent open

transactions.

10.1 Parameter Setting — Implementations of HSMS

must provide for installation time setting of the

following parameters. The range and resolution of all

parameters must be at least as shown in the table. All

parameters must be stored in such a manner that the

settings will be retained if the power fails or if the

system software is reloaded.

Table 10

Parameter Name Value Range Resolution Typical Value Description

T3 Reply

Timeout

1-120 seconds 1 second 45 seconds Reply timeout. Specifies maximum amount of time an

entity expecting a reply message will wait for that reply.

T5 Connect

Separation

Timeout

1-240 seconds 1 second 10 seconds Connection Separation Timeout. Specifies the amount of

time which must elapse between successive attempts to

connect to a given remote entity.

T6 Control

Transaction

Timeout

1-240 seconds 1 second 5 seconds Control Transaction Timeout. Specifies the time which a

control transaction may remain open before it is

considered a communications failure.

T7 NOT

SELECTED

Timeout

1-240 seconds 1 second 10 seconds Time which a TCP/IP connection can remain in NOT

SELECTED state (i.e., no HSMS activity) before it is

considered a communications failure.

T8 Network

Intercharacter

Timeout

1-120 seconds 1 second 5 seconds Maximum time between successive bytes of a single

HSMS message which may expire before it is considered a

communications failure.

Connect Mode PASSIVE,

ACTIVE

— —

Connect Mode. Specifies the logic this local entity will use

during HSMS connection establishment.

Local Entity IP

Address and

Port number

determined by

TCP/IP

conventions

— —

Required for any entity operating in PASSIVE mode.

Determines the address on which the local entity will listen

for incoming connection requests.

Remote Entity

IP Address and

Port Number

determined by

TCP/IP

conventions

— —

Required for any entity operating in ACTIVE mode.

Determines the address of the remote entity to which the

local entity will attempt to connect.

NOTE: Parameter defaults shown above are for small networks (10 nodes or less). Settings may need to be adjusted for larger network

configurations.