JP2017021662A - Relay server system and communication method using relay server - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a relay server system and its communication method that improve communication security and reduce a load on a relay server.SOLUTION: A relay server 40 has a function that stores a request task transmitted by a task request side (task request device 10) via the Internet 30 in an inside folder and designates a reception server from which the task request side receives. A task execution device (service provision side) 20 monitors the relay server 40 via the Internet 30 to see if there is a request task therein. If it confirms there is a request task, it executes the task and transmits the result to a reception server 50 to store it.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a relay server system and a communication method using a relay server, and in particular, a task requested from a task requesting device (client device) via the Internet is executed by a task execution device (service providing device), and an execution result is obtained. The present invention relates to a relay server system that transmits data to a task request device via the Internet and a communication method using the relay server.

  Conventionally, in response to a task request sent from the requesting side (client device) via the Internet, the requested task is executed by the task execution device (service providing device), and the execution result is transmitted to the requesting side via the Internet. There are two types of communication systems: peer-to-peer (P2P), where the requester and provider are directly connected via the Internet, and those where the both are indirectly connected via a relay server on the Internet. ing.

  Here, as a client device (task request device) on the task request side, a mobile portable terminal such as a smartphone, a personal computer, or a client server device is generally used. On the other hand, the task execution device (service providing device) may be a personal computer or various server devices (for example, any device having a function of executing a requested task and transmitting an execution result to the request side via the Internet). File servers, database servers, web servers, mail servers, etc.).

  However, in a system in which the requesting side 10 and the providing side 20 are directly connected via the Internet 30 as shown as a reference diagram in FIG. It is easy and there are many security problems.

  Therefore, as shown in FIG. 3, as a means of improving security vulnerability, the request side (plural client computers 11-1 to 11-n) and the providing side (server computer 12) established an interconnection. Instead of making a task request later, only the client computer (task requesting device) that sends the presence / absence of a task from the requesting side to the providing side in advance and confirms that the providing side has received this request directly with the providing side A client server system that establishes a connection has also been proposed (see Patent Document 1).

  According to this example, the task request side (client computer) and the task processing side (server computer) are configured to be interconnected only when a task request exists, thus avoiding connection with an unnecessary partner. And the connection time can be shortened. As a result, it can be said that the risk of receiving unnecessary attacks is reduced, and security is improved accordingly.

  However, although there are no unnecessary connections, there is a period in which the requester and the provider are directly connected, which is not sufficient as a safe security measure.

  Therefore, as shown in the reference diagram of FIG. 4, there is a technique for avoiding a direct connection between the requesting side 10 and the providing side 20 by interposing a relay server 40 on the network and using this relay server as a relay machine. Proposed. However, if access from client devices (requesting side) and task execution devices (providing side) trying to communicate with each other via the network 30 is concentrated on the relay server 40, a large server load or communication load is applied. is there.

In order to avoid this, a technique for distributing the load using a management server has been proposed. Here, the management server monitors the communication status between the requesting side (client) and the providing side so that the load is not concentrated only on a specific server on the network, and the server with a low load as the server to which the client should connect (Refer to Patent Document 2).
However, since a special server called a management server is required, there is a drawback that the system configuration becomes complicated. Further, the relay server that receives the designation from the management server must always transmit the request content from the request side to the providing side. Therefore, there is a drawback that the time and load for the transmission processing in the relay server cannot be avoided.

