semi合集-English.pdf - 第1584页

SEMI E37-0303 © SEMI 1995, 2003 6 entity indicates successful completion of the connect procedure, and the CONNECTE D state is entered (Sect ion 5). These procedures are ca rried out through the API of the local entity&a…

SEMI E37-0303 © SEM 1995, 2003 5

6 Use of TCP/IP

6.1 TCP/IP API — The specification of a required TCP

Application Program Interface (API) for use in

implementations is outside the scope of HSMS. A given

HSMS implementation may use any TCP/IP API —

sockets, TLI (Transport Layer Interface), etc. —

appropriate to the intended hardware and software

platform, as long as it provides interoperable TCP/IP

streams protocol on the network.

The appendix contains examples of the TCP/IP

procedures referenced in this standard and sample

scenarios using both the TLI (POSIX standard 1003.12)

and the popular BSD socket model for TCP/IP

communication.

6.2 TCP/IP Network Addressing Conventions

6.2.1 IP Addresses — Each physical TCP/IP

connection to a given Local Area Network (LAN) must

have a unique IP Address. IP Addresses must be

assignable at installation time, and an HSMS

implementation cannot select a fixed IP Address. A

typical IP Address is 192.9.200.1.

IP imposes restrictions on these numbers which are

outside the scope of the HSMS protocol. Consult

Section 2.3 of RFC 791, Internet Protocol (IP) in

Section 3.

6.2.2 TCP Port Numbers — A TCP Port Number can

be considered as an extension of the IP Address.

HSMS implementations should allow configuring TCP

Port to the full range of the TCP/IP implementation

used. A typical TCP Port Number is 5000.

Conventions have been established for selecting TCP

Port Numbers which are outside the scope of the HSMS

protocol. Consult RFC 793, Transmission Control

Protocol (TCP) in Section 3.

6.3 Establishing a TCP/IP Connection

6.3.1 Connect Modes — The procedures for

establishing a TCP/IP connection are defined in RFC

793. However, not all the procedures defined by RFC

793 are supported by commonly available APIs. In

particular, while RFC 793 permits both entities to

initiate the connection simultaneously, this feature is

rarely supported in available

APIs. Therefore, HSMS restricts an entity to one of the

following modes:

• Passive Mode. The Passive mode is used when the

local entity listens for and accepts a connect

procedure initiated by the Remote Entity.

• Active Mode. The Active mode is used when the

connect procedure is initiated by the Local Entity.

The appendix provides an example of how an entity

may operate alternately in the active and passive modes

to achieve greater flexibility in establishing

communications.

6.3.2 Passive Mode Connect Procedure — The

procedure followed by the Passive Local Entity is

defined in RFC 793. It is summarized as follows:

1. Obtain a connection endpoint and bind it to a

published port.

2. Listen for an incoming connect request to the

published port from a remote entity.

3. Upon receipt of a connect request, acknowledge it

and indicate acceptance of the connection. At this

point, the connect procedure has completed

successfully, 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

appendices provide 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 connect request after a local entity-specific

timeout. The action to be taken (for example: return to step 1

to retry) is a local entity-specific issue.

NOTE: See Section 9, Special Considerations, for issues

relating to multiple connection requests to the same passive

mode entity.

6.3.3 Active Mode Connect Procedure — The

procedure followed by the Active Local Entity is

defined in RFC 793. It is summarized as follows:

1. Obtain a connection endpoint.

2. Initiate a connection to the published port of a

passive mode remote entity.

3. Wait for the receipt of the acknowledge and the

acceptance of the connect request from the remote

entity. Receipt of the acceptance from the remote

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.

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.