Emulator apparatus

The present invention relates to a technique for testing a communication protocol stack between computers interconnected via a network.

When testing the developed communication protocol stack, for example, the TCP protocol stack, it is common to test with the system configuration shown in FIG. For example, as shown in Fig. 14 (a), a computer equipped with the TCP protocol stack to be tested and another computer equipped with the TCP protocol stack tested are connected to each other via a network. Test various sequences.

Alternatively, a WAN (Wide Area Network) speed-up device or the like performs protocol conversion for TCP when communicating between computers A and B. When testing such a device, place computers A and B with the tested TCP protocol stack end-to-end and test between computers A and B, as shown in Figure 14 (b). The configuration in which the target WAN acceleration device is arranged is common. With such a configuration, the network system shown in the figure is tested by performing TCP communication from end to end.

In TCP, RFC (Request for Comment) defines a wide variety of operation sequences such as simultaneous connection establishment. An example is shown in FIG. FIG. 15 is an operation sequence diagram for establishing a simultaneous connection. In the simultaneous connection establishment sequence, as shown in FIG. 15, each of the two computers connected to each other via the network sends a connection request to the other side and waits for the connection request from the other side. Then, when each computer receives the connection request from the other party, it waits for approval by an acknowledgment for the transmitted connection request. Upon receipt of the acknowledgment on each computer, the connection is established and the sequence is complete.

In the simultaneous connection establishment sequence, the timing of transmitting the connection request to the other party is not triggered by the reception of the packet from the other party, so it is difficult to take the timing.

Here, as a known technique, in communication according to TCP / IP (Internet Protocol), a PCU (Protocol Data Unit) between communication systems is acquired and analyzed, and an event sequence is estimated and emulated based on the contents. (For example, Patent Document 1) provides a technique for analyzing the details of communication by performing the above.

In addition, regarding the technology for testing TCP / IP, a technology for reproducing a problem of TCP / IP by processing traffic data in a pseudo communication environment built in a communication network emulator device is also provided (for example, a patent). Reference 2).<patcit num="1"><text>Japanese Unexamined Patent Publication No. 11-27308</text></patcit><patcit num="2"><text>Japanese Unexamined Patent Publication No. 2004-201121</text></patcit>

<p> As mentioned above, TCP defines many operation sequences, and these operations are specified. It is necessary to test the operation sequence by operating it arbitrarily in the above test configuration and verify the operation. However, some of these operation sequences are difficult to operate in the conventional system configuration.</p><p> An object of the present invention is to provide a technique capable of generating various operation sequences and verifying the normality of protocol operation in a protocol stack test.</p>

<p> In order to solve the above problems, the disclosed emulator device is an emulator device connected to a test target device equipped with a communication protocol stack to be tested via a network, and the emulator device side in a sequence to be tested. When a scenario describing a series of operations to be executed is input, the management means that determines the operation to be executed and gives an activation notification by referring to the scenario, and the operation that receives the activation notification from the management means. The configuration includes an execution means that reads from the scenario, executes it, and generates a packet to be transmitted to the test target device.</p><p> In order to determine and execute the operation to be executed according to the contents described in the input scenario, define the response to the packet received from the device under test, for example, as in the test for the simultaneous connection establishment sequence. It is possible to realize a sequence that was difficult to implement by itself. This makes it possible to verify the operation of the protocol stack under various situations.</p><p> In the scenario, the identification information for identifying the operation and the destination operation identification information including the identification information to be executed next to the operation are described in association with each operation, and the management means is described. At the timing when the scenario is input or when the operation end notification is received from the execution means, the movement destination operation identification information associated with the operation is read out, and the operation activation notification indicated by the movement destination operation identification information is read. May be configured to be transmitted to the execution means.</p>

<p> According to the disclosed emulator, the operation is executed according to the input scenario, and the packet to be transmitted to the opposite computer which is the test target device is generated and transmitted. This makes it possible to realize various operation sequences and verify the operation of the protocol stack under various situations.</p>

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 is a functional block diagram of a computer including the TCP emulator according to the present embodiment. The computer 1 shown in FIG. 1 is connected to another computer equipped with the protocol stack to be tested via a network, and is connected to the operation system unit (hereinafter referred to as the OS) 2 and the TCP (Transmission Control Protocol) emulator unit (hereinafter referred to as the emulator). Includes 3 and.

