JPH04329047A - Transmission control processing method - Google Patents

Abstract

PURPOSE:To create a program not notifying a protocol (procedure) by forming the program of each processing while parameters are formed as a table. CONSTITUTION:A program of each processing is formed by forming parameters as a table. In this case, when processing is given from protocol dependent function address tables 7, 10 for each protocol to a common routine 13, a reply to the information of the protocol dependent function address tables 7, 10 for each protocol and to a command/response received by a transport data tables 8, 11 are implemented in a common routine 13. Moreover, a relevant command/ response is set to a transfer control level header 9 (procedure A), 12 (procedure B) by the transport data tables 8, 11 in the common routine 13. Then the common routine 13 itself is operated to notify each protocol to the tables 7, 10 and the tables 8, 11 without notifying each protocol.

Description

[Detailed description of the invention]

0001

[Field of Industrial Application] The present invention relates to a transmission control processing method, and particularly to a transfer control level (transport control) of a high-level transmission control procedure in communication control between a terminal device and a computer or between computers. level, see Figure 12) or OSI (Open System
The present invention relates to a transmission control processing method that facilitates the development of a plurality of transmission control procedures in the development of the transport layer, session layer, and presentation layer of s Interconnection (see FIG. 13).

0002

2. Description of the Related Art As an example, FIG. 14 shows an outline of processing at the transfer control level of a high-level transfer control procedure in conventional communication control. As shown in the figure, conventionally, (a) first, the transfer control level passed from the data link level;
Control is passed from the header 14 to the corresponding processing routine 16 in the transfer control level transition table 15 that defines the operation of each command/response. (b) The processing routine 16 refers to/updates each control table 17, processes each command/response, sets each command/response in the transfer control level header 18, and passes control to the data link level. (c) Also, in the processing routine 16, the transfer control level
If there is a header 18 + message, the message is passed to the user level (AP program). Regarding this, for example, see the Institute of Electronics, Information and Communication Engineers, ``
You can refer to the description in Section 26, Section 3 of "Electronic Information and Communication Handbook" (Ohmsha, 1988).

0003

However, in the above-mentioned prior art, it is necessary to create a predetermined number of processing routines 19 for each command/response operation from the transfer control level transition table 15. In addition, multiple procedures within the same system, such as IBM's SDL
Since the transfer control level specifications (see FIG. 15) differ between the C procedure and the HDLC procedure developed by Hitachi, Ltd. in Japan, there was a problem in that twice as many processing routines had to be created. Furthermore, when the transfer control level is changed or modified, it takes a lot of time to review the transfer control level transition table 15 mentioned above and review, change, and modify each processing routine, and more bugs occur. Another problem was that it was very difficult to change or modify the transfer control level. The present invention has been made in view of the above circumstances, and its purpose is to solve the above-mentioned problems in the conventional technology and improve the transfer control level of high-level transmission control procedures or the transport layer of OSI. In the development of session layer and presentation layer, protocols (procedures)
An object of the present invention is to provide a transmission control processing method that enables the creation of a program without being aware of this. Another object of the present invention is to provide a transmission control processing method that is easy to develop multiple protocols within the same system.

0004

[Means for Solving the Problems] The above object of the present invention is to provide transfer control level processing in a high level transmission control procedure;
Alternatively, in a transmission control processing method at a transport level, a session level, and a presentation level in OSI, the programs for each of the above processes are configured to be protocol-independent by creating a table of parameters. This is achieved by a transmission control processing method.

[0005]

[Operation] In the transmission control processing method according to the present invention, parameters are tabulated as shown in FIG. 16 in the development of the transfer control level of high-level transmission control procedures or the transport layer, session layer, and presentation layer of OSI. By doing so, it is possible to use a program that is not conscious of protocols (procedures), and various transmission control procedures can be realized. This reduces the number of programs (each processing routine) to be developed, making it possible to improve the efficiency of program creation.

[0006]

[Example] Before explaining the embodiment of the present invention, FIG.
7, we will explain the protocol hierarchy and text format. (a) The text format received from the other party's computer or terminal device over the physical line is passed from the physical line level to the data link level and then to the transfer control level. (b) At this time, the transfer control level is the transfer control level header 4 with data link level header (F, A, C) 3 and data link level trailer (FCS, F) 6 removed, or transfer Control level header 4 + message 5 is passed. (c) At the transfer control level, transfer control level header 4
+Telegram 5, the transfer control level header 4 is removed and the message 5 is passed to the user level (AP program). (d) Also, at the transfer control level, the user level (AP
Regarding the message 5 passed from the program), a transfer control level header 4 is added and the message is passed to the data link level. (e) At the data link level, transfer control level header 4 + message 5 passed from the transfer control level is added to data link level header (F, A, C) 3 and data link level trailer (FCS, F) 6. is added and passed to the physical line level. (f) At the physical line level, the text format is transmitted to the other party's computer or terminal device using the physical line.

[0007] Hereinafter, a transmission control processing method using parameter tabulation according to the present invention will be explained based on FIGS. 1 to 11. FIGS. 1 and 2 are flowcharts showing the operation of an embodiment to which the present invention is applied. Figures 3 and 4 are explanatory diagrams of event check table analysis operation, Figures 5 and 6
is an explanatory diagram of the status acquisition process, FIG. 7 is an explanatory diagram of the routine selection call process, FIG. 8 is an explanatory diagram of the routine call process, FIG. 9 is an explanatory diagram of the common routine process, FIGS. 10 and 11
is an explanatory diagram of the relationship between a transport data table and a transfer control level protocol format. First, the characteristics of the main tables used in the embodiments of the present invention will be explained. (1) Protocol compatible function address table (IAD)
T): The protocol-compatible function address table shown in 7 or 10 in FIG. 16 is a table for remembering each protocol-compatible function address at the transfer control level, and
As shown in FIG. 8, it is composed of a common section that stores table identifiers, the number of valid entries, etc., and an individual section that stores processing types, data entry numbers, etc., details of which are shown in FIG. (2) Transport data table (IDAT):
The transport data table shown at 8 or 11 in FIG. 16 is a table used when the protocol format of the transfer control level is registered and the message format is transmitted using the registration number.
As shown in FIG. 11, there is a common part that stores table identifiers, effective entry lengths, etc.
It is composed of individual parts in which the effective length of the first data is stored. Note that other tables will be explained each time they appear. The outline of the transmission control processing method using parameter tabulation according to this embodiment will be explained below, focusing on FIGS. 1 and 2. Step 21: The text format received from the other party's computer or terminal device over the physical line is passed from the physical line level to the data link level to the transfer control level. Step 22: At the transfer control level, first, the command/response of the transfer control level header is checked.