JP 2006-185194 A (paragraphs [0007], [0009] and FIG. 1) JP 2012-234236 A (paragraphs [0012] to [0016] and FIG. 1)

  As described above, in a system in which the requester and the provider communicate via the Internet, the server load and the communication load increase when attempting to improve security, and the system configuration becomes complicated when attempting to reduce this load. There is a drawback of doing. In addition, the relay server that has received the request inevitably undergoes processing for transmitting the request to the providing side, and thus a problem arises that a busy state is likely to occur even if there is a task request from another device.

  Furthermore, whether it is a direct connection or an indirect connection, the requester must continue to connect to the Internet until the requested result arrives or until a relay server to be accessed is designated. This causes a problem that its own processing efficiency is limited. In other words, even if the requester wants to reduce the time required to connect to the Internet as much as possible and execute its own processing efficiently, the requester must remain connected to the Internet until a response is received from the provider or management server. You will not be freed from the constraint of being unusable. This is a major factor that hinders the processing efficiency on the request side.

  The present invention improves the above-mentioned conventional drawbacks, and in a server system in which a requester and a provider use a relay server on the Internet for communication (information transfer), the security vulnerability is reduced without complicating the system configuration. It is an object of the present invention to provide an improved new relay server system and its communication method.

  Another object of the present invention is to provide a relay server system and a communication method thereof in which a relay server that accepts a request reduces the time for processing the request and reduces the concentration of server load. To do.

  Still another object of the present invention is to provide a relay server system that solves the restriction that the requesting side maintains the Internet connection until a response is returned from the providing side or the management server, and a communication method therefor. is there.

  In the first aspect of the present invention, a relay server connected to the Internet, a task requesting device connectable to the relay server via the Internet, and a task execution device that is connectable to the Internet and executes the requested task The relay server system has a function of storing a request content transmitted from a task requesting device via the Internet and a function of specifying a receiving server for the requesting device. The task execution device has a function to check whether there is a task request to itself by accessing the relay server via the Internet. When the request is confirmed, the requested task is executed and the result is specified by the relay server. Forward to the receiving server. The task requesting device is configured to receive a result from a receiving server designated by the relay server when the task is requested.

  In the second aspect of the present invention, the relay server has a file storage unit that stores the request contents transmitted from the requesting device in association with the receiving server information for receiving the result.

  In the third aspect of the present invention, the relay server starts a timer in response to accepting the task request sent from the requesting device, and the task request is automatically described when a predetermined time elapses. It has an automatic erasure unit that erases files.

  In the fourth aspect of the present invention, when the providing device confirms that there is a task request in the relay server, the providing device has a function of instructing the relay server to delete the request.

  In the fifth aspect of the present invention, the receiving server receives a task execution result from the providing side, and a timer that is started, and when the timer has not received from the requesting side even after a predetermined time has elapsed. It has a function of deleting an execution result file and displaying an error.

  In the sixth aspect of the present invention, when the request side accesses the receiving server and receives the result, it has a function of instructing the receiving server to delete the result in response to the request.

  In a seventh aspect of the present invention, a technique is disclosed in which a plurality of receiving servers are connected to the Internet, and the results are distributed and stored in the plurality of receiving servers. Here, the relay server has a function of designating a plurality of receiving servers for storing the results in a distributed manner and their storage order. The provider side distributes and saves the results according to this specification, and the requester accesses each server so as to receive the results distributed according to the specification in order.

  In an eighth aspect of the present invention, a communication method is disclosed in which a relay server is used as a message board, so that a providing side confirms a task request from the requesting side and the requested task is executed. Here, the client device (task requesting device) writes a command or parameter indicating the request contents to the file R, sends the file R to a relay server on the Internet using the IP address, and the relay specified by the IP address The server receives this file R and provides the task requesting device with the IP address of the receiving server in response, and the task execution device (providing side) accesses the relay server on the Internet using the IP address. Check whether file R exists, and if file R exists, execute the requested task, write the result to file A, and use a relay server that includes the step of receiving the file A and sending it to the IP address of the server Communication method was provided.

  In a ninth aspect of the present invention, a communication method including the step of distributing and storing task execution results in a plurality of receiving servers on the Internet is disclosed.

  In a tenth aspect of the present invention, there is disclosed a communication method including the steps of distributing a requested task using a plurality of task execution devices and transmitting the result to a receiving server.

