JPH1055323A - Communication interface - Google Patents

Abstract

PROBLEM TO BE SOLVED: To release a process from a complicated reception processing and also to reduce a load of a main CPU by receiving the data on a condition described on a table in response to a reception request given from an application program and sending the received data back to the application program. SOLUTION: A LAN connection is secured via an Ethernet circuit 86 between a host computer 80 containing a communication interface 87 and another host computer. An application program request processing part 81 of the computer 80 receives a request from an application program 85 that desires to perform a communication. A protocol processing part 82 carries out a TCP/IP protocol to transmit and receive data to and from the opposite host computer, and a data transmitter/receiver means 83 transmits and receives data to and from the circuit 86. Then the part 81 notifies the part 82 of the time-out value and the packet size according to the contents of a parameter table 90 and also requests the communication processing.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an information processing apparatus, and more particularly, to performing packet communication with another information processing apparatus.
The present invention relates to a method for providing a service to an application program by extending a function of a communication control device that processes a communication protocol.

[0002]

2. Description of the Related Art A client / server type LAN using Ethernet as a communication line specification and using TCP / IP as a communication protocol has become widespread. In the case of an information device that uses UNIX for the OS, for example, if it performs the function of a server, a communication channel is opened in preparation for accepting a connection request from a client, and a request from the client is received at a certain well-known address. wait. On the other hand, the client opens a communication channel and connects to a specific host, that is, the well-known address of the server, and then sends a service request to the server and receives a response. A logical communication path in which the client and the server recognize each other's communication channel and connect them is called a connection, and communication performed after establishing such a connection is called connection-type communication. TCP is a protocol for performing connection-type communication. Also, TC
Information devices employing P / IP perform communication in the same manner as described above, even if the OS is not UNIX.

[0005] A process that attempts to communicate at a client hands over a buffer containing data to be sent to TCP. TCP adds a TCP header to the data and delivers the data to the lower layer IP. IP is more IP
Since a header is added to form an IP packet and delivered to the lower data link layer, the data link layer transmits / receives data in accordance with the rules of Ethernet.

[0004] In this specification, the IP is the IP address of the partner host.
Data transmitted / received from / to P is referred to as an IP packet or datagram, and data transmitted / received from / to TCP of the partner host is simply referred to as a packet.

[0005]

The TCP guarantees the destruction or loss of a packet. However, due to restrictions on packet size and communication speed, the lower layer IP may divide one packet into a plurality of packets and send / receive them. It does not guarantee that it will be passed to a higher-level process. Therefore, a process that attempts to perform communication using TCP needs to repeat a reception request to TCP many times until data of a desired size is received. Also, in order to efficiently receive packets sent asynchronously, it is necessary to periodically issue a reception request and always take in packets. For this reason, the configuration of the program becomes complicated, and the process tends to monopolize the CPU.

[0006] Further, the packets received by the client process are not necessarily of a known size to the client. For example, STX (0 in hexadecimal)
2, the data string starting with 02H) is indeterminate for the receiving side because the size of the data is determined by the transmitting side when the last byte ends with ETX (03H). Therefore, the client process must always request reception of a packet with the maximum size, or conversely, request reception with a small size and check the last byte for each packet received. In the former case, when the server process sends data less than the maximum size, the client process may wait forever. In the latter case, the reception request is frequently repeated, and the above-described problem occurs.

An object of the present invention is to relieve the process from complicated reception processing associated with packet communication and to enable efficient reception to reduce the load on the main CPU.

[0008]

The present invention comprises a protocol processing unit for transmitting and receiving data to and from a partner device, and a request processing unit for requesting the protocol processing unit to perform communication processing in response to a request from an application program. A communication interface, comprising: a table describing conditions that can be changed by a user with respect to transmission / reception of data to / from a partner device, wherein the request processing unit communicates with the protocol processing unit based on the conditions described in the table. And receiving the data of the conditions described in the table in response to one reception request from the application program and returning the reception data to the application program, thereby solving the above-mentioned problem. It is.