Step 23: Next, the process is performed with reference to the transfer control level transition table. The details of the process will be explained below. (1) Since the processing units in the transfer control level transition table are complex, they are subdivided into the smallest processing units and are also converted into codes (referred to as "trigger internal codes"). (2) In the trigger internal code conversion process (step 24), the trigger internal code is obtained from the command/response of the transfer control level header. The details are as follows. ■In the event check table (IECK) analysis process (step 25), check is performed from the event check table using the command code check position, command code check effective length, and comparison target command of the relevant transfer control level header, and the trigger internal Ask for code. Hereinafter, based on FIGS. 3 and 4, the example message format and event check table analysis operation shown above will be explained. (a) Set the event check display ■ in the event check table to "Check not required" and set the command check display "■" to check required. ■ to ■ indicate that the information in the message format is set in the corresponding location of the event check table. (b) Command code check position ■ is (1) to (4)
), specifying the length from the start position of the transfer control level header. (c) Command code check effective length ■(1) to (4)
Set the length to check. (d) Continuously set the contents to be checked in the comparison target commands, and check the command check positions (1) to (4) above.
, command code check effective length (1) to (4) are checked, and if they match, the aforementioned trigger internal code 40 is obtained.

(3) In the status acquisition call process (step 26), using the trigger internal code obtained in the above-described trigger internal code conversion process, the protocol compatible function address and
Find the table entry number. The details are as follows. ■In the status acquisition process (step 27), the transport path management table (I
TLC) to obtain the address of the status/trigger table. The details of the above operation will be explained below based on FIGS. 5 and 6. (a) Based on the status/trigger table of the address, the protocol compatible function address table/ Ask for entry number. (b) Here, the individual parts of the status/trigger table are organized into groups for each status, and the trigger internal code is associated with the address.
41) Find the relative position by x ISTT common part total number of triggers (44) + trigger internal code (40). (c) From the start of the status/trigger table (42) + common part size (43) + the value obtained in (b) above,
Protocol compatible function address table entry number (
47). (4) In the routine selection call process (step 28),
The entry address of the corresponding protocol compatible function address table is obtained from the protocol compatible function address table entry number obtained in the above-mentioned status acquisition call process. The details are as follows (see FIG. 7). (2) Find the start address (48) of the protocol compatible function address table from the common part of the transport path management table of the path. ■From the start address of the protocol compatible function address table (48) + common manager (49) + (protocol compatible function address table entry number (47) - 1) x individual manager (50), the corresponding protocol compatible function address Find the address (51) of the table.

