JPH1153273A - Infinite length data communication method of request responding type - Google Patents

Abstract

PROBLEM TO BE SOLVED: To execute the communication of finite length data and the communication of infinite length data by the same communication manner by designating the type of data to be a stream type and allowing distributed processing information to repeat the transmitting/receiving of finite length data according to this designation, so as to communicate infinite length data between applications. SOLUTION: An application on a client side 1 executes operation calling to a server object 5 to the distributed processing environment 6 of its own node and enters a block state. Then without waiting for return from the object 5, the application 1 is released from the block state. At the time of being released from the block state, a stream-type variable is generated on the client side. The application on the client side 1 obtains the attribute of this variable (buffer information within the variable). Next, infinite length data is read by accessing to the stream-type variable and when the reading of all the pieces of data is not finished by once access, access is repeated to the variable.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a method for communicating infinite length data between applications in a distributed system.

In recent years, client / server systems, etc.
Many distributed system technologies 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. In the peer-to-peer type, on the other hand, both applications simply exchange information under mutually equal rights and conditions.

Typical implementations of the request-response type include a remote procedure call (RPC) technique and a distributed object technique 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 set of operations, and when a client invokes an operation on an object and responds to the client from the object, the interface between the client and the server via a parameter is defined. To send and receive data.

[0004] One of the features of these technologies is that it is not necessary to be aware of the network when programming, and the client can communicate data by a method that calls a procedure or operation of a server.

However, communication between conventional 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.

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 whose data size 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 infinite-length data communication 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, the communication of finite-length data is a request-response type, so that the 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 in a consistent manner called object-oriented. On the other hand, since communication of infinite-length data is not a request-response type, the entity that provides or processes infinite-length data at the time of implementation 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 the server must be aware of the network interface, such as the aforementioned socket, 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 in consideration of the network interface. This adds to the burden of application development. In particular, this burden becomes extremely large in the development of a multimedia system that mainly handles data that can be classified into infinite length data such as moving images or audio.

[0009]

SUMMARY OF THE INVENTION It is an object of the present invention to provide communication of infinite length data between applications.
Resolve the above drawbacks, provide the same communication method for both finite-length data and infinite-length data, enable consistent application of system development methods, and be aware of network interfaces when implementing code for each application. Instead, to enable communication of infinite length data.

[0010]

In order to achieve the above object, a request response type infinite length data communication method according to the present invention provides a method in which one application makes a request between applications and the other application responds to the request. Is specified as a stream type, and the distributed processing environment repeatedly sends and receives finite-length data according to this specification.
It is characterized by communicating infinite length data between applications.

According to the request-response-type infinite-length data communication method of the present invention, the distributed processing environment does not require the use of the network management interface for communicating the infinite-length data with both the client application and the server object. Also, there is no need to be conscious. In addition, access means for infinite length data is provided as an operation parameter, and there is no need to define operations such as starting or stopping communication to enable access to infinite length data.

[0012]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 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.

Reference numeral 2 denotes a client-side data processing unit.
In response to a request to invoke an operation from the client application 1, the server object 5
The object reference, the operation call request, and the data as the parameters of the operation 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.

Reference numeral 3 denotes a data communication unit. This determines the position of the server object 5 from the object reference received from the client-side data processing unit 2,
The server-side data processing unit 4 of the server object 5
, An object reference, an operation invocation request, and data as parameters. 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.

Reference numeral 4 denotes a server-side data processing unit. When receiving the object reference, the operation call request, and the data as the parameter from the data communication unit 3, it passes the call request and the data as the 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.

Reference numeral 5 denotes a server object. this is,
Provides services related to 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 as a distributed processing environment 6 to an application developer.

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 is the client application 1
Returns the response of the called operation. In either or both of the steps (2) and (4), infinite data is exchanged between the client application 1 and the server object 5.

FIG. 2 is a diagram showing the entire configuration of the distributed processing environment. The application distributed to each computer 10a, 10b passes through the distributed processing environment 6 on each computer,
Enables inter-application communication without being aware of distribution. In this embodiment, the distributed processing environment 6 defines a data type for infinite length data, and the application uses that type.

In the following description, the infinite-length data type is called 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 the distributed processing environment and provided to the application. The application handles the infinite length data as a parameter of the operation call in the operation, and processes the infinite length data by accessing the parameter.

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 ID
L Compiler).

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 the stream-type variable as an operation call parameter visible from both parties appears to be a single entity, the variable entity actually exists in both the client and the server.