In the eleventh aspect of the present invention, a plurality of relay servers are connected to the Internet, and the task requesting device sends the file R to a relay server designated at random from these.
When the processing is concentrated on the designated relay server, a busy signal is returned to notify the acceptance failure. As a result, the task requesting device repeats the step of sending the file R by designating another relay server, thereby searching for a relay server with less processing concentration and sending the file R. On the other hand, there is disclosed a communication method including a step in which the providing device sequentially accesses a plurality of relay servers to find a relay server that accepts the file R.

  A characteristic requirement in the relay server system and the communication method of the present invention is that the relay server that receives the request from the request side does not transmit the request to the providing side, but the providing side accesses the relay server to That is, the presence or absence is confirmed. That is, both the requesting side and the providing side only need to perform one-way access to the relay server, and it is not necessary for the relay server to relay the task request from the requesting side to the providing side.

  In other words, instead of using a relay server for relaying information so that information from the requesting side is sent to the providing side and information from the providing side is returned to the requesting side as in the past, the requesting side The use of the relay server as if it was a message board by confirming the request transmitted to the relay server is a point that differs greatly from the conventional usage of the relay server.

  There is a so-called electronic bulletin board that publishes the provided information on a web page and uses it as a place for exchanging information with those who are interested in it. Therefore, it should be noted that it is contrary to the security protection technology of the present invention that places importance on the secrecy of information. Therefore, the functions required for the server are also completely different.

  In this regard, the function of the relay server of the present invention will be described in more detail. First, when a relay server accepts a task request from the request side, it needs a function of passing the information of the receiving server to the request side as a response to the request acceptance. However, the relay server does not need a function for notifying the provider of the request. This is because it is assumed that the provider confirms the request itself. In other words, the relay server does not need to access the requesting side or the providing side by itself, and the requesting side and the providing side do not need to access the relay server in a procedure (for example, a predetermined time interval) arbitrarily determined. It is characterized by being configured to access.

According to the present invention configured as described above, the following effects can be obtained.
(1) Since the service (task) requester and the service (task execution result) provider are not connected to each other via the relay server and do not require connection to the other party, extremely confidential security is realized. it can. In addition, since the relay server itself only needs to function as a message board, there is no worry that a large processing load is applied, and it is not necessary to provide a special management server, so that the system configuration is not complicated.

  (2) Since the relay server only needs to store the requested task and the result receiving server in association with each other, it does not require complicated processing or management. Therefore, the processing load on the relay server is not increased, and the processing efficiency of the relay server is not hindered.

  (3) Further, by providing the relay server with a timer function, it accepts the requested task and starts the timer. If the confirmation is not made by the provider until the predetermined time has elapsed, the requested task is automatically It can be erased. As a result, since the request task is not stored for an unnecessarily long period of time, there is no fear that the request contents will be leaked even if the relay server receives an attack from the outside. In addition, the load on the relay server can be greatly reduced.

  (4) When the providing device confirms the task request to itself, it has a function to give the relay server an instruction to delete the request, so the confirmation is completed without waiting for the elapsed time set in the timer. Later, the request can be deleted promptly. For this reason, it is possible to further improve the confidentiality of information.

  (5) Even at the receiving server, the timer is started when the task execution result is received, and the contents are automatically deleted when a predetermined time elapses. Therefore, even if the receiving on the request side is delayed, information leaks. Risk can be significantly reduced. It is also possible to easily inform the requester of the fact of erasure by displaying an error display indicating a retry (retry) or the like upon automatic erasure. The requesting device that has not been able to access the receiving server within the predetermined time may confirm the error display and then request a retry (retry) from the providing side.

  (6) Since the requesting side has a function of instructing deletion when receiving the result from the receiving server, there is no fear that the result remains in the receiving server for a long time. Therefore, high security can be maintained even in the receiving server.

  (7) When multiple receiving servers are connected to the Internet, task concentration results are distributed and stored in these servers, so that load concentration occurs on specific receiving servers along with improving security. Can be avoided.

  (8) Claim 8 discloses a method for realizing high-security communication with a simple system configuration by using the function of the relay server as a message board function. In particular, since the task request device can transmit a request to the relay server with a very small file described by commands and parameters indicating the request contents, it does not occupy the storage area of the relay server and The task request can be easily stored in the relay server without increasing the communication connection time. Furthermore, since the providing device can confirm the presence / absence of a task request by making an inquiry to the relay server, the processing efficiency of the relay server is not reduced.

  (9) In addition to the effect of (8) above, task execution results can be distributed and arranged on a plurality of servers, so that higher security can be obtained. Further, since the communication time with one receiving server can be shortened by the amount of distribution, the concentration of communication load can be reduced.

  (10) If a plurality of task execution devices (providing devices) are used, task processing can be distributed. Conventionally, in order to process tasks in a distributed manner, hardware for managing load distribution called a balancer and software for controlling the load have been required. However, according to an aspect of the present invention, tasks in charge of distributed processing are required. By simply specifying the execution device, each task execution device acquires the task assigned to itself from the relay server and executes it, so there is no need to use a complicated and expensive balancer.

  (11) According to the aspect of claim 11, if the file R is sent to any one of a plurality of relay servers and the response is busy without specifying the relay server to send the task request, another relay A relay server with sufficient processing capacity can be used as a message board by sending file R to the server. As a result, there is no need to wait until the relay server becomes empty, and not only the security can be improved, but also the responsiveness with the relay server can be improved.

