semi合集-English.pdf - 第1594页

SEMI E37-0303 © SEMI 1995, 2003 16 Table 10 Parameter Name Value Range Reso lution Typical Valu e Description T3 Reply Timeout 1-120 seconds 1 second 45 seconds Reply time out. Specifies maximum amount of time an entity …

100%1 / 7923
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.
SEMI E37-0303 © SEMI 1995, 2003 16
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.
SEMI E37-0303 © SEM 1995, 2003 17
APPENDIX 1
NOTE: This appendix was approved as a part of SEMI E37 by full letter ballot procedure.
A1-1 TCP/IP Procedures Using TLI and BSD Socket Interfaces
A1-1.1 Passive Mode Connect Procedure
Table 1
Intended Action TLI Construct BSD Construct Comment
Obtain a connection endpoint and
bind it to a published port.
tep = t_open(...)
t_bind(tep,...)
skt = socket(...)
bind(skt,...)
BSD refers to a connection endpoint as a
“socket.” TLI refers to it as a TEP (transport end
point).
Permit socket to listen for
connections.
... listen(skt...) In TLI, the equivalent of BSD listen is not
necessary.
Connect procedure: receive
incoming connect request and
accept it.
t_listen(tep,...)
t_accept(tep,...)
accept(skt,...)
Connect procedure: receive
incoming connect request, but
reject it.
t_listen(tep,...)
t_snddis(tep,...)
... The BSD API does not support originating a
reject of a connect request, as receiving request
and accepting it are a single operation.
A1-1.2 Active Mode Connect Procedure
Table 2
Intended Action TLI Construct BSD Construct Comment
Obtain a connection endpoint. tep = t_open(...)
t_bind(tep,...)
skt = socket(...) TLI requires bind to null address for active
entity.
Connect procedure: send connect
request and receive accept or
reject from passive entity.
t_connect(tep,...)
t_rcvconnect(tep,...)
connect(skt,...) The BSD connect will correctly handle an
active reject from the TLI-based remote
entity.
A1-1.3 Terminating the Connection
Table 3
Intended Action TLI Construct BSD Construct Comment
Release the connection and free
connection endpoint.
t_sndrel(tep,..)
t_close(tep)
close(skt) The “gracefulness” of the BSD close is a
function of the local implementation.
Disconnect and free the
connection endpoint.
t_snddis(tep,..)
t_close(tep)
shutdown(skt,2)
close(skt)
Shutdown immediately disables further sends
and receives if the second arg = 2.
A1-1.4 Sending and Receiving HSMS Messages
Table 4
Intended Action TLI Construct BSD Construct Comment
Send an HSMS
message
hdr->Len = length;
t_snd(tep,hdr,14,0);
t_snd(tep,Text,hdr->Len,0);
hdr->Len = length;
write(skt,hdr,14);
write(skt,Text,hdr-
>Len);
The procedure illustrates a “typical”
implementation style in which the length bytes
and header are combined into a single 14-byte
item sent first, followed by the text. This is not to
imply that combining everything is not permitted.
Receive and HSMS
message
t_rcv(tep,hdr,14,...);
t_rcv(tep,Text,hdr->Len,...);
read(skt,hdr,14);
read(skt,Text,hdr->Len);
As above, but for receiving.