OS2 includes a packet bypass processing section 21, a protocol stack section 22, and a bypass condition table 23. Emulator 3 is a program that emulates TCP operations, gives a series of operations specified in RFC (Request for Comment) as a scenario, and realizes each operation sequence in a pseudo manner. The emulator 3 shown in FIG. 1 includes a reception processing unit 31, a scenario step management unit 32, a step execution processing unit 33, a standard TCP emulation unit 34, a transmission processing unit 36, and a save buffer 35.

The packet bypass processing unit 21 of the OS2 determines whether the packet transmitted from another computer via the network should be passed to the emulator 3 or processed in the OS2, and sorts the packet.

The protocol stack unit 22 has a tested TCP protocol stack, and the packet bypass processing unit 21 processes a packet determined to be processed in OS2. The bypass condition table 23 stores the conditions for making a determination for packet distribution in the packet bypass processing unit 21.

The reception processing unit 31 of the emulator 3 receives from the OS 2 a packet determined by the packet bypass processing unit 21 of the OS 2 to be processed by the emulator 3. The scenario step management unit 32 manages the scenario execution by reading the scenario S of the test input to the computer 1 by the user, determining the operation to be executed next, and executing the scenario S.

Here, the "scenario" is defined as describing the operation to be executed in the own device, that is, the computer 1 provided with the emulator 2 when executing a certain operation sequence with the opposite computer (another computer). The operations that are sequentially executed in the computer 1 according to the scenario include an operation that is executed as a response to a packet received from the opposite computer side and an operation that is actively executed from the own device to the opposite computer side. is there. Hereinafter, in the present embodiment, each operation executed at a certain timing is referred to as a step.

The step execution processing unit 33 executes the step instructed by the scenario step management unit 32. The standard TCP emulation unit 34 passes necessary information to and from the step execution processing unit 33 to emulate the operation of the standard TCP.

The save buffer 35 is a buffer for saving necessary data when the step execution processing unit 33 executes a step. Specifically, one entry contains an identifier and received data. Of these, the identifier consists of identification information for identifying each step described in the scenario, and is added to the received data when the received data is saved in the save buffer 35. When restoring the saved data, the save buffer 35 is searched using the identification information described in the scenario as a search key, and the matching data is extracted.

The transmission processing unit 36 transmits the packet obtained as a result of the step execution in the step execution processing unit 33 (and the standard TCP emulation unit 34) to the opposite computer side. When testing a WAN (Wide Area Network) speed-up device, etc. with the configuration shown in Fig. 13 above, Fig. 1 is applied to one or both of the computers connected to each other via the network. Apply a computer equipped with emulator 3 shown in.

Further, the determination by the packet bypass processing unit 21 of the OS2 is not essential, and all the packets received from the other party's computer may be passed to the emulator 3.

FIG. 2 is a flowchart showing the entire processing in the computer 1. Of the series of processes from step S1 to step S5 shown in FIG. 2, the process by the emulator 3 according to the present embodiment is the process from step S3 to step S5.

First, the process of FIG. 2 is started when a packet is received from the other computer, and in step S1, packet bypass processing is performed to determine whether the packet should be processed by OS2 or emulator 3. If it is determined that the packet should be processed by OS2, the process proceeds to step S2, and the TCP protocol stack unit 22 in OS2 executes the packet processing. If it is determined in step S1 that the received packet should be processed by the emulator 3, the process proceeds to step S3.

In step S3, the reception processing unit 31 of the emulator 3 receives the packet from OS2, and in step S4, executes a predetermined step according to the scenario. Here, the scenario step management unit 32 notifies the step execution processing unit 33 in advance of the steps to be executed in the scenario. The step execution processing unit 33 recognizes the step instructed by the scenario step management unit 32 in advance, and starts executing the instructed step when the emulator 3 receives the packet transmitted from the other party. To do. When the step execution is completed, the step execution processing unit 33 notifies the scenario step management unit 32 that the step execution is completed. The scenario step management unit 32 determines the next step to be executed by the end notification from the step execution processing unit 33, and gives the information to the step execution processing unit 33.