1 shows a system function block diagram in a first embodiment of the present invention. FIG. It is a reference figure showing a conventional communication system roughly. 1 is a system block diagram illustrating a conventional method proposed for improving security vulnerabilities in a communication system. It is a reference figure showing roughly the conventional communication system using a relay server. FIG. 2 shows an internal functional block diagram of a relay server in the first embodiment of the present invention. FIG. 2 shows an internal functional block diagram of a receiving server in the first embodiment of the present invention. It is a flowchart which shows the task procedure in the 1st Embodiment of this invention, and the process sequence until it receives this request | requirement. 6 is a flowchart showing a processing procedure until a task request is confirmed and executed in the first embodiment of the present invention. It is a flowchart which shows the process sequence after a task execution result in the 1st Embodiment of this invention is sent to a receiving server until a request | requirement apparatus receives this. The system block diagram for distributing and storing a task execution result in the some receiving server in the 2nd aspect of this invention is shown. FIG. 9 shows a system diagram for distributing and executing a requested task using a plurality of task execution devices (providing devices) in a third embodiment of the present invention. The block diagram of the relay server system which performs the process for searching for the relay server which received the request | requirement task while searching for the relay server with few loads among several relay servers in the 4th embodiment of this invention Indicates. 1 shows a main functional block diagram of a task requesting device in a first embodiment of the present invention. FIG. The main functional block diagram of the task execution apparatus in the 1st embodiment of this invention is shown.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. However, it should be noted that this description does not limit the invention described in the claims. Further, each block shown in the figure is an example of functions necessary for carrying out the invention, and it is understood by those skilled in the art that each block can be configured by hardware, software, or a complex thereof. If there is, it is easy to understand. In addition, the solid or broken arrow lines shown in the figure are described with the focus on the direction and route of information necessary for explanation, and the start and end points of each arrow line are directly connected by wiring. Note that it is not intended to be.

  FIG. 1 is a system functional block diagram relating to Embodiment 1 of the relay server system of the present invention. A task requesting device 10 that operates as a requesting side, a task execution device 20 that operates as a providing side, a relay server 40 that receives a requesting task, and a receiving server 50 that receives a task execution result are devices that can be connected to the Internet 30. is there. The task requesting device (client device) 10 is a mobile terminal device such as a smartphone, a tablet terminal, a notebook PC, or a stationary information processing device such as a desktop PC, and has an Internet connection function. That's fine. Further, the task execution device (service providing device) 20 has a function of processing data using a computer, such as a search function, a classification function, an arithmetic function, an organization function, and an analysis function necessary for executing the requested task. Any information device may be used. The relay server 40 and the receiving server 50 are information processing devices that can cope with network connection and simultaneous access from a plurality of clients. In particular, the relay server 40 and the receiving server 50 are specified by device designation information such as an IP address sent via the network. A folder function for storing a file sent via a network, and a function capable of disclosing a stored folder to a browsing requester (in this embodiment, a task requesting device and a task execution device). If it exists, it is applicable to the present invention.

  Although the details of the processing procedure of each device will be described later, here it is desirable to explain the interrelationship between the four devices shown in the figure. The relationship between the task requesting device 10 and the task execution device 20 is such that the task requesting device 10 issues a request for a task and the task execution device 20 executes the requested task. On the other hand, the relationship between the task requesting device 10 and the relay server 40 is that the task requesting device 10 sends a file describing the requested task to the relay server 40 (see (1)), and the relay server 40 is sent. The file is stored in its own folder, and the task requesting device 10 is instructed to the receiving server 50 for receiving the result executed by the task execution device 20 (see (2)). Furthermore, in the relationship between the relay server 40 and the task execution device 20, the relay server 40 is used to check whether the task execution device 20 has a task to be processed by itself (see (3)). It is. The relationship between the task requesting device 10, the task execution device 20, and the receiving server 50 is that the execution result (see (4)) sent from the task execution device 20 is received and stored in the server 50, and the task requesting device 10 stores the execution result. Obtained from the receiving server (see (5)).

  In the relay server system shown in FIG. 1 as Embodiment 1, the processing procedure from when the task requesting device 10 requests a task to obtaining the result proceeds as follows.

  First, the task requesting apparatus 10 activates an application program and creates the contents of a task desired to be requested using a command or parameter by a file creation unit (10-1 in FIG. 13). For example, when requesting a list of men who live in Tokyo and wear glasses, a file R “Search, man, Tokyo, glasses” is created. This file R is transmitted via the Internet 30 to the relay server 40 having the IP address designated by the task request unit (10-2 in FIG. 13) of the task requesting apparatus 10.

  FIG. 5 shows a main functional block diagram of the relay server 40. The relay server 40 includes a task request receiving unit 40-1, a receiving server designating unit 40-2, a file storage unit 40-3, a timer 40-4, And a file erasure unit 40-5.

  A file sent to the relay server 40 specified by the IP address via the Internet 30 is received by the task request receiving unit 40-1. The relay server 40 that has received the request performs the following three processes.