[0009]

FIG. 8 shows a communication interface 87 of the present invention.
FIG. 2 is a functional block diagram of a computer 80 (hereinafter, referred to as a host) including a host. The host 80 is connected to another host computer via an Ethernet line 86 via a LAN.
The hosts can be both a client and a server. However, in this embodiment, the user determines in advance whether the host operates as a client or a server according to settings.

As shown in FIG. 1, a host 80 has an application program request processing unit 81 for receiving a request from an application program 85 for performing communication.
A protocol processing unit 82 that executes a TCP / IP protocol to transmit / receive data to / from a partner host;
86 includes a data transmitting / receiving means 83 for transmitting and receiving data, and a parameter table 90 for storing parameters relating to communication.

The application program request processing unit 81 notifies the protocol processing unit 82 of a timeout value and a packet size, which will be described later, according to the contents of the parameter table 90, and requests communication processing. Further, the protocol processing unit 82 includes a timer 84 for measuring the communication time, and not only when a packet of a specified size is received, but also when a set time elapses.
The upper-level application program request processing unit 81 is notified. Here, the elapse of the set time is called a timeout. Further, the application program 85 may be hereinafter referred to as a process.

FIG. 9 shows the contents of the parameter table 90. The C / S mode 91 is a flag indicating whether the host operates in the client mode or the server mode. The host name 92 is the name of a server to be connected when the host operates in the client mode.
When there are a plurality of servers, the server name specified directly by the application program 85 can be prioritized. The connection time-out value 93 is the maximum wait time from when the application program request processing unit 81 of the client requests communication with the host, opens a communication channel and requests a connection to the server, and returns a response from the server. is there. That is, it is the maximum allowable time that can be used to establish a connection between the client and the server.

The reception time-out value 94 is the maximum value of the waiting time from when the client sends a request to the server to transmit data until the first datagram is received after the request is sent. Also, the packet timeout value 95
Specifies the time between receiving the first datagram and receiving the complete packet containing the datagram. A complete packet is a packet that satisfies the conditions described below and that has byte data of a specified size.

In the present embodiment, the parameter table 90 is called a protocol adjustment table, and is abbreviated as PAT hereinafter. FIG. 10 is a display example of a basic specification setting screen 10 for setting the above parameters. In mode 11, "1" is set for a client and "2" is set for a server.
As the connection host name 12, a known server name is set. In this example, "NET-HOST" is the server name. Connection timeout 13
And the reception timeout 14 and the reception time 15 of one packet are
Any of them can be set within a range of 0.1 second to 600 seconds. The reception time 15 of one packet is preferably set to several seconds or less in consideration of the efficiency of the reception process.

Returning to FIG. 9, the head data 96 to the maximum size 99 specify the conditions of the packet to be received. That is, when the first byte data of the received packet matches the byte data indicated by the first data 96, the size of the packet (the number of bytes in this embodiment) is equal to the size indicated by the maximum size 99. It shows what is expected. Alternatively, if the last data of the packet matches the last data (1) 97 or the last data (2) 98, this indicates that the packet is completed regardless of the maximum size 99. Therefore, even if the packet does not match the maximum size of 99,
If the data at the beginning and end satisfy the conditions, it indicates that the packet can be treated as a complete packet as described above.

FIG. 11 is a display example of a reception specification setting screen 20 for setting these conditions. Up to ten combinations of four conditions from the first data 21 to the maximum size 24 can be registered. For example, in the set indicated by reference numeral 25, the first data 21 is 02H, that is, STX, and the last data (1) 22 is 03.
H, that is, ETX, and a packet having a maximum size 24 of 1024 bytes. This is because when the first byte of the received datagram is STX, when the last data is ETX, or when the received data is 10
When it becomes 24 bytes, it indicates that the packet is to be delivered to the upper process 85 as completed.

The set indicated by reference numeral 26 is the first data
21 is the case of ENQ, which is data meaningful in one byte, so the maximum size 24 is one byte, and the end data is not set. In other words, if ENQ is received, immediately
This indicates that the byte is to be transferred to the upper process 85.