(5) Routine call processing (step 30
), the address (52) of the transfer control level/processing module (common routine) is obtained from the address of the protocol compatible function address table obtained from the routine selection call process described above. The details are as follows (see FIG. 8). (2) Transfer control to the address (52) of the transfer control level/processing module (common routine) determined above (steps 32 to 34). (6) An example of the processing of the processing module (common routine) is shown in FIG. ■In step 61, the transport
Check the status of the relevant path from the path management table. (2) In step 62, a process is selected according to the process type in the protocol compatible function address table. It also refers to the update status, update type, timer type, timer identifier, timer setting type, etc., and performs processing. ■The transport data table registers the transfer control level protocol format. In step 63, from the data entry number of the protocol compatible function address table,
Ask for the corresponding format. ■In the common part of the transport data table, there is a specification for assembling, that is, message assembly identification, a command distribution position that specifies the relative position of information that identifies the message, and a length of the information that identifies the message. There is a command distribution length. (a) Compare the content of the message requested to be assembled with the leading data set in the transport data table individual section, and search for the corresponding entry. (b) Determine whether or not code conversion is necessary from the corresponding entry, and if necessary, perform processing according to the code conversion procedure in (c) (step 64). (c) Transfer the transfer control level header set in the individual section of the transport data table to the transmission buffer, and pass control to the data ring level (step 65
).

[0011] A supplementary explanation of the above-mentioned table will be given below. First, the protocol compatible function address table shown in FIGS. 7 and 8 will be explained. (1) As mentioned above, the structure of the table consists of one common part and a plurality of (N) individual parts. (2) The common part includes a table identifier for setting the name or ID of the protocol compatible address table, the number of valid entries for setting the number of individual parts (here N), and individual part 1.
It consists of an individual section that sets the size of each piece, and a common section that sets the size of the common section. (3) In addition, the individual section includes the transfer control level module address (or name table of the relevant module) that sets the address of the applicable processing module, the processing type that sets the processing type of the applicable processing module, and the update that sets the update status. Status, update type to set the status update type (individual update, all path update, no update, etc.), data entry number to set the data entry number of the transport data table individual section, timer type to set the timer type, Timer identifier to set the identifier of timer processing (cancel, set, timeout, etc.), timer setting type to set the type of timer setting, return code to set the return code to be returned to the upper interface, generator to set the type to be generated. It has columns for rate type, notification type for setting the notification type to the upper interface, and message type for setting the message type.

