semi合集-English.pdf - 第1591页

SEMI E37-0303 © SEM 1995, 2003 13 PType = 0 SType = 6 System Bytes — Equal to System Bytes in correspondin g Linktest.req. 8.2.8 SType=7: Reject.req — An HSMS m essage with SType 7 is used in r esponse to any valid HSMS …

100%1 / 7923
SEMI E37-0303 © SEMI 1995, 2003 12
Value Description
4–
127
Reserved for subsidiary standard-specific reasons for
select failure.
128–
255
Reserved for local entity-specific reasons for select
failure.
PType = 0
SType = 2
System Bytes — Equal to value of System Bytes in
the corresponding Select.req.
8.2.4 SType=3: Deselect.req — An HSMS message
with SType 3 is a “Deselect Request” Control Message,
used by the initiator of the Select procedure for ending
HSMS communication. The message format is as
follows:
Message Length is always 10 (Header only).
The HSMS Message Header is as follows:
SessionID — The SessionID must match the value
of the SessionID of a previously sent Select.req to
indicate the particular HSMS session that is
ending. Subject to further specification by
subsidiary standards.
Header Byte 2 = 0
Header Byte 3 = 0
PType = 0
SType = 3
System Bytes — A unique value among open
transactions.
8.2.5 SType=4: Deselect.rsp — An HSMS message
with SType 4 is a “Deselect Response” Control
Message, used as the response to a Deselect.req Control
message in the Deselect procedure for ending HSMS
communications. The message format is as follows:
Message Length is always 10 (Header only).
The HSMS Message Header is as follows:
SessionID — must equal the session ID in the
corresponding Deselect.req
Header Byte 2 = 0
Header Byte 3 — DeselectStatus. A code of zero
indicates success of the Deselect operation. A non-
zero code indicates failure.
Table 8
Value Description
0 Communication Ended. The Deselect completed
successfully.
1 Communication Not Established. HSMS
communications has not yet been established with a
select, or has already been ended with a previous
Deselect.
2 Communication Busy. The session is still in use by the
responding entity and so it cannot yet relinquish it
gracefully. In this case, if the original requester must
terminate communications, the separate procedure
should be used as a last resort.
3–
127
Reserved for subsidiary standard-specific reasons for
Deselect failure.
128–
255
Reserved for local entity-specific reasons for Deselect
failure.
PType = 0
SType = 4
System Bytes — Equal to System Bytes in
corresponding Deselect.req.
8.2.6 SType=5: Linktest.req — An HSMS message
with SType 5 is a “Linktest Request” Control Message.
It is used to verify the integrity of the HSMS
Connection, or as a periodic heartbeat. The message
format is as follows:
Message Length is always 10 (Header only).
The HSMS Message Header is as follows:
SessionID = 0xFFFF (in binary, all ones)
Header Byte 2 = 0
Header Byte 3 = 0
PType = 0
SType = 5
System Bytes — A unique value among open
transactions.
8.2.7 SType=6: Linktest.rsp — An HSMS message
with SType 6 is a “Linktest Response” Control
Message, used as the response to a Linktest.req Control
message in the Linktest Procedure. The message format
is as follows:
Message Length is always 10 (Header only).
The HSMS Message Header is as follows:
SessionID = 0xFFFF (binary, all ones)
Header Byte 2 = 0
Header Byte 3 = 0
SEMI E37-0303 © SEM 1995, 2003 13
PType = 0
SType = 6
System Bytes — Equal to System Bytes in
corresponding Linktest.req.
8.2.8 SType=7: Reject.req — An HSMS message with
SType 7 is used in response to any valid HSMS
message received which is not supported by the
receiver of the message or which is not valid at the
time. It is intended for dealing with attempts to use
subsidiary standards or user-defined extensions which
are not supported by the receiver (for example, SType
equal to any value not defined in this standard). It must
be used when an entity receives a control message
which is a response (even numbered SType) for which
there was no corresponding open transaction.
The HSMS Message Header is as follows:
SessionID — equal to the value of the Session ID
in the message being rejected.
Header Byte 2 — For ReasonCode = PType Not
Supported, equal to the PType in the message
being rejected. Otherwise equal to the value of the
SType in the message being rejected.
Header Byte 3 — reason code (always non-zero)
Table 9 ReasonCode
Value Description
1 SType Not Supported. A message was received whose
SType value not defined in the HSMS standard or the
particular subsidiary standard(s) supported by the
entity.
2 PType Not Supported. As above, but for PType.
3 Transaction Not Open. A Response control message
was received when there was no outstanding request
message which corresponded to it.
4 Entity Not Selected. A data message was received when
not in the SELECTED state.
4–
127
Reserved for subsidiary standard-specific reasons for
reject.
128–
255
Reserved for local entity-specific reasons for reject.
PType = 0
SType = 7
System Bytes — Equal to System Bytes in
corresponding message being rejected.
8.2.9 SType=9: Separate.req — An HSMS message
with SType = 9 is used to terminate HSMS
communications immediately. With the exception of
the SType value, it is identical to the Deselect.req
message. Its purpose is to end HSMS communications
immediately and without exception. No response is
defined.
9 Special Considerations
9.1 General Considerations
9.1.1 Communications Failures — If a
communications failure is detected, the entity should
terminate the TCP/IP connection. Upon termination of
the connection, the entity may, at this point, attempt to
reestablish communications.
9.2 TCP/IP Considerations
9.2.1 Connect Separation Time (T5) — The connect
procedures initiate some network activity. Frequent use
of the active mode connect procedure to the IP Address
and Port Number of an entity not yet ready to accept
connections can be hostile to TCP/IP operations. The
passive mode does not generate network activity and is
not considered hostile to the network, although it may
affect local application performance. An Entity
initiating a connection in the active mode should limit
its use of the connect procedure in a manner that is
equivalent to the procedure described here.
After an active connect procedure terminates by any
means (successfully or unsuccessfully), the Entity
should not initiate another active connect procedure (for
the same Remote Entity) until the T5 Connect
Separation Time has elapsed. The separation of connect
operations will be the sum of the T5 Connect
Separation Time interval, plus the duration of the
connect operation itself.
9.2.2 NOT SELECTED Timeout (T7) — Entry into the
NOT SELECTED state is achieved either by state
transition #2 (establishment of a TCP/IP connection).
There is a time limit on how long an entity is required
to remain in the NOT SELECTED state before either
entering the SELECTED state or by returning to the
NOT CONNECTED state.
Some entities, particularly those unable to accept more
than a single TCP/IP connection, may be impaired in
their operation by remaining in their NOT SELECTED
state as they will be unavailable for communications
with other entities. Such entities shall disconnect the
TCP/IP connection (State Transition Event #3) if
communication remains in the NOT SELECTED state
for longer than the T7 timeout period.
9.2.3 Network Intercharacter Timeout (T8) — Because
TCP/IP is a stream rather than a message protocol, it is
possible that bytes which are all part of a single HSMS
message may be transmitted in separate TCP/IP
messages without any violation of the TCP/IP protocol.
Since it is possible that these separate messages may be
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