The set indicated by reference numeral 27 is the first data
Numeral 21 indicates that the packet is delivered to the upper process 85 when the data at the end is CR or LF. Also in this case, if 130-byte data is received before the CR or LF comes, it indicates that the packet should be delivered at that point. As described above, in this embodiment, "**" can be used as a character representing a generic designation, that is, a so-called wild card character, as the leading data.

As other data, a maximum size of 24
Is specified in advance as a 1024-byte packet. This is effective when the user does not set the condition indicated by reference numeral 27 in the PAT90.

The screens shown in FIGS. 10 and 11 are displayed by an application program 85 shown in FIG. 8 for setting communication conditions. The value set on the screen by the user is reflected on the PAT90.
The application program request processing unit 81 refers to the PAT 90, specifies communication conditions to the protocol processing unit 82 based on the conditions, and requests processing.

Next, the operation of the embodiment will be described with reference to the flowcharts of FIGS. The application program request processing unit 81 includes an application program 85
Upon receiving an instruction to start communication, transmit or receive data in the form of a system call from the (upper process), the following operation is performed. <Establishment of Connection> The application program request processing unit 81 establishes a connection with the server as follows.

That is, as shown in FIG.
The parameters are read from T90 and copied to its own memory (step S101), and a request for securing a communication port is made to the protocol processing unit 82 (step S102), and a response is waited. at the same time,
The calling process 85 is put into a sleep state by blocking, and the control is transferred to another process 85. On the other hand, the protocol processing unit 82 secures a communication port (socket) and returns the result.

As shown in FIG. 1B, from the response of the protocol processing unit 82, the application program request processing unit 81 determines whether or not the socket has been secured, and if the socket has not been secured (No in S103). , An error is returned to the upper process 85. On the other hand, if the socket can be secured, the connection timeout value defined in the PAT 90 is sent to the protocol processing unit 82 and set (S104), and the PAT is also set.
Requests a connection with the server having the host name 92 defined in 90 (S105) and waits for a response. Protocol processing unit
82 measures the time using the internal clock means 84, attempts to establish a connection with the server within the previously set connection timeout value, and returns the result.

As shown in FIG. 1C, the application program request processing section 81 determines whether or not the response from the protocol processing section 82 has timed out (S106). Error is returned. On the other hand, if it is not time-out, it is determined whether or not a connection has been established (S107). If not, an error is returned to the upper process 85 to that effect. If the connection is established, the process ends normally and returns control to the upper process 85.

Note that the server executes the processing shown in FIG. 7 when the system is started, so that a connection request from a client can always be accepted. That is, a communication port is secured (S701), and if it is secured (S702; Yes), a client connection request is accepted (S703). UNI
For X machines, this usually ends with an accept () system call. <Reception of Data> The application program request processing unit 81 receives data from the server as follows.

That is, as shown in FIG.
The reception timeout value described in
(S201). Then, in this embodiment, if any data is received, it requests the protocol processing unit 82 to receive one byte so that the first byte is returned if the data is received (S203).

However, if a call is received from the upper process 85 specifying the number of received bytes, step S202
Then, the process proceeds to terminal A, as shown in FIG. 5, and requests reception of data of a designated number of bytes (S501), and waits for a response.
In this manner, the conventional method requests the protocol processing unit 82 to return the received data of the number of bytes required by the upper process 85. However, according to the present invention, the protocol processing unit 82 is first requested to return one byte of data in order to know what is the first byte of the datagram received first.

The operation when requesting reception of one byte will be described below. The protocol processing unit 82 has an internal clock
Time is counted using 84, wait for the datagram to arrive within the previously set reception timeout value, and return the result. That is, if a datagram arrives, the first byte of the datagram is returned; otherwise, a timeout error is returned.