(1) As a proof of acceptance of the file R in which the requested task is described, the receiving server designating unit 40-2 receives the IP address and folder of the server (receiving server 50 in FIG. 1) from which the task requesting device 10 should receive the result. The name and the file name Z are sent as a series of related information to the task requesting apparatus 10 via the Internet 30.
(2) The IP address, folder name, and file name Z described in (1) are added to the file R in which the requested task received earlier is written and stored in the file storage unit 40-3.
(3) When saving is completed, the timer 40-4 is started, and when a preset time (for example, 20 seconds) elapses, it is saved in the file storage unit 40-3 using the file erasing unit 40-5. Force file R to be deleted automatically.

  On the other hand, the task execution device 20 has a monitoring operation (task confirmation) unit 20-3 shown in FIG. 14, and the relay server 40 is periodically (for example, 100 mm) using an IP address in a period other than the process execution. Monitor every second). That is, the task confirmation unit 20-3 accesses the relay server at a time interval shorter than the period until the relay server 40 automatically deletes the file in the file storage unit 40-3 (20 seconds in the above example). Then, repeat the process to check whether the file exists. When the task confirmation unit 20-3 confirms the existence of the file R, the task confirmation unit 20-3 acquires the file R and instructs the relay server to delete the file R. As a result, when the task execution device 20 finds a file in which the requested task is described, the file is deleted from the relay server 40 immediately.

  As is clear from the above description, the period in which the file R in which the request task to be managed as confidential information is stored in the relay server may be a very short time of 20 seconds at the maximum in this embodiment. Therefore, it becomes possible to maintain very high security without requiring special management.

  Next, the task execution device 20 executes the requested task in accordance with the file R read from the relay server 40 in the task execution unit (20-1 in FIG. 14). According to the above example, a list of men living in Tokyo and wearing glasses is created and written to file A. The task execution device 20 transmits the created file A from the result transmission unit 20-2 of FIG. 14 to the receiving server 50 specified by the IP address described in the file R acquired from the relay server 40 via the Internet. The file A is written in the designated folder of the receiving server 50.

  FIG. 6 shows functional blocks necessary for the present invention in the receiving server 50. The receiving server 50 includes an execution result storage folder 50-1, a timer 50-2, and a file erasing unit 50-3 for storing the file A sent from the task execution device 20.

  The file A sent from the task execution device 20 is written and saved in the designated file Z in the designated execution result storage folder 50-1. The receiving server 50 starts the timer 50-2 when the file A is written into the file Z, and forcibly uses the file erasing unit 50-3 when the predetermined time elapses (for example, 20 seconds). Erase.

  On the other hand, the task requesting device 10 acquires the IP address, folder name, and file name Z of the receiving server from the relay server 40, and then periodically (for example, 100 mm) in the monitoring operation unit 10-5 shown in FIG. Every second), the receiving server 50 is accessed to monitor whether the file Z exists. When the task execution apparatus 10 confirms that the file Z exists in the receiving server 50, the task execution apparatus 10 acquires the file Z via the Internet 30 and instructs the receiving server 50 to delete the file Z. When the task requesting apparatus 10 obtains the target file Z from the receiving server 50, the search result for the requested task is written therein, and the search request application is terminated.

  With reference to the schematic diagrams of the flowcharts shown in FIGS. 7 to 9, the detailed processing flow of the present embodiment, particularly the timing at which the task requesting device 10 and the task execution device 20 monitor the relay server 40 and the receiving server 50 will be described. . The English letters a to p exemplify steps necessary for processing of the task requesting device 10, the task execution device 20, the relay server 40, and the receiving server 50.

  As shown in FIG. 7, the task requesting device (client device) 10 starts up the application program and creates the content of the requested task as a file A by the file creation unit 10-1, which is created by the task requesting unit 10-2. To the relay server 40 via the Internet 30 (step a).

  If the relay server 40 is in a processable state, it accepts the file R and sends the IP address of the receiving server and the folder name and file name where the result is stored to the task requesting device 10 (step b). The task requesting device 10 that has acquired the information about the receiving server stores it in the receiving server storage unit 10-3 and disconnects the Internet connection (step c). The relay server 40 adds the received server information to the file R received from the task requesting apparatus 10 (step d), and starts a timer (step e).

  When the requested task (file R) is sent to the relay server 40, a busy signal is returned to the task requesting device 10 when the relay server 40 cannot accept it. The task requesting device 10 that has received the busy signal may wait until the relay server 40 becomes empty, or may send the request file R to another relay server.

  The task requesting device 10 that has completed the reception of the requested task accesses the receiving server via the Internet 30 and performs a monitoring operation (mo) for monitoring whether or not the execution result of the requested task is stored. Use 5 to run regularly. Of course, this operation can also be performed using the idle time of the task requesting apparatus 10. On the other hand, the task execution device 20 (service providing side) periodically monitors a monitoring operation (mo) for confirming whether or not there is a task request for itself with the task confirmation unit 20-3 in FIG. This operation may be performed when the task execution device 20 is idle.

  The relay server 40 that has accepted the requested task (file R) starts a timer and starts measuring the retention period of the file R (step f in FIG. 8).

  When the task execution device 20 performing the monitoring operation (mo) confirms that there is a task request to the relay server 40 (confirmation of the file R), the file R stored in the relay server 40 is immediately deleted. (Step g) and the task requested by the task execution unit 20-1 is executed (step h).

  When the relay server 40 is instructed by the task execution device 20 to delete the file R, it immediately deletes the file R from the storage folder (step i). If there is no access from the task execution device 20 even after a predetermined time has elapsed since the timer activation, the relay server deletes the file R itself (step j). If an error is displayed after erasing the file R, the task execution device 20 can recognize that the confirmation has not been made in time, and can perform a retry or the like. . When the file deletion according to the instruction from the task requesting device 20 or the forced file deletion with the lapse of a predetermined time is completed, the processing of the relay server 40 ends.

  In FIG. 9, the task execution device 20 that has completed the processing of the requested task creates an execution result as a file A and instructs it to be stored in the file Z of the receiving server 50, and the result transmission unit 20-2. (Step k). The task execution device 20 that has completed the transmission of the file A ends the processing at this point.

  The receiving server 50 stores the file A sent from the task execution device 20 in the folder of the file Z as instructed (step l). When the saving is completed, the timer is started and time measurement is started (step m).

  On the other hand, as a result of the monitoring operation (mo), the task requesting device 10 that has confirmed that there is a result file Z designated for the receiving server 50 obtains the file Z from the receiving server 50, the file is sent to the receiving server 50. Instruct to delete Z (step n). Receiving server 50 receiving the deletion instruction immediately deletes file Z from the folder (step o). The task requesting device that acquired the target file Z ends the processing at this point and closes the application.

  If the receiving server 50 starts the timer and the access for receiving is not made from the task requesting apparatus 10 even after a predetermined time has elapsed, the receiving server 50 forcibly deletes the file Z by itself ( Step p). When either file deletion in accordance with an instruction from the task requesting device 10 or automatic file deletion with the elapse of a predetermined time is executed, the processing of the receiving server 50 ends at that point. When the file Z is forcibly deleted, the task requesting apparatus 10 can know that the reception has failed by displaying an error.

  FIG. 10 is a functional system block diagram of a second embodiment related to the relay server system of the present invention. Here, an example in which a plurality of receiving servers 50-a to 50-n are arranged on the Internet 30 will be described. . Since requesting a task, executing a requested task, and receiving an execution result may be basically the same as those in the first embodiment, detailed description thereof is omitted here.

  In the second embodiment, the results can be distributed and stored in a plurality of receiving servers 50. For this purpose, the relay server 40 may add each IP address, folder name, file name, and storage order of the receiving server that stores the task execution result in a distributed manner to the file R received from the task requesting device 10. . The task execution device 20 distributes and transmits the results to the receiving servers described in the file R, and the task requesting device 10 can sequentially access the receiving servers specified in the file R and receive the results.

  By distributing and storing task execution results as in the second embodiment, security can be further improved and the processing load of each receiving server can be distributed. Therefore, even if the capacity size of the file A of the task execution result is increased, it is possible to avoid that a capacity load is applied only to a specific receiving server.

  FIG. 11 is a functional system block diagram showing a third embodiment in which the present invention is applied to a system that performs distributed processing using a plurality of task execution devices 20-a to 20-n. As means for instructing distributed processing, the task requesting device 10 may create a file R that describes each IP address and processing content of the task execution device that requests processing, or the relay server 40 should perform distributed processing. The IP address of the task execution device and the task in charge may be added to the file R received from the task requesting device 10. On the other hand, each task execution device can confirm the task requested by itself by executing the monitoring operation described above.

  According to the third embodiment, the security can be improved and the processing load of the task execution device can be distributed. In particular, load distribution can be easily performed without using a special management device or management software such as a balancer to distribute the processing load.

  FIG. 12 is a functional system block diagram in which the present invention is applied to a system in which a plurality of relay servers 40-a to 40-n are connected to the Internet 30. The task requesting device 10 sends the file R describing the requested task to any one of the plurality of relay servers. If the relay server to which the file R is sent is busy, an unnecessary waiting time can be prevented from being given to the task requesting device 10 by returning a busy signal. The task requesting device 10 that has received the busy signal may send the file R to another relay server. By doing so, a request task can be sent to a relay server with few queues, so the responsiveness between the task requesting device and the relay server can be improved. Note that the task execution device 20 can find the file R by the above-described monitoring operation without requiring any special processing.

  In any of the above-described embodiments, the relay server and the receiving server are described as separate servers. However, it is easy for those skilled in the art that the relay server that receives the task request may be the receiving server. It is understandable.

  As is apparent from the above description, the present invention can be used in any communication system in which a task requesting device (requesting side) and a task execution device (providing side) can communicate with a relay server via the Internet.