As described in the description of each functional block in FIG. 1, when the step is executed, the standard TCP emulation unit 34 is made to execute the standard TCP processing as necessary. When the step execution process is completed, the process proceeds to step S5. In step S5, the packet generated by executing the step is sent to the other computer, and the process ends.

By executing the processes of steps S1 to S5 shown in FIG. 2, a packet is transmitted from the computer 1 to the other computer. As described above, the packet transmission process from the computer 1 includes a transmission process as a response to a packet received from the other party's computer and a process of actively transmitting the packet from the own device to the other party. Which of the packets transmitted by the process in Fig. 2 is due depends on the description of the scenario. Next, the scenario will be described.

FIG. 3 is a diagram showing an example of a scenario. Of the scenarios shown in the figure, the sentences starting with the "#" symbol (second line, third line, ...) are comment sentences. Emulator 3 reads the sentences (1st line, 4th line, 6th line, ...) of the line without the symbol "#" in order from the beginning of the scenario.

In the scenario, describe the operation for each step. One step contains an identifier, an action definition and a step transition word. The identifier is identification information that makes it possible to uniquely identify a certain step. In the scenario example of FIG. 3, "identifier 1" and "identifier 2" described in the first line and the eighth line correspond to this, respectively.

An action definition is defined as a description of a single or multiple actions described in the same step. Here, the action definition is classified into (1) active action definition and (2) passive action definition. Of these, the active action definition in (1) describes the action for the computer 1 side equipped with the emulator 3 to voluntarily send data to the other side. In the passive action definition of (2), the action for responding to the received data from the other party is described.

A step transition word is defined as a dedicated description prepared to indicate which step action definition is to be executed after executing the action definition for a certain step. Example scenario in Figure 3 Then, "move to identifier 2" and "move to identifier 1" on the 4th and 6th lines correspond to the step transition words, respectively.

The contents of the operation definition will be described more specifically. Within one step, write either an active action definition or a passive action definition. Of these, the content of the transmission data and the transition destination TCP state are described in the active action definition. The transition destination TCP state indicates the TCP state of the protocol stack that transitions after executing processing according to the description of the operation definition and transmitting a packet, and can be omitted. When the transition destination TCP state is omitted, the behavior is the same as that of standard TCP. In Fig. 3, the 11th line corresponds to the active action definition.

In the passive operation definition, the received data condition, the save / restore instruction of the received data, the content of the response data, and the transition destination TCP state are described. The passive motion definition corresponds to the 4th and 6th lines in Fig. 3.

In the embodiment, the received data condition consists of the information set in the TCP segment among the packets received from the other party. In the passive action definition, it is possible to describe multiple action definitions in one step. When writing multiple passive action definitions in one step, it is necessary to set different received data conditions.

Further, the received data condition can be omitted. When the description of the received data condition is omitted, a predetermined operation is selected for all the received data. The save / restore instruction of the received data consists of an instruction to save the data of the received packet to a predetermined area of the save buffer 35 or to restore the data of the save buffer 35 from the predetermined area.

In the embodiment, the content of the response data includes the content of the data included in the packet returned to the other party as a response. The transition destination TCP state is the same as the transition destination TCP state included in the active action definition, and indicates the TCP state of the protocol stack that transitions after executing processing according to the description of the action definition and transmitting a packet.

The content of the response data and the transition destination TCP state can be omitted. A specific method for realizing the sequence test referred to in RFC793 by the emulator 3 according to the present embodiment will be described using a scenario created according to the above rules.

FIG. 4 is a diagram illustrating a test method of the simultaneous connection establishment sequence. When a connection request is received from the opposite computer (the other computer equipped with the protocol stack to be tested) in order to test the simultaneous connection establishment sequence, the emulator 3 returns the connection request to the opposite computer (). Lines 1 to 4 of the scenario).

When the opposite computer returns a response to the transmitted connection request, the emulator 3 returns an response (ACK) to the connection request from the opposite computer (lines 7 to 9 of the scenario).