Next, the transport data table shown in FIGS. 10 and 11 will be explained. (1) The structure of the table is similar to the protocol compatible function address table described above, with one common part and multiple (N
It consists of individual parts. (2) The common part is the protocol compatible function address and
Similar to the table, a table identifier that sets the name or ID of the transport data table, the number of valid entries that sets the number of individual parts (here N), and individual part 1
In addition to the individual manager that sets the size of each message and the common manager that sets the size of the common part, command distribution positions (1) to (
4), and command distribution lengths (1) to (4) for setting the length of data for distributing message types. (3) The individual section also includes a data entry number that sets the entry number corresponding to each stored message format, an assemble flag that sets whether or not assembling is required, and leading data that sets the length of the protocol format from the beginning. Set the effective length, the relative position of the message that requires code conversion, the relative position of the code conversion target, and set whether the data consists of only transport data or transport data that includes AP messages. It has columns for starting data for setting data type and transport data format for each protocol.

Although not specifically described in the above embodiments, according to the present invention, it is possible to easily develop a plurality of protocols within the same system. This will be explained below. FIG. 16 shown earlier shows protocol compatible function address tables 7 (procedure A) and 10 (procedure B) for each different protocol (procedure), and transport data tables 8 (procedure A) and 11 (procedure B).
)have. Transfer control level protocol format 9 is included in the individual section of the transport data table 8.
Set. Also, transport data table 1
A transfer control level/protocol format 12 is set for each individual section. Regarding this, in Fig. 15,
Please refer to the differences in format depending on the procedure. Protocol compatible function address table 7 for each protocol,
When processing is passed from 10 to the common routine 13, the common routine 13 uses the information in the protocol-compatible function address tables 7 and 10 for each protocol and the command/command received from the transport data tables 8 and 11. Respond to the response. The common routine 13 also includes transport data tables 8 and 1.
1, transfer control level headers 9 (procedure A), 12 (
Set the corresponding command/response in step B). Furthermore, the common routine 13 automatically uses the protocol compatible function address tables 7 and 10 and the transport data tables 8 and 1 without being aware of each protocol.
First, it works to make you aware of each protocol. According to this embodiment, it is possible to easily develop multiple protocols within the same system. It should be noted that each of the above embodiments is an example of the present invention, and it goes without saying that the present invention should not be limited thereto.

[0014]

[Effects of the Invention] As described above in detail, the present invention has the remarkable effect of making it possible to use a program that is not aware of protocols and realizing various transmission control procedures. .

[0015]

[Brief explanation of drawings]

FIG. 1 is a part of an operation flow diagram showing the operation of an embodiment of the present invention.

FIG. 2 is another part of an operation flow diagram showing the operation of an embodiment of the present invention.

FIG. 3 is an explanatory diagram (part 1) showing the analysis operation of IECK according to the embodiment.

FIG. 4 is an explanatory diagram (part 2) showing the analysis operation of IECK according to the embodiment.

FIG. 5 is an explanatory diagram (part 1) showing status acquisition processing in the embodiment.

FIG. 6 is an explanatory diagram (part 2) showing status acquisition processing in the embodiment.

FIG. 7 is an explanatory diagram showing routine selection call processing in the embodiment.

FIG. 8 is an explanatory diagram showing routine call processing in the embodiment.

FIG. 9 is a diagram illustrating an example of processing of a processing-specific module (common routine) in the embodiment.

FIG. 10 is a diagram (part 1) showing the relationship between IDTA and transfer control level/protocol format in the embodiment.

FIG. 11 is a diagram (part 2) showing the relationship between IDTA and transfer control level/protocol format in the embodiment.

FIG. 12 is a diagram showing a hierarchical structure of a high-level transmission control procedure.

FIG. 13 is a diagram showing the hierarchical structure of OSI.

FIG. 14 is a diagram illustrating conventional transfer control level processing.

FIG. 15 is a diagram showing format differences in conventional transfer control level procedures.

FIG. 16 is a diagram showing an overview of the operation of an embodiment of the present invention.

FIG. 17 is a diagram showing the layered structure and text format of the protocol.

[Explanation of symbols]

IECK: Event check table, ITLC: Transport path management table, ISTT: Status trigger table, IADT: Protocol compatible function address table, IDAT: Transport data table.
table.

Claims (3)

[Claims] Claim 1: In a transfer control level process in a high-level transmission control procedure, or in a transport level, session level, and presentation level transmission control process method in OSI, a program for each process is written in a table with parameters. A transmission control processing method characterized in that the configuration is made such that the protocol is not conscious. 2. The table includes a transfer control level, or a protocol compatible function address table for remembering each function address corresponding to the protocol at the transport level, session level, and presentation level in OSI, and a transfer control level. 2. The transmission control processing method according to claim 1, further comprising using a transport data table in which protocol formats of the data are registered. 3. The transfer control level or OSI
The transition table used in transport level, session level, and presentation level processing is subdivided into the smallest processing units and coded, and the code is used to search the protocol compatible function address table, and the protocol From the search results of the corresponding function address table, the transfer control level, the transport level in OSI, the session level,
The address of the presentation level processing module (common routine) is searched, and the processing module is the transfer control level, or the transport level, session level, presentation in OSI, which corresponds to the protocol compatible function address table. 3. The transmission control processing method according to claim 2, further comprising selecting a level protocol format.