DESCRIPTION OF SYMBOLS 10 ... Task request (client) apparatus 10-1 ... File preparation part 10-2 ... Task request part 10-3 ... Receiving server memory | storage part 10-4 ... Result receiving part 10-5 ... Monitoring operation unit 20 ... Task execution (service provision) device 20-1 ... Task execution unit 20-2 ... Result transmission unit 20-3 ... Task confirmation unit 30 ... Internet 40 ... Relay server 40-1 ... Task request receiving unit 40-2 ... Receiving server designating unit 40-3 ... File storage unit 40-4 ... Timer 40-5 ... File erasing unit 50 ... Receiving server 50-1 ... Execution result storage folder 50-2 ... Timer 50-3 ... File erasing unit
a ~ p ・ ・ ・ each processing step

Claims (11)

In a relay server system including a task requesting device connectable to the Internet, a task execution device for executing a requested task, and a relay server connected to the Internet,
The task request device includes a task request unit that requests a task from the relay server via the Internet, and a reception server storage unit that stores a reception server sent from the relay server,
The relay server includes a task receiving unit that receives a requested task sent from a task requesting device via the Internet, and a receiving server designating unit that specifies a receiving server on the Internet that should receive a task execution result for the task requesting device. And
The task execution device includes a task confirmation unit that accesses the relay server via the Internet and confirms whether there is a requested task, a task execution unit that executes the requested task when the request is confirmed, and an execution A relay server system, comprising: a result transmission unit configured to transmit a result of the completed task to the receiving server via the Internet.   The relay server system according to claim 1, wherein the relay server includes a storage unit that stores the requested task transmitted from the task requesting device and the receiving server that receives a task execution result in association with each other.   The relay server system according to claim 2, wherein the relay server has a timer that is activated in response to acceptance of the request task, and the timer deletes the request task in the storage unit after a predetermined time has elapsed.   The relay server system according to claim 1, wherein the task execution device issues an instruction to delete the requested task when it is confirmed that the requested task exists in the relay server.   The receiving server has a timer that starts in response to reception of a task execution result sent from the task execution device, and automatically deletes the received execution result when the timer passes a predetermined time. Item 8. A relay server system according to item 1.   The relay server system according to claim 1, wherein the task requesting device instructs the receiving server to delete the result after receiving the result from the receiving server.   The relay according to claim 1, wherein a plurality of receiving servers including the relay server are connected to the Internet, and task execution results in the task execution device are distributed and stored in the plurality of receiving servers. Server system. Using a relay server including a relay server connected to the Internet, a task requesting device that transmits a requested task to the relay server via the Internet, and a task execution device that is connectable to the Internet and executes the requested task A communication method,
A first step of writing the contents of the task requested by the task requesting device to the file R;
A second step of sending the file R to the relay server via the Internet;
A third step of transmitting the IP address of the receiving server that receives the task execution result as the receipt confirmation of the file R to the task requesting device when the relay server that has received the file R;
A fourth step in which the task execution device accesses the relay server via the Internet and confirms whether the requested task exists in the relay server;
The task execution device that has confirmed the requested task executes a requested task, and a fifth step;
A sixth step in which the task execution device transmits a task execution result to the receiving server via the Internet;
A seventh step in which the task requesting device accesses the receiving server via the Internet and receives the task execution result;
A communication method using a relay server having   A plurality of receiving servers are connected to the Internet, and the relay server has a distributed IP address instructing to store task execution results in a plurality of receiving servers and information instructing the storage order. The communication method according to claim 8, comprising a step to be transmitted to the task requesting device and the task execution device.   9. The communication method according to claim 8, comprising a plurality of task execution devices connectable to the Internet, and the file R is written with contents of request tasks assigned to the plurality of task execution devices. Each of the task execution devices confirms a requested task to be executed by accessing the relay server independently. A relay server including a plurality of relay servers connected to the Internet, a task requesting device that transmits a requested task to the relay server via the Internet, and a task execution device that is connectable to the Internet and executes a requested task A communication method used,
A first step of writing the contents of the task requested by the task requesting device to the file R;
A second step of transmitting the file R to the relay server randomly designated among the plurality of relay servers via the Internet;
A third step of sending a busy signal to the task requesting device when processing is concentrated on the designated relay server;
The task requesting device that has received the busy signal transmits a file R to another relay server, a fourth step;
A fifth step of receiving the task request by the other relay server that has received the file R, and transmitting the IP address of the receiving server that receives the task execution result as the reception confirmation of the file R to the task request device;
A sixth step in which the task execution device sequentially accesses the plurality of relay servers via the Internet to check whether the requested task exists in the relay server; and
A seventh step of receiving the file R from the relay server that has confirmed that the requested task exists, and executing the requested task;
An eighth step in which the task execution device transmits a task execution result to the receiving server via the Internet;
A ninth step in which the task requesting device accesses the receiving server via the Internet to obtain the task execution result;
A communication method using a relay server having