Thus, in order to test the sequence of simultaneous connection establishment, when a connection request is received from the opposite computer, the emulator 3 sends a connection request to the opposite computer before returning a response to the received connection request. To do. A process in which a connection request is sent to each other with the other computer and a response is returned to each other in response to the connection request from the other side. Can be executed.

FIG. 5 is a diagram illustrating a sequence test method for recovery processing from an old duplicate sequence. In order to simulate the response to the old duplicate sequence number (SYN), the emulator 3 saves the sequence number SEQ = 100 received from the TCP under test, that is, the opposite computer, to the save buffer 35, and saves it in the save buffer 35. Returns SYN + ACK corresponding to a younger sequence number. That is, it returns a response to the sequence number 100-10 = 90, which is older than the actually received sequence number (lines 1 to 5 of the scenario).

When a connection reset request is received from the opposite computer, the saved sequence number SEQ = 100 is restored and a response is returned (lines 7 to 9 of the scenario). In this way, since the opposite computer receives the response to the sequence number older than the actually transmitted sequence number, the opposite computer, that is, the computer equipped with the protocol stack to be tested, performs the recovery process from the old sequence. It is possible to test whether it can be executed normally.

FIG. 6 is a diagram illustrating a test method for a sequence of simultaneous closing. When the emulator 3 receives a "FIN" indicating that there is no subsequent data from the computer equipped with the protocol stack to be tested, the emulator 3 saves the received "FIN" to a predetermined area of the save buffer 35 and saves the received "FIN" to a predetermined area of the save buffer 35. , Send "FIN" to the other party's computer (lines 1 to 5 of the scenario).

Upon receiving the response to the transmitted FIN, the emulator 3 restores the saved "FIN" from the predetermined area of the save buffer 35, and sends the response to the FIN received by its own device to the other computer. Returns (lines 7-10 of the scenario).

In this way, the sequence of simultaneous closing is performed by first sending the FIN, receiving the response from the other party, and then returning the response to the received FIN, instead of returning the response to the received FIN immediately. It will be possible to test.

FIG. 7 is a diagram illustrating a test method for the sequence of recovery from a half-open connection. In the test of the recovery sequence from the half-open connection, it is assumed that TCP on the opposite computer crashed. Emulator 3 returns an old (young) number response (ACK) to the connection request (sequence number SEQ = 400) from the opposite computer side in order to pretend to keep the connection (scenarios 1 to 5). Line).

On the other side of the computer that receives the response with the old number, the connection is first initialized (CTL = RST), and then the connection request (sequence number SEQ = 400) is retransmitted. In this way, by returning a response with a number lower than the sequence number of the connection request actually received by the emulator 3, it is possible to realize the recovery operation from the half-open connection.

As described above, the emulator 3 according to the present embodiment determines which of the steps described in the scenario should be executed, and executes a predetermined operation according to the contents described in the step of the scenario. Therefore, it is possible to test a sequence that is difficult to generate in a configuration that responds according to a packet actually received from the opposite computer, such as the above-mentioned simultaneous connection establishment sequence.

Hereinafter, specific processing methods will be described for each part of the computer 1 equipped with the emulator 3 according to the present embodiment. FIG. 8 is a flowchart showing packet bypass processing in the packet bypass processing unit 21 of OS2. The process shown in FIG. 8 is started when the OS2 recognizes the packet transmitted from the other party.

First, in step S11, the bypass condition table 23 is referred to, and it is determined whether or not the values set in the predetermined fields of the received packets match the conditions stored in the bypass condition table 23. The bypass condition table will be described later.

In the determination in step S11, if the value of the predetermined field of the received packet matches the value stored in the bypass condition table 23, the process proceeds to step S12, the packet is transferred to the emulator 3, and the process ends.

In the determination of step S11, if the value of the predetermined field of the received packet does not match the value stored in the bypass condition table 23, the process proceeds to step S13, the packet is transferred to the protocol stack unit 22 of OS2, and processing is performed. finish.

The bypass condition table 23 referred to in step S11 above is a table referenced by the packet bypass processing unit 21, and in the embodiment, one entry is a destination IP (Internet Protocol) address, a source IP address, and a destination. It consists of four pieces of information: port number and source port number.