The individual data flowing through 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.

Next, a mounting method in the stream type will be described. 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 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 the 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.

In the following description, it is assumed that the buffer is mounted cyclically, but in the present invention, the buffer is not necessarily cyclic. Further, 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.

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.

Hereinafter, the client application 1
Will be described with reference to FIGS. 3 to 6 when an operation of the server object 5 is called and infinite length data flows from the server object 5 to the client application 1. FIG. 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 a client code, and FIG. 6 is a description example of an implementation code of a server.

First, the client-side application 1
Will be described. The client-side application 1 obtains a reference to 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) (this is an IOR (Inter-Operable) defined by CORBA.
Object Reference). At this stage, the stream-type variable has not yet been generated in the client-side application 1.

Next, the client-side application 1
Performs an operation call 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 returns from the server object 5 (end notification of processing accompanying the operation invocation)
Is released from the block state without waiting for ((7) in FIG. 3)
). When released from the blocking 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), (107) in FIG. 5).

The client-side application 1 accesses a stream type variable and reads infinite data. If reading of all data is not completed by one access, the variable is repeatedly accessed ((10) in FIG. 3, FIG. 5).
(109) to (116)). 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 interruption.

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 at the time of generating the variables include buffer information (number of cycles, data size per cycle) and quality of service information (QoS).

After the generation of the variables, the server object 5 accesses the stream type variables 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 and FIG. 6).
(208)-(216)). The end of the writing may be voluntarily terminated by judging the content of the data to be written by the server object 5 ((212), (214) in FIG. 6) or may be interrupted and interrupted. .

Finally, the operation of the client and server distributed processing environments 6a and 6b will be described. The client-side distributed processing environment 6a is the client-side application 1
(1 in Fig. 3)
An operation call message is sent to the distributed processing environment 6b on the server side ((2) in FIG. 3). The content includes a reference to the server object 5, network location information (IP address and port number) on the client side, an operation type, parameter processing and a 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.

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. Next, the server side distributed processing environment 6b
Sends a message requesting connection to a new channel to the client-side distributed processing environment 6a ((5) in FIG. 3).
). The contents include socket information (network address, port number) newly generated by the server.

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 client application 1 is unblocked (FIG. 3
(7)). 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).
).

When the server-side distributed processing environment 6b receives the writing from the server object 5 to the stream-type variable (the buffer therein) ((9) in FIG. 3), the data in the buffer in the variable is converted into the infinite-length data. Write to the socket for communication. 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. Is passed to the client application 1.

In this embodiment, a socket is used as an interface of a communication channel for infinite-length data, but of course, another type may be used. What is necessary is that the distributed processing environment on both the server side and the client side mutually transmit and receive network location information and make a connection request. 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.

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.

Code descriptions using C ++ as a programming language are as shown in FIGS. 4B, 5 and 6. B in FIG. 4 is a stream type class declaration. In this method, the 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. Of these, (3) and (4) are used to initialize stream type variables. In particular, in (4), information such as the buffer size is set at the same time. (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 that index. (8) is an operation to write data in the reverse of (7).

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. FIG.
(104) and (112) relate to processing of data read from a stream type variable. Also, (204), (2) in FIG.
Item 10) concerns the processing of data to be written to stream type variables.

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 flow is from the client application to the server object. It is.

From the above description of the embodiment, it is clear that the distributed processing environment does not require the use of the network management interface to communicate infinite-length data for both the client application and the server object, and does not need to be aware of it. I understand. 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.

Also, from the description of the embodiment, means for accessing infinite-length data is provided as an operation parameter, and the definition of operations such as starting or stopping communication for enabling access to infinite-length data. Is not required. Therefore, according to this embodiment, there is an advantage that flexibility of application development is not impaired.

[0043]

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 communication manner of request-response type. As an example of the mode of implementation, in the RPC or 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 for infinite length data as well as finite length data can be represented as an object. It can be done in a consistent manner 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. Secondly, there is an advantage that communication of infinite length data can be developed without being conscious of the network management interface, and the 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 server implementation code.

[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)

[Claims] An application issues a request between applications, and the other application specifies a data type as a stream type in response to the request, and the distributed processing environment repeatedly sends and receives finite-length data according to the specification. A request-response-type infinite-length data communication method characterized by communicating infinite-length data between applications.