As shown in FIG. 3, the application program request processing section 81 determines whether or not the response from the protocol processing section 82 has timed out (S301). return. On the other hand, if it is not time-out, the head data of the PAT90 is searched by the received 1-byte data, and the corresponding tail data and the maximum size are obtained (S302). FIG.
In the example of 1, the 1 received from the protocol processing unit 82
If the byte is STX, the end data is ETX and the maximum size is 1024. If the first data is ENQ, the last data is not specified, and the maximum size is 1. In all cases where the other data is the leading data, the trailing data is CR or LF and the maximum size is 130.

Therefore, the application program request processing unit 81 calculates the remaining size by subtracting the first byte already obtained from the maximum size (S303). As a result, if the remaining size is 0 (S304; Yes), the data reception has been completed, so the received packet is returned to the upper process 85, and the process ends normally. For example, if the received data is ENQ, one byte is returned and the process immediately ends.

On the other hand, if the remaining size is not 0 (S30)
4; No), a timeout value of 100 ms is first set in the protocol processing unit 82 in order to receive the remaining data to be sent subsequently (S305), and the 100 ms is subtracted from the packet timeout value 95 of the PAT90. (S306). Then, it specifies the remaining size and requests the protocol processing unit 82 to receive data (S307). Since the first datagram is considered to have arrived since the first byte has already been received, the value of 100 ms is set to a shorter value to capture the remaining data after the second byte. Is set to

In the example shown in FIG.
In the case of X, the maximum size 24 of the packet is 1024 bytes, but if the end data of the first datagram is ETX, the upper process 85 does not wait for the arrival of 1024 bytes.
Can return the received packet. Therefore, immediately after the first byte is received, the result can be immediately returned to the upper process 85 with a shorter timeout value.

FIG. 4 shows the receiving process for the second and subsequent bytes. As described above, the protocol processing unit 82
When 0 ms has elapsed, the datagram that has been received at that time is returned.
If there is received data (Step S401; Yes), the end byte data is compared with the end data (1) 97 or (2) 98 to determine whether it matches (S402). If they match, the packet is completed, so it is returned to the upper process 85 and the process ends normally. On the other hand, if it does not match any of the end data (1) 97 or (2) 98 (S403; No), the remaining size is recalculated by subtracting the number of bytes of the datagram received this time from the remaining size (S403). S404). As a result, if the remaining size is 0, the reception of the data of the predetermined size is completed, so the received packet is returned to the upper process 85, and the process ends normally.

On the other hand, if the remaining size is not 0, PAT
It is checked whether the remainder of the 90 packet timeout value 95 is 0 or more (S406). If 0, it means that a complete packet could not be received within the set time, so the currently received data is returned to the upper process 85 and a timeout error is notified. If the remainder of the packet timeout value 95 of the PAT 90 is equal to or greater than 0 (S406; Yes), the protocol processing unit 82 instructs the protocol processing unit 82 to receive the timeout value 30 in order to receive the remaining data to be sent subsequently.
0 ms is set (S407), and the 300 ms is subtracted from the packet timeout value 95 of the PAT90 (S40).
8). Then, it specifies the remaining size and requests the protocol processing unit 82 to receive data (S409). When there is a response to this request from the protocol processing unit 82, the application program request processing unit 81 resumes the process from step S401.

If there is no received data in step S401, the process jumps to step S406 to execute a packet timeout check. At this time, 300 ms is set as a timeout value in the protocol processing unit 82. This is because the packet was not completed in the first datagram reception, and it is clear that the packet is divided into two or more. Therefore, considering the processing time on the transmission side, the initial setting shown in FIG. The value is set to be longer than 100 ms so that the process does not monopolize the CPU.

As described above, upon receiving data, the application program 85 may issue a reception request once. In response to the single reception request, the application program request processing unit 81 determines whether a packet matching the conditions defined in the PAT 90 has been received,
Similarly, when a time-out error occurs after the time defined in the PAT 90 has elapsed, the application program 85
Will be notified. During that time, the application program request processing unit 81 and the protocol processing unit 82 all check the conditions and timeouts defined in the PAT 90, so that the application program 85 does not need to do anything.