FIG. 9 is a flowchart showing the scenario step management process by the scenario step management unit 32 of the emulator 3. In the embodiment, the scenario for the test to be started from now on is started when the user registers it in the computer 1.

First, in step S21, the step to be executed first is searched from the registered scenarios. In step S22, as a result of the search, it is determined whether or not there is a step to be executed. Here, the step to be executed is an operation (that is, a step) that has not yet been executed among the steps described by the registered scenario, and the operation to be executed next on the computer 1 at the timing of performing the search. Refers to the step that describes.

If it is determined in step S22 that the step to be executed cannot be obtained as a result of the search, no particular process is performed and the process proceeds to step S27. On the other hand, if it is determined in step S22 that there is a step to be executed, the process proceeds to step S23, and a start notification is given to the step execution processing unit 33. Then, in step S24, the end notification from the step execution processing unit 33 is awaited. Upon receiving the end notification, the process proceeds to step S25, and it is determined whether or not the process has ended normally as a result of executing the step.

If it is determined to end normally in step S25, the process proceeds to step S27, but if it is determined to end abnormally, the process proceeds to step S26, notifies the user of the content of the abnormality, and then proceeds to step S27. ..

In step S27, the scenario step management unit 32 refers to the scenario, searches for the next step to be executed, and returns to step S22. After that, the same process is repeated until all the steps described in a certain scenario are completed.

FIG. 10 is a flowchart showing the step execution process by the step execution process unit 33 ( That is 1). The process shown in FIG. 10 is started when the activation notification is received from the scenario step management unit 32.

First, in step S31, among the scenarios, the action definition of the step for which the activation notification is received from the scenario step management unit 32 is collated, and in step S32, it is determined whether or not the action definition is a passive action definition. In the case of a passive motion definition, the process proceeds to the process shown in FIG. 11, which will be described in detail later. If it is not a passive action definition, the process proceeds to step S33.

In step S33, it is determined whether or not there is an operation described for the step for which the activation notification has been received in the scenario. If the corresponding operation is not described, the process proceeds to step S34, a termination notification is sent to the scenario step management unit 32, and the process is terminated. When the corresponding operation is described, the process proceeds to step S35, and the data to be transmitted to the opposite computer is created according to the description of the scenario.

In step S36, the processing results of each other are passed to and from the standard TCP emulation unit 34, and the standard TCP emulation unit 34 temporarily sets the transition destination TCP state corresponding to the transmission data. Then, in step S37, it is determined whether or not the transition destination of the TCP state is specified by referring to the description of the scenario.

In step S37, it is determined that the transition destination TCP state is specified by the scenario when Ru, the process proceeds to step S38, the rewriting with the specified content transition destination TCP state, the process proceeds to step S39. If it is determined that the transition destination TCP state is not specified in the scenario, no particular processing is performed and the process proceeds to step S39.

In step S39, the content of the transmission data and the transition destination TCP state are confirmed. In step S40, the TCP state is changed to the state determined in step S39. Finally, in step S41, when the end notification is transmitted to the scenario step management unit 32, the packet is transmitted to the opposite computer to end the process.

FIG. 11 is a flowchart (No. 2) showing the step execution process by the step execution process unit 33. The processing when the action definition of the scenario is a passive action definition is shown. First, in step S51, it waits for the received data to be transmitted from the opposite computer. When the data is received, the process proceeds to step S52, and the received data is collated with the operation definition of the step for which the activation notification is received from the scenario step management unit 32.

In step S53, it is determined whether or not the received data is set with the information corresponding to the received data condition described in the operation definition. If it is determined that the information corresponding to the received data condition is not set in the received data, the process proceeds to step S54, a termination notification is sent to the scenario step management unit 32, and an abnormal operation is notified.

If it is determined in step S53 that the information corresponding to the received data condition is set in the received data, the process proceeds to step S55, and whether or not there is a description in the operation definition to save the received data. To judge.

If it is determined in step S55 that there is a request to save the received data, the process proceeds to step S56, the received data is saved in the save buffer 35, and the process proceeds to step S57. If it is determined in step S55 that there is no request to save the received data, no particular process is performed and the process proceeds to step S57. In step S57, it is determined whether or not there is a description in the operation definition to restore the received data.

If it is determined in step S57 that there is a request to restore the received data, the process proceeds to step S58, the corresponding data is read from the save buffer 35, the received data is overwritten, and the process proceeds to step S59. If it is determined in step S57 that there is no request to restore the received data, no particular process is performed and the process proceeds to step S59.

In step S59, the processing results of each other are passed to and from the standard TCP emulation unit 34, and the standard TCP emulation unit 34 temporarily sets the response data and the transition destination TCP state for the received data.

In step S60, it is determined whether or not the content of the response data to be transmitted to the opposite computer is described in the operation definition of the scenario. If the content of the response data is specified by the scenario, the process proceeds to step S61, the response packet is rewritten with the content specified in the scenario, and the process proceeds to step S62. If the content of the response data is not specified in the scenario, no particular processing is performed and the process proceeds to step S62.

In step S62, it is determined whether or not the transition destination TCP state is specified by the scenario, and if it is specified, the transition destination TCP state is rewritten to the contents specified in the scenario in step S63, and the process proceeds to step S64. move on. If the transition destination TCP state is not described in the scenario, no particular processing is performed and the process proceeds to step S64.

In step S64, the content of the response data and the transition destination TCP state are confirmed. In step S65, the TCP state is changed to the TCP state determined in step S64. Finally, in step S66, when the end notification is transmitted to the scenario step management unit 32, the packet is transmitted to the opposite computer to end the process.

By the way, the emulator 3 shown in FIG. 1 can be configured by using, for example, an information processing device (computer) as shown in FIG. The information processing device of FIG. 12 includes a CPU (central processing unit) 1001, a memory 1002, an input device 1003, an output device 1004, an external storage device 1005, a medium drive device 1006, and a network connection device 1007, which are connected to each other by a bus 1008. It is connected.

The memory 1002 includes, for example, a ROM (read only memory), a RAM (random access memory), and the like, and stores a program and data used for processing. CPU1001 performs necessary processing by executing a program using memory 1002.

The save buffer 35 in FIG. 1 corresponds to the memory 1002. Further, the reception processing unit 31, the scenario step management unit 32, the step execution processing unit 33, the standard TCP emulation unit 34, and the transmission processing unit 36 in FIG. 1 have functions realized by executing a program stored in the memory 1002. Corresponds to.

The input device 1003 is, for example, a keyboard, a pointing device, a touch panel, or the like, and is used for inputting instructions and information from a user. The output device 1004 is, for example, a display, a printer, a speaker, or the like, and is used for outputting inquiries to users, alarms, processing results, and the like.

The external storage device 1005 is, for example, a magnetic disk device, an optical disk device, a magneto-optical disk device, a tape device, or the like. The information processing device stores the above programs and data in the external storage device 1005, and loads them into the memory 1002 for use as needed.

The medium drive device 1006 drives the portable recording medium 1009 and accesses the recorded contents. The portable recording medium 1009 is an arbitrary computer-readable recording medium such as a memory card, a flexible disk, a CD-ROM (compact disk read only memory), an optical disk, or a magneto-optical disk. The user stores the above programs and data in the portable recording medium 1009, and loads them into the memory 1002 for use as needed.

The network connection device 1007 is connected to an arbitrary communication network such as a LAN (local area network) or the Internet, and performs data conversion associated with the communication. The information processing device receives the above programs and data from an external device via the network connection device 1007, and loads them into the memory 1002 for use.

FIG. 13 shows a computer-readable recording medium capable of supplying programs and data to the information processing apparatus of FIG. The programs and data stored in the portable recording medium 1009 and the database 1103 of the server 1101 are loaded into the memory 1002 of the information processing device 1102. The server 1101 generates a transport signal that carries the program and data, and transmits the transport signal to the information processing device 1102 via an arbitrary transmission medium on the network. CPU1001 executes the program using the data and performs necessary processing.

As described above, according to the emulator 3 according to the present embodiment, various operation sequences in TCP communication are performed by generating a transmission packet to the opposite computer according to the description of the input scenario and performing the transmission process. Can be realized. It is effective for conducting tests to verify the normality of TCP operation under various conditions in a network system such as a computer's TCP stack or a WAN acceleration device that converts TCP into a protocol.

