JP3569114B2 - Request response type infinite data communication method - Google Patents

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a method for communicating infinite length data between applications in a distributed system.
[0002]
In recent years, many distributed system technologies such as a client / server system have been developed. According to Miki, Tsuchiya, and Lee, "Three-tier client / server system construction technique" (Soft Research Center, 1996), communication methods between distributed applications are roughly classified into two types: request-response type and peer-to-peer. There is a type. In the request-response type, one application makes a request and the other responds to it. On the other hand, in the peer-to-peer type, both applications simply exchange information under mutually equal rights and conditions.
[0003]
Typical implementations of the request response type include a remote procedure call (RPC) technology and a distributed object technology using a common object request broker architecture (CORBA). In RPC, for example, when a server application defines a procedure, and when the client calls the procedure to the server application and when the server responds to the client, data is exchanged between the client and the server via parameters. Do. Similarly, in CORBA, an object as a server defines an interface that is a collection of operations, and when a client invokes an operation on an object and responds to a client from an object, the interface between the client and the server via a parameter is defined. To exchange data.
[0004]
One of the features of these technologies is that the client does not need to be aware of the network when performing programming, and can perform data communication by a method in which a client calls a procedure or an operation of a server.
[0005]
However, conventional communication between request-response-type applications including RPC and CORBA targets only finite-length data as data to be exchanged, and cannot exchange infinite-length data. That is, conventionally, only peer-to-peer communication exists for exchanging infinite length data between the client and the server. For example, in a UNIX environment, it is common for both a client and a server to generate sockets, and both to access their own sockets to exchange infinite length data.
[0006]
Here, “finite length data” refers to data that can specify the entire length of data when data communication is started. On the other hand, "infinite length data" refers to data for which the size of data cannot be specified when data communication is started. An example of the infinite length data is video and audio data of a video conference system. Since the service end time of this system is generally indefinite, it is not possible to specify the entire length of the data at the time of starting the communication of the video and audio data. Another example of infinite length data is a video on demand service. Since the length of the movie is known in advance, it can be treated as finite length data, but depending on the implementation of the application, it can be developed as infinite length data.
[0007]
Using the peer-to-peer type instead of the request-response type for communication of infinite length data between applications has the following disadvantages. The first drawback is that it is difficult to develop a consistent system because the communication manners of finite-length data and infinite-length data are different. For example, in a distributed object environment such as CORBA, since communication of finite length data is a request response type, an entity that provides or processes finite length data at the time of code implementation can be represented as an object. Therefore, it is possible to develop the analysis, design and implementation of the system by a consistent method called object orientation. On the other hand, since communication of infinite length data is not a request-response type, a subject that provides or processes infinite length data at the time of mounting cannot be represented as an object. Therefore, system development cannot be performed in a consistent manner. For this reason, consistency cannot be maintained, the advantage of the system development method is lost, and the efficiency and quality of system development are reduced.
[0008]
A second disadvantage is that both the client and server must be aware of the network interface, such as the sockets described above, when implementing the code. In other words, in spite of the fact that technologies such as RPC and CORBA can be used, if infinite length data is to be communicated, programming must be performed with the network interface in mind. This adds to the burden of application development. In particular, this burden becomes extremely large in the development of multimedia systems that mainly handle data that can be classified into infinite length data such as moving images or audio.
[0009]
[Problems to be solved by the invention]
SUMMARY OF THE INVENTION An object of the present invention is to solve the above-mentioned drawbacks with respect to communication of infinite length data between applications, to provide the same communication manner for both finite length data and infinite length data, and to make it possible to apply a consistent system development method. Another object of the present invention is to enable communication of infinite-length data without being aware of a network interface when implementing the code of each application.
[0010]
[Means for Solving the Problems]
In order to achieve the above object, a request-response-type infinite-length data communication method of the present invention is a request-response-type infinite-length data communication method in which one application initiates a request and the other application responds to the request in a distributed processing environment. In a distributed processing system, in order to communicate infinite-length data between applications, a stream type is defined in a distributed processing environment as a data type for infinite-length data, and one application provides a stream type provided by the other application. When calling an operation having a parameter including a parameter, a variable of a trim type corresponding to the parameter is generated on each of the two application sides, and the distributed processing environment continuously repeats communication of infinite-length data between applications through the variable. Executes as finite-length data transfer And wherein the door.
[0011]
According to such a request-response type infinite length data communication method of the present invention, the distributed processing environment does not require the use of a network management interface for communicating infinite length data with both the client application and the server object. There is no need to be conscious. In addition, access means to infinite length data is provided as an operation parameter, and there is no need to define an operation such as starting or stopping communication for enabling access to infinite length data.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
Next, embodiments of the present invention will be described in detail with reference to the drawings. FIG. 1 is a functional classification of the overall configuration of a distributed processing environment and an application. 1 is a client application. It invokes the operation of the object as a server to receive services on infinite data.
[0013]
Reference numeral 2 denotes a client-side data processing unit. In response to this, in response to an operation call request from the client application 1, the object reference of the server object 5, the operation call request, and data as operation parameters are passed to the data communication unit 3. This also passes the operation call response and data as parameters received from the data communication unit 3 to the client application 1.
[0014]
3 is a data communication unit. In this method, the position of the server object 5 is determined from the object reference received from the client-side data processing unit 2, and the object reference, the operation call request, and the data as parameters are passed to the server-side data processing unit 4 of the server object 5. In addition, it passes the operation call response received from the server-side data processing unit 4 and data as parameters of the operation to the client-side data processing unit 2.
[0015]
Reference numeral 4 denotes a server-side data processing unit. When receiving an object reference, an operation call request, and data as a parameter from the data communication unit 3, it passes the call request and data as a parameter to the server object 5. When receiving an operation call response and data as its parameters from the server object 5, it passes them to the data communication unit 3.
[0016]
5 is a server object. It provides services for infinite length data. It also performs the operation for which the call request was received.
Among the above, the client-side data processing unit 2, the data communication unit 3, and the server-side data processing unit 4 are provided to the application developer as the distributed processing environment 6.
[0017]
A simple scenario viewed from the client application 1 and the server object 5 is as follows. (1) The client application 1 obtains an object reference of the server object 5 to be called by using a name service or a trader service. (2) The client application 1 calls an operation of the server object 5 using the object reference. (3) The server object 5 executes the called operation. (4) The server object 5 returns a response of the called operation to the client application 1. In either or both of (2) and (4), infinite length data is exchanged between the client application 1 and the server object 5.
[0018]
FIG. 2 is a diagram showing the entire configuration of the distributed processing environment. The applications distributed to the respective computers 10a and 10b enable communication between the applications through the distributed processing environment 6 on each computer without being aware of the distribution. In this embodiment, the distributed processing environment 6 defines a data type for infinite length data, and the application uses that type.
[0019]
In the following description, the infinite length data type is referred to as a stream type. This stream type is an abstract data type assuming that an application directly processes infinite-length data. The stream type is defined by a distributed processing environment and provided to an application. The application treats the infinite length data as a parameter of the operation call in the operation, and processes the infinite length data by accessing the parameter.
[0020]
The distributed processing environment provides a data type in an interface definition language (IDL) and a data type in a programming language (for example, C ++) as a stream type. In addition, mapping is performed from the IDL description of the stream variable to the programming language (the mapping is performed by the IDL compiler).
[0021]
Since the stream type is provided as the data type of the parameter of the operation call, the generation of the stream type variable by the client-side application 1 and the server object 5 is performed in the same manner as the conventional data type of CORBA. That is, either of them gives an opportunity to generate a stream type variable. Although there is only one stream type variable entity as an operation call parameter visible to both parties, the variable entity actually exists in both the client and the server.
[0022]
The individual data flowing in the stream type is a simple bit string unlike the integer type and the floating point type. Therefore, unlike those types of data, marshalling and unmarshalling are not performed before and after communication.
[0023]
Next, a mounting method in the stream type will be described. The stream type variable (instance) has the following information for each variable. It is roughly divided into a user data section and a management section. A buffer is a component of the user data section. This is a temporary storage of data from once receiving writing of data from the application to writing to the network interface, and from reading data from the network interface to reading to the application. Each time the application accesses a stream type variable once, it reads and writes one buffer of finite length data, and processes the infinite length data by repeating the reading and writing.
[0024]
In the following description, it is assumed that the buffer is mounted cyclically, but in the present invention, the buffer is not necessarily cyclic. Also, as components of the management unit, there are buffer information (number of buffer cycles, data size per cycle, head address) and network information (network protocol stack, service quality, self and partner network location information). . The buffer information is information on the aforementioned buffer, and the network information is information on a communication channel for infinite-length data between the client and the server.
[0025]
In order to prevent data copying between the application and the network interface, it is also possible to adopt a configuration in which no buffer is provided in the stream type.
[0026]
The operation sequence when the client application 1 calls an operation of the server object 5 and infinite data flows from the server object 5 to the client application 1 will be described below with reference to FIGS. Here, it is assumed that the distributed processing environment 6 uses a socket, which is one of the network interfaces provided by an operating system such as UNIX. FIG. 3 is a diagram showing an example of an operation sequence, FIG. 4 is a code description example for defining a class “stream”, FIG. 5 is a description example of client code, and FIG. 6 is a description example of implementation code of a server.
[0027]
First, the operation of the client-side application 1 will be described. The client-side application 1 obtains the reference of the server object 5 in the manner of the conventional CORBA ((102) in FIG. 5). This reference includes server-side network location information (IP address and port number) and the like (this conforms to the IOR (Inter-Operable Object Reference) defined by CORBA). At this stage, the stream-type variable has not been generated in the client-side application 1 yet.
[0028]
Next, the client-side application 1 calls an operation to the server object 5 with respect to the distributed processing environment 6 of the own node, and enters a block state ((1) in FIG. 3, (104) in FIG. 5). The client-side application 1 is released from the block state without waiting for a return from the server object 5 (a notification of the end of the process accompanying the operation call) ((7) in FIG. 3). When released from the block state, a stream type variable is also created on the client side. The client-side application 1 obtains the attribute of this variable (buffer information in the variable) ((106) and (107) in FIG. 5).
[0029]
The client-side application 1 accesses a stream type variable and reads infinite length data. If reading of all data is not completed by one access, the variable is repeatedly accessed ((10) in FIG. 3, (109) to (116) in FIG. 5). The end of reading may be voluntarily terminated by the client-side application 1 judging the content of the data ((113), (115) in FIG. 5) or may be interrupted by receiving an interrupt.
[0030]
Next, the operation of the server object 5 will be described. Upon receiving the operation call ((3) in FIG. 3), the server object 5 generates stream-type variables ((4) and (8) in FIG. 3 and (6) in FIG. 4). The parameters for generating the variables include buffer information (number of cycles, data size per cycle) and quality of service information (QoS).
[0031]
After the variable generation, the server object 5 accesses the stream type variable and writes the infinite length data. If writing of all data is not completed by one access, the variable is repeatedly accessed ((9) in FIG. 3, (208) to (216) in FIG. 6). The termination of the writing may be voluntarily terminated by judging the contents of the data to be written by the server object 5 ((212), (214) in FIG. 6), or may be interrupted by receiving an interrupt. .
[0032]
Finally, operations of the client side and server side distributed processing environments 6a and 6b will be described. Upon receiving an operation call from the client-side application 1 ((1) in FIG. 3), the client-side distributed processing environment 6a sends an operation call message to the server-side distributed processing environment 6b ((2) in FIG. 3). . The contents include the reference of the server object 5, the network location information (IP address and port number) on the client side, the type of operation, the parameter processing and the value. Next, the server-side distributed processing environment 6b starts the server and calls an operation on the corresponding object ((3) in FIG. 3). The sequence up to this point is the same as the conventional CORBA operation call.
[0033]
Next, when the server object 5 generates a stream type variable instance ((3) in FIG. 3), the server side distributed processing environment 6b generates a new communication channel for communication of infinite length data. Therefore, a new socket is created, an available port number is obtained, and the new socket is set. Subsequently, the distributed processing environment 6b on the server side sends a message for requesting connection to a new channel to the distributed processing environment 6a on the client side ((5) in FIG. 3). The contents include socket information (network address, port number) newly generated by the server.
[0034]
The client side distributed processing environment 6a generates a new socket on the server side. Next, a free port number is set in the socket. Then, a completion notification message is sent to the server side ((6) in FIG. 3). Further, the block of the client application 1 is released ((7) in FIG. 3). At this time, a stream-type variable instance on the client side is also generated. Upon receiving the notification of the connection completion from the client side, the distributed processing environment 6b on the server side ends the processing related to the generation of the variable ((8) in FIG. 3).
[0035]
When the server-side distributed processing environment 6b receives writing from the server object 5 to the stream-type variable (the buffer therein) ((9) in FIG. 3), the server-side distributed processing environment 6b transfers the buffer data in the variable to the infinite length data communication Write to the socket. On the other hand, when the client-side distributed processing environment 6a receives a read request from a stream-type variable from the client application 1 ((10) in FIG. 3), the client-side distributed processing environment 6a reads data from a communication socket for infinite-length data, and reads the data. To the client application 1.
[0036]
In this embodiment, a socket is used as an interface of a communication channel for infinite length data. What is necessary is that the distributed processing environments on both the server side and the client side mutually transmit and receive network location information and make connection requests. Also, note that the exchange and processing between the distributed processing environments are invisible to the server object and the client application, and the server only generates stream type variables (programmatically declares variables). Should.
[0037]
Next, an example of code description by an application developer will be described. In the IDL description, as shown in FIG. 4A, the signature “stream” means a stream type. The application developer declares a stream type parameter using this signature. "Out" indicates that infinite length data flows from the server side to the client side as in the conventional data type.
[0038]
Code description examples using C ++ as a programming language are as shown in FIG. 4B, FIG. 5 and FIG. B in FIG. 4 is a stream type class declaration. In this method, an IDL compiler receives the above IDL description and outputs a stream type class declaration as a header file. (3) to (8) are operations for the stream type. Among them, (3) and (4) are used to initialize stream type variables. Particularly in (4), information such as the buffer size is set simultaneously. (5) and (6) are operations for obtaining information such as the buffer size. (7) is an operation of designating the index of the buffer cycle and reading the data in the buffer of the index. (8) is an operation for writing data in the reverse of (7).
[0039]
FIG. 5 shows the implementation code of the client-side application, and FIG. 6 shows the implementation code of the server operation. These codes are as described in the above description of the operation sequence. Note that (104) and (112) in FIG. 5 relate to processing of data read from stream type variables. Further, (204) and (210) in FIG. 6 relate to the processing of data to be written in stream type variables.
[0040]
In the above description of the embodiment, an example in which the flow of infinite data flows from the server object to the client application has been described. On the contrary, it is needless to say that the same applies to the case where the data flows from the client application to the server object.
[0041]
From the above description of the embodiment, it is understood that the distributed processing environment does not need to use or be aware of the network management interface for communicating infinite length data for both the client application and the server object. Therefore, there is an advantage that the handling of infinite length data is simplified for the application developer, and the application development burden can be reduced.
[0042]
Also, from the description of the embodiment, access means to infinite length data is provided as an operation parameter, and it is necessary to define operations such as communication start or communication stop to enable access to infinite length data. It turns out that it does not. Therefore, according to this embodiment, there is an advantage that flexibility of application development is not impaired.
[0043]
【The invention's effect】
As described above, the present invention has the following effects. That is, first, communication of finite-length data and communication of infinite-length data can be performed by the same request-response communication method. As an example of the mode of implementation, in the RPC or the distributed processing environment, both the communication of the finite length data and the communication of the infinite length data can be realized by calling the procedure of the server or the operation of the server object. This indicates that consistent system development is possible even for systems that handle both types of data. In particular, in a distributed object environment such as CORBA, a subject that provides a service not only for finite-length data but also for infinite-length data can be represented as an object. It can be done in a consistent way called orientation. Further, there is an advantage that general-purpose object services such as a trader and a name service can be used as they are for an object providing an infinite-length data service. Second, there is an advantage that communication of infinite length data can be developed without being conscious of the network management interface, and handling of infinite length data can be simplified to reduce the burden of application development.
[Brief description of the drawings]
FIG. 1 is a diagram showing functional classifications of the overall configuration of a distributed processing environment and an application.
FIG. 2 is a diagram illustrating an entire configuration of a distributed processing environment.
FIG. 3 is a diagram showing an example of an operation sequence.
FIG. 4 is a diagram illustrating a code description example that defines a class “stream”.
FIG. 5 is a diagram illustrating a description example of a client code.
FIG. 6 is a diagram illustrating a description example of a mounting code of a server.
[Explanation of symbols]
REFERENCE SIGNS LIST 1 client application 2 client-side data processing unit 3 data communication unit 4 server-side data processing unit 5 server object 6 distributed processing environment 6a client-side distributed processing environment 6b server-side distributed processing environment 10 computer

Claims (1)

In a distributed processing system in which a request is made by one application and the other application responds to the request in a distributed processing environment, the data for infinite length data is used to communicate infinite length data between applications. A stream type is defined in the distributed processing environment as a type, and when one application calls an operation having a parameter including a stream type provided by the other application, a trim type variable corresponding to the parameter is generated on each of the two applications. A request response type infinite length data communication method, characterized in that the distributed processing environment executes communication of infinite length data between applications as transmission and reception of a plurality of finite length data that is continuously repeated through the variable.

Images