When the upper process 85 makes a reception request by explicitly indicating the number of received bytes, the application program request processing section 81 executes the processing of FIG. 6 after the processing of FIG. This is the same as the processing shown in FIG. 4 except that steps S402 and S403 for comparing the last byte are omitted, and the other processing is completely the same.

[0038]

According to the present invention, since the application program 85 can receive a desired packet with only one reception request, the processing can be simplified and the program can be easily created. Further, when the desired data is not transmitted, a time-out error is returned in a predetermined time, so that an appropriate response can be taken without waiting forever. And
Since there is no need to frequently check the arrival of packets, the application will not monopolize the CPU,
The efficiency of the entire system is improved.

[Brief description of the drawings]

FIG. 1 is a flowchart illustrating a processing procedure for starting communication of a client in an embodiment.

FIG. 2 is a flowchart showing a processing procedure of a 1-byte reception instruction in the embodiment.

FIG. 3 is a flowchart showing a processing procedure after reception of a first byte in the embodiment.

FIG. 4 is a flowchart illustrating a processing procedure of reception processing of a second byte and subsequent bytes in the embodiment.

FIG. 5 is a flowchart illustrating a processing procedure of an instruction to receive a designated byte in the embodiment.

FIG. 6 is a flowchart illustrating a processing procedure of reception processing for a second byte and subsequent bytes in the embodiment.

FIG. 7 is a flowchart illustrating a procedure of a communication start process of a server in the embodiment.

FIG. 8 is a block diagram illustrating a configuration of an information processing apparatus including a communication interface according to the embodiment.

FIG. 9 is a diagram illustrating a configuration example of a parameter table in the embodiment.

FIG. 10 is a diagram showing a display example of a basic specification setting screen in the embodiment.

FIG. 11 is a diagram showing a display example of a reception specification setting screen in the embodiment.

[Explanation of symbols]

 10 Basic specification setting screen 20 Reception specification setting screen 80 Information equipment 81 Application program request processing section 82 Protocol processing section 83 Data transmission / reception means 84 Clocking means 85 Application program 86 Ethernet line 87 Communication interface 90 Parameter table

Claims (7)

[Claims] 1. A communication interface comprising: a protocol processing unit for transmitting and receiving data to and from a partner device; and a request processing unit for requesting the protocol processing unit to perform a communication process in response to a request from an application program. An application program for requesting communication processing from the protocol processing means based on the conditions described in the table. A communication interface configured to receive data of a condition described in the table in response to one reception request from the server and return the received data to the application program. 2. The table describes at least the reception time of one packet, and the request processing means designates a time shorter than the reception time of the one packet and requests the protocol processing means to receive data. 2. The communication according to claim 1, wherein the request is repeated, and the protocol processing means includes a time measuring means, and when a time designated by the request processing means elapses, the data received at that time is returned. interface. 3. The table further describes the size of one packet.
If data equal to the size of the one packet is received within the packet reception time, an acknowledgment is returned with the data to the requesting application program,
The communication interface according to claim 2, wherein an error is returned to the requesting application program if data equal to the size of the one packet is not received within the reception time of the one packet. 4. The table may further describe start data and end data of a packet, and the request processing means may determine that both the start and end data of the data received within the reception time of the one packet are the same. When the header data matches the head data and the tail data described in the table, an acknowledgment is returned to the requesting application program together with the data. 3. The communication interface according to claim 2, wherein an error is returned to the application program. 5. The communication interface according to claim 2, wherein a wildcard character can be used as the head data. 6. The request processing means, wherein, within the reception time of the one packet, both the leading and trailing data of the received data match the leading and trailing data described in the table, respectively, or 6. The communication interface according to claim 3, wherein a response is returned to the requesting application program when data equal to the size of the one packet is received. 7. The protocol processing means according to claim 1, wherein
2. The method according to claim 1, wherein a P procedure is performed.
7. The communication interface according to any one of claims 6 to 7.