Regarding the above embodiments, the following additional notes will be further disclosed. (Appendix 1) An emulator device that is connected to the device under test equipped with the communication protocol stack to be tested via a network. When a scenario describing a series of operations to be executed on the emulator device side is input in the sequence to be tested, a management means for determining the operation to be executed and giving a start notification by referring to the scenario, and An execution means for generating a packet to be read from the scenario and executed for receiving a start notification from the management means and transmitted to the test target device, and an execution means. An emulator device characterized by being equipped with. (Appendix 2) In the above scenario, for each operation, identification information for identifying the operation and destination operation identification information including identification information to be executed next to the operation are described in association with each other. The management means reads out the movement destination operation identification information associated with the operation at the timing when the scenario is input or the timing when the operation end notification is received from the execution means, and the movement destination operation identification information is used. Send the activation notification of the indicated operation to the execution means. The emulator device described in Appendix 1 characterized by the above. (Appendix 3) In the scenario, each operation is from either a passive operation that describes a response operation to a packet received from the test target device or an active operation that describes an operation that spontaneously transmits a packet from the emulator device. Naru, The passive operation and the active operation include a transition destination protocol state after the operation is executed in the emulator device. The execution means executes the operation for which the activation notification is received from the management means, and then transitions the protocol state to the transition destination protocol state of the operation. The emulator device described in Appendix 2 characterized by the above. (Appendix 4) The passive operation includes one or more operations, and a condition is defined for each operation to be determined based on the content of the packet received from the device under test. When the operation for which the activation notification is received from the management means is the passive operation, the execution means executes the operation for which the conditions are set corresponding to the contents of the packet received from the test target device. The emulator device described in Appendix 3 characterized by the above. (Appendix 5) The active action further includes information relating to the content of the packet to be transmitted. When the operation receiving the activation notification from the management means is the active operation, the execution means generates a transmission packet by referring to the information related to the content of the transmission packet described in the operation. The emulator device described in Appendix 3 characterized by the above. (Appendix 6) When instructed by the execution means, an emulation means that emulates the standard operation of the communication protocol and returns the result to the execution means. Further prepare When the executing means receives an instruction about an operation to be executed from the management means, the executing means refers to the description of the operation in the scenario, and when it is described that the scenario emulates the standard operation of the communication protocol, the executing means refers to the description of the operation. Instruct the emulation means to perform emulation. The emulator device described in Appendix 2 characterized by the above. (Appendix 7) A determination means for determining whether or not the packet should be executed by the execution means based on the content of the packet received from the test target device. The emulator device described in Appendix 1, which is further equipped with.

<figref num="1">It is a functional block diagram of the computer including the TCP emulator which concerns on embodiment.</figref><figref num="2">It is a flowchart which showed the whole processing.</figref><figref num="3">It is a figure which shows an example of a scenario.</figref><figref num="4">It is a figure explaining the test of the simultaneous connection establishment sequence.</figref><figref num="5">It is a figure explaining the sequence test method about the recovery process from an old duplicate sequence.</figref><figref num="6">It is a figure explaining the test method about the sequence of simultaneous closing.</figref><figref num="7">It is a figure explaining the test method about the recovery sequence from a half-open connection.</figref><figref num="8">It is a flowchart which showed the packet bypass processing.</figref><figref num="9">It is a flowchart which showed the scenario step management process.</figref><figref num="10">It is a flowchart (No. 1) showing the step execution process.</figref><figref num="11">It is a flowchart (No. 2) showing the step execution process.</figref><figref num="12">It is a block diagram of an information processing apparatus.</figref><figref num="13">It is a figure which shows the recording medium.</figref><figref num="14">It is a figure which shows the system configuration for carrying out the test of a protocol stack.</figref><figref num="15">It is an operation sequence diagram about simultaneous connection establishment.</figref>

Code description

1 computer 2 Operation system 3 TCP emulator 21 Packet bypass processing unit 22 Protocol stack 23 Bypass condition table 31 Reception processing unit 32 Scenario step management department 33 Step execution processing unit 34 Standard TCP emulation section 35 Evacuation buffer 36 Transmission processing unit