semi合集-English.pdf - 第1585页

SEMI E37-0303 © SEM 1995, 2003 7 7.3 Data Proced ure — HSMS data m essages may be initiated by either entity as lon g as the connection is in the SELECTED state. Receipt of a data message whe n not in the SELECTED state …

100%1 / 7923
SEMI E37-0303 © SEMI 1995, 2003 6
entity indicates successful completion of the
connect procedure, and the CONNECTED state is
entered (Section 5).
These procedures are carried out through the API of the
local entity' s implementation of TCP/IP. The appendix
provides the API-specific procedures for the above
steps using both TLI and BSD.
NOTE: A failure may occur during the above steps. The
reason for failure may be local entity-specific or may be due
to a lack of any accept message after a local entity-specific
timeout. The action to be taken is a local entity-specific issue.
If, however, the local entity intends to retry the connection, it
should do so subject to the T5 connect separation timeout (see
“Special Considerations”).
6.4 Terminating a TCP/IP Connection — Connection
termination is the logical inverse of Connection
establishment. From the Local Entity' s perspective, a
TCP/IP connection may be broken at any time.
However, HSMS only permits termination of the
connection when the connection is in the NOT
SELECTED substate of the CONNECTED state.
The procedures for termination of a connection are
defined in RFC 793. Either entity may initiate
termination of the connection. The NOT CONNECTED
state is entered, indicating the end of HSMS
communications. The appendix illustrates the
procedures for both release and disconnect using the
TLI and BSD APIs.
7 HSMS Message Exchange Procedures
HSMS defines the procedures for all message exchange
between entities across the TCP/IP connection
established according to the procedures in the previous
section. As explained in the overview, once the
connection is established, the two entities establish
HSMS communications with the Select procedure.
Then data messages may be exchanged in either
direction at any time. When the entities wish to end
HSMS communications, the Deselect or Separate
procedure is used to end HSMS communications.
7.1 Sending and Receiving HSMS Messages — All
HSMS procedures involve the exchange of HSMS
messages. These messages are sent and received as
TCP/IP streams using the previously established
TCP/IP connection at standard priority. In particular,
the use of “Urgent” data is not supported under HSMS
(see RFC 793 for more information on send and receive
procedures).
The appendix gives examples of sending and receiving
HSMS messages using both TLI and BSD socket APIs.
7.2 Select Procedure — The Select procedure is used
to establish HSMS communications on a TCP/IP
connection using the Select.req and Select.rsp messages
in a control transaction.
Although HSMS permits Select at any time in the
CONNECTED state, subsidiary standards may further
require the connection to be in the NOT SELECTED
substate (see “Special Considerations”).
7.2.1 Initiator Procedure — The procedure followed
by the initiator is as follows.
1. The initiator of the select procedure sends the
Select.req message to the responding entity.
2. If the initiator receives a Select.rsp with a Select
Status of 0, The HSMS Select procedure completes
successfully and the SELECTED state is entered
(see Section 5).
3. If the initiator receives a Select.rsp with a non-zero
Select Status, the Select completes unsuccessfully
(no state transitions).
4. If the T6 timeout expires in the initiator before
receipt of a Select.rsp, it is considered a
communications failure (see “Special
Considerations”).
7.2.2 Responding Entity Procedure — The procedure
followed by the responding entity is as follows.
1. The responding entity receives the Select.req.
2. If the responding entity is able to accept the select,
it transmits the Select.rsp with a Select Status of 0.
The HSMS Select Procedure for the responding
entity is successfully completed, and the
SELECTED state is entered (see Section 5).
3. If the responding entity is unable to permit the
select, it transmits the Select.rsp with a non-zero
Select Status. The HSMS Select Procedure for the
responding entity completes unsuccessfully (no
state transitions).
7.2.3 Simultaneous Select Procedures — If the
subsidiary standards do not restrict the use of the Select,
it is possible that both entities simultaneously initiate
Select Procedures with identical SessionID’s. In such a
case, each entity will accept the other entity' s select
request by responding with a Select.rsp.
SEMI E37-0303 © SEM 1995, 2003 7
7.3 Data Procedure — HSMS data messages may be
initiated by either entity as long as the connection is in
the SELECTED state. Receipt of a data message when
not in the SELECTED state will result in a reject
procedure (see Section 7.7).
Data messages may be further defined as part of a data
transaction as either a “Primary” or “Reply” data
message. In a data transaction, the initiator of the
transaction sends a primary message to the responding
entity. If the Primary message indicates that a reply is
expected, a Reply message is sent by the responding
entity in response to the Primary.
The following types of Data Transactions are
supported:
1. Primary Message with reply expected and the
associated Reply Message.
2. Primary Message with no reply expected.
The specific procedures for these transactions are
determined by the application layer and are subject to
other standards (for example, E5 and E30 for GEM
equipment using SECS-II encoded messages).
The applicable upper layer standard is identified by the
message type. The type is determined from the specific
format defined in Section 8. The normal type for HSMS
messages is SECS-II text. Also refer to “Special
Considerations” concerning the T3 Reply Timeout.
7.4 Deselect Procedure — The Deselect procedure is
used to provide a graceful end to HSMS
communication for an entity prior to breaking the
TCP/IP connection. HSMS requires that the connection
be in the SELECTED state. The procedure is as
follows.
7.4.1 Initiator Procedure
1. The initiator of the Deselect procedure sends the
Deselect.req message to the responding entity.
2. If the initiator receives a Deselect.rsp with a
Deselect Status of 0, its Deselect procedure
terminates successfully. The NOT SELECTED
state is entered (see Section 5).
3. If the initiator receives a Deselect.rsp with a non-
zero Deselect Status, its Deselect procedure
terminates unsuccessfully. No state change occurs.
4. If the T6 timeout expires in the initiator before
receipt of a Deselect.rsp, it is considered a
communications failure (see “Special
Considerations”).
7.4.2 Responding Entity Procedure
1. The responding entity receives the Deselect.req
message.
2. If the responding entity is in the SELECTED state,
and if it is able to permit the Deselect, it responds
using the Deselect.rsp with a zero response code.
The responding entity' s Deselect procedure
completes successfully. The NOT SELECTED
state is entered (see Section 5).
3. If the responding entity is unable to permit the
Deselect, either because it is not in the SELECTED
state or because local conditions do not permit the
Deselect, it responds using the Deselect.rsp with a
non-zero response code. The responding entity' s
Deselect procedure terminates unsuccessfully. No
state change occurs.
7.4.3 Simultaneous Deselect Procedures — If the
subsidiary standards do not restrict the use of the
Deselect, it is possible that both entities simultaneously
initiate Deselect Procedures with identical SessionID’s.
In such a case, each entity will accept the other entity' s
Deselect request by responding with the deselect.rsp.
SEMI E37-0303 © SEMI 1995, 2003 8
7.5 Linktest Procedure — The Linktest is used to
determine the operational integrity of TCP/IP and
HSMS communications. Its use is valid anytime in the
CONNECTED state.
7.5.1 Initiator Procedure
1. The initiator of the Linktest procedure sends the
Linktest.req message to the responding entity.
2. If the initiator receives a Linktest.rsp within the T6
timeout, the Linktest is successfully completed.
3. If the T6 timeout expires in the initiator before
receipt of a Linktest.rsp, it is considered a
communications failure (see “Special
Considerations”).
7.5.2 Responding Entity Procedure
1. The responding entity receives the Linktest.req
from the initiator.
2. The responding entity sends a Linktest.rsp.
7.6 Separate Procedure — The Separate procedure is
used to abruptly terminate HSMS communication for
an entity prior to breaking the TCP/IP Connection.
HSMS requires that the connection be in the
SELECTED state when using Separate. The responding
entity does not send a response and is required to
terminate communications regardless of its local state.
The procedure is as follows.
7.6.1 Initiator Procedure
1. The initiator of the select procedure sends the
Separate.req message to the responding entity. The
initiator' s Separate procedure completes
successfully. The NOT SELECTED state is entered
(see Section 5).
7.6.2 Responding Entity Procedure
1. The responding entity receives the Separate.req
from the initiator.
2. If the responding entity is in the SELECTED state,
its Separate procedure completes successfully.
3. If the responding entity is not in the SELECTED
state, the Separate.req is ignored.
7.7 Reject Procedure — The Reject procedure is used
in response to an otherwise valid HSMS message
received in an inappropriate context. Supporting the
reject procedure can provide useful diagnostic
information during the development of a distributed
application using HSMS. The procedure is as follows:
7.7.1 Initiator (Sender of Inappropriate Message)
Procedure
1. The initiator of the inappropriate message, upon
receiving the Reject.req, takes appropriate action
(local entity-specific).
7.7.2 Responding Entity Procedure
1. The entity receiving the inappropriate message
responds with a Reject.req message.
HSMS requires the reject procedure for the receipt of a
data message in the NOT SELECTED state, or the
receipt of a message whose SType or PType (see next
section: Message Format) is not defined for the entity
receiving the message. Subsidiary standards may define
other conditions which require the Reject Procedure. In
general, receipt of a reject message is an indication of
an improperly configured system or a software
programming error.
8 HSMS Message Format
This section defines the detailed format of the messages
used by the procedures in the previous section.