Relay apparatus and communication system
9 claims: 2 independent, 7 dependent
- 1第1通信装置と通信可能な中継装置であって、 第1通信装置から送信されたデータを他の中継装置に中継する中継手段と、 サーバ装置に前記他の中継装置の状態を問い合わせ、前記他の中継装置が接続を受け入れる状態にある場合には、前記他の中継装置に対して接続要求を行い、前記他の中継装置との間で動的に中継用コネクションを確立して保持する保持手段と、 中継用コネクションが確立されたときに、 前記中継装置が属する LANに接続された通信装置の装置名のリスト を前記他の中継装置に送信し、前記他の中継装置が属するLANに接続された通信装置の装置名のリストを前記他の中継装置から受信することで、装置名のリストを 交換する手段と、 第2通信装置は前記他の中継装置が属するLANに接続されており、交換したリストにおいて前記他の中継装置と対応づけられている前記 第2通信装置の装置名を宛先として指定したデータ送信要求を前記第1通信装置から受信する手段と、を備え 、 前記第1通信装置から送信されたデータを前記他の中継装置に中継することで、さらに当該データが前記第2通信装置に中継されることを特徴とする中継装置。
- 2請求項1に記載の中継装置において、 前記保持手段は、 複数の中継装置との間で中継用コネクションを接続して保持する手段、を含み、 前記中継手段は、 複数の中継用コネクションを利用して複数の中継装置に対してデータを中継する手段、を含むことを特徴とする中継装置。
- 3請求項2に記載の中継装置において、 前記保持手段は、 複数の中継装置との間で保持している中継用コネクションを個別に切断する手段、を含むことを特徴とする中継装置。
- 4請求項1に記載の中継装置において、 前記保持手段は、 通信装置からの指定によって他の中継装置との間で中継用コネクションを接続して保持する手段、 を含むことを特徴とする中継装置。
- 5請求項1に記載の中継装置において、 前記保持手段は、 通信装置からの指定によって他の中継装置との間で中継用コネクションを接続して保持する手段、 を含み、 通信装置から特定の中継装置に対する中継用コネクションの接続指定を受けたとき、既に、前記特定の中継装置との間で中継用コネクションが保持されている場合には、既に形成されている中継用コネクションを共用することを特徴とする中継装置。
- 6端末間のデータを中継する通信システムであって、 第1通信装置と通信可能な第1中継装置と、 サーバ装置と、 第2通信装置と通信可能な第2中継装置と、を備え、 前記第1中継装置は、 サーバ装置に前記第2中継装置の状態を問い合わせ、前記第2中継装置が接続を受け入れる状態にある場合には、前記第2中継装置に対して接続要求を行い、前記第2中継装置との間で動的に中継用コネクションを確立して保持する保持手段と、 中継用コネクションが確立されたときに、 前記第1中継装置が属する LANに接続された通信装置の装置名のリスト を前記第2中継装置に送信し、前記第2中継装置が属するLANに接続された通信装置の装置名のリストを前記第2中継装置から受信することで、装置名のリストを 交換する手段と、 前記第2通信装置は前記第2中継装置が属するLANに接続されており、交換したリストにおいて前記第2中継装置と対応づけられている前記 第2通信装置の装置名を宛先として指定したデータ送信要求を前記第1通信装置から受信する手段と、を備え 、 前記第1中継装置が前記第1通信装置から送信されたデータを前記第2中継装置に中継送信することで、前記第2中継装置がさらにデータを前記第2通信装置に中継送信することを特徴とする通信システム。
- 7請求項6に記載の通信システムにおいて、 前記第1通信装置と前記第2通信装置は、それぞれ異なるプライベートネットワークの中に配置されており、外部のネットワークからは前記第1通信装置および前記第2通信装置に対してTCPコネクションの接続要求が行なえないネットワーク構成となっていることを特徴とする通信システム。
- 8請求項6に記載の通信システムにおいて、 前記保持手段は、 通信装置からの指定によって他の中継装置との間で中継用コネクションを接続して保持する手段、 を含むことを特徴とする通信システム。
- 9請求項6に記載の通信システムにおいて、 前記保持手段は、 通信装置からの指定によって他の中継装置との間で中継用コネクションを接続して保持する手段、 を含み、 通信装置からの要求に対して既に該当する中継装置間で中継用コネクションが形成されている場合は、他の通信装置もそのコネクションを共用することを特徴とする通信システム。
Independent claims9
81 paragraphs, as filed
The present invention relates to a technique for relaying data transmitted and received between communication devices.
By using technologies such as VPN (Virtual Private Network) and tunneling, it is possible to relay data transmitted from terminals located in a private network to terminals in other private networks via the Internet. is there. For example, by connecting the LAN of the head office and the LAN of the branch office with a VPN, it is possible to relay the data between the terminals connected to the LAN via the Internet.
Patent Document 1 below also discloses a technique for relaying data between local systems connected via the Internet. This technology accesses a relay server on the Internet from each terminal located in the local system, establishes a TCP connection, and uses the TCP connection to send and receive data between the local systems.
<patcit num="1"><text>Japanese Patent Application Laid-Open No. 2002-217943</text></patcit>
<p> By using VPN and tunneling technologies, it is possible to send and receive data between LANs connected via the Internet. However, these technologies are systems built with fixed settings. In other words, the connection between LANs is fixedly set in the relay device installed between each LAN and the Internet. So, for example, if you want to maintain a VPN constantly, such as a company headquarters and branch offices, there is no problem, but it is not possible to handle cases where you want to try to connect to dynamically different private networks. ..</p><p> Therefore, in view of the above problems, an object of the present invention is to provide a system capable of dynamically setting data relay between networks connected via the Internet.</p>
<p> In order to solve the above problems, the invention according to claim 1 is a relay device capable of communicating with the first communication device, which is a relay means for relaying data transmitted from the first communication device to another relay device. The server device is inquired about the status of the other relay device, and when the other relay device is in a state of accepting a connection, a connection request is made to the other relay device and the other relay device is connected to the other relay device. When the relay connection is established, the holding means that dynamically establishes and holds the relay connection is established.<u style="single">The relay device belongs to</u>List of device names of communication devices connected to the LAN<u style="single">Is transmitted to the other relay device, and a list of device names of communication devices connected to the LAN to which the other relay device belongs is received from the other relay device to obtain a list of device names.</u>Means of exchange and<u style="single">The second communication device is connected to the LAN to which the other relay device belongs, and is associated with the other relay device in the exchanged list.</u>A means for receiving a data transmission request specified as a destination of the device name of the second communication device from the first communication device is provided.<u style="single">,Previous</u>The data transmitted from the first communication device is relayed to the other relay device, so that the data is further relayed to the second communication device.</p><p> The invention according to claim 2 includes, in the relay device according to claim 1, the holding means for connecting and holding a relay connection with a plurality of relay devices. It is characterized by including means for relaying data to a plurality of relay devices using a plurality of relay connections.</p><p> The invention according to claim 3 is characterized in that, in the relay device according to claim 2, the holding means individually disconnects the relay connection held between the relay devices. And.<u style="single"> The invention according to claim 4 includes, in the relay device according to claim 1, the holding means for connecting and holding a relay connection with another relay device by designation from the communication device. It is characterized by that.</u><u style="single"> The invention according to claim 5 includes, in the relay device according to claim 1, the holding means for connecting and holding a relay connection with another relay device by designation from the communication device. , When a connection designation of a relay connection to a specific relay device is received from the communication device, if a relay connection is already held with the specific relay device, the relay connection already formed is formed. It is characterized by sharing a connection.</u></p><p> The invention according to claim 6 is a communication system that relays data between terminals, and is a first relay device capable of communicating with a first communication device, a server device, and a second relay capable of communicating with a second communication device. The first relay device inquires of the server device about the status of the second relay device, and when the second relay device is in a state of accepting a connection, the first relay device is inquired to the second relay device. When a connection request is made and a holding means for dynamically establishing and holding a relay connection with the second relay device and a relay connection are established,<u style="single">The first relay device belongs to</u>List of device names of communication devices connected to the LAN<u style="single">Is transmitted to the second relay device, and a list of device names of communication devices connected to the LAN to which the second relay device belongs is received from the second relay device to obtain a list of device names.</u>Means of exchange and<u style="single">The second communication device is connected to the LAN to which the second relay device belongs, and is associated with the second relay device in the exchanged list.</u>A means for receiving a data transmission request specified as a destination of the device name of the second communication device from the first communication device is provided.<u style="single">,Previous</u>The feature is that the first relay device relays and transmits the data transmitted from the first communication device to the second relay device, so that the second relay device further relays and transmits the data to the second communication device. And.</p><p> Claim<u style="single">7</u>The described invention is claimed.<u style="single">6</u>In the communication system described in the above, the first communication device and the second communication device are arranged in different private networks, and the external network refers to the first communication device and the second communication device. It is characterized by having a network configuration in which connection requests for TCP connections cannot be made.<u style="single">The invention according to claim 8 includes, in the communication system according to claim 6, the holding means for connecting and holding a relay connection with another relay device by designation from the communication device. It is characterized by that.</u><u style="single"> The invention according to claim 9 includes, in the communication system according to claim 6, the holding means for connecting and holding a relay connection with another relay device by designation from a communication device. When a relay connection has already been formed between the relay devices corresponding to the request from the communication device, the other communication devices also share the connection.</u></p>
<p> The relay device of the present invention inquires of the server device about the status of another relay device, makes a connection request when the other relay device is in a state of accepting a connection, and relays to and from the other relay device. Establish and hold a connection for. Therefore, the communication device capable of communicating with this relay device can perform communication with the communication device capable of communicating with another relay device via a public network.</p><p> Further, the relay device of the present invention can connect and hold a relay connection with a plurality of relay devices. Therefore, when the communication devices to be communicated belong to different networks, it is possible to individually generate a plurality of connections.</p><p> Further, the relay device of the present invention can individually disconnect the relay connection held between the plurality of relay devices. Therefore, it is possible to maintain only the connections that need to communicate, and the resources can be effectively used.</p>
{First embodiment} Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a configuration diagram of a communication system according to the first embodiment. In this communication system, two LANs 10 and 20 are connected via WAN30. LANs 10 and 20 are, for example, company LANs, and WAN30 is a public network such as the Internet. In other words, two different private LANs 10 and 20 are connected via a public network such as the Internet.
As shown in the figure, two communication devices 11 and 12 and a relay device 15 are connected to the LAN 10. And LAN10 is connected to WAN30 via gateway 16. Two communication devices 21, 22 and a relay device 25 are connected to the LAN 20. The LAN 20 is connected to the WAN 30 via the gateway 26.
Communication devices 11 and 12 are terminals such as personal computers and have a network function. Specifically, TCP / IP is implemented, and it is possible to communicate with the relay device 15 and other computers connected to LAN10 using TCP / IP. Similarly, the communication devices 21 and 22 are also equipped with TCP / IP, and can communicate with the relay device 25 and other computers connected to the LAN 20 using TCP / IP. In addition, communication using TCP / IP is also possible for relay devices 15, 25 and gateways 16, 26.
The server device 35 is connected to WAN30. WAN30 is a public network such as the Internet as described above. Therefore, terminals connected to LAN10,20 and WAN30 can establish a TCP connection by specifying the global IP address of the server device 35.
On the other hand, the communication devices 11,12,21,22 and the relay devices 15,25 connected to the LANs 10 and 20 are assigned private IP addresses. The gateways 16 and 26 form a firewall so that a connection can be made by designating an internal terminal directly from an external network. Therefore, terminals connected to WAN30 are restricted from making TCP connection connection requests to relay devices 15 and 25. In the present embodiment, since the server device 35 functions as a SIP server (SIP proxy server, registration server) as described later, it is possible for the server device 35 to communicate with the relay devices 15 and 25 by designating a specific port. Gateways 16 and 26 are set as shown above.
Table 1 is a table showing a registration example of the relay device database 351 managed by the server device 35. In this example, three relay devices A to C are registered. The relay devices A to C are, for example, device names attached to the relay device 15 and the relay device 25. The URL, IP address, and login status flag are set for each of the relay devices A to C.
<tables num="1"><img file="JP4492575B2_D0001.tif" /></tables>
The IP address of each relay device registered in the relay device database 351 is not the IP address in the private network of each relay device, but is translated by the gateway using functions such as NAT (Network Address Translation) and IP masquerade. Global IP address. For example, the relay device 15 is assigned a private address in the LAN 10, but when accessing the server device 35, the IP address is converted into a global IP address in the gateway 16.
Each of the relay devices A to C connects to the server device 35 and logs in to the server device 35. Information indicating whether each of the relay devices A to C is currently logged in to the server device 35 or is logged out is set in the "status" field of the relay device database 351. When each relay device is logged in, the server device 35 can determine that it is ready to establish a TCP connection with each of the other relay devices. In other words, the state in which the relay device is logged in to the server device 35 indicates that the relay device is in a state in which the connection request for the TCP connection sent from the other terminal can be accepted.
The flow of communication processing in the communication system having the above configuration will be described with reference to FIGS. 2 to 4. FIG. 2 is a diagram showing the overall processing flow of the communication system including the relay devices 15 and 25 and the server device 35. In the following description, the communication between the relay devices 15 and 25 and the server device 35 will be described by using SIP (Session Initiation Protocol) as an example, but other protocols may be used. ..
Each of the relay devices 15 and 25 sends a SIP "REGISTER request message" to the server device 35 at the time of initialization or periodically, and notifies the server device 35 of the location information (IP address, port number, etc.) of the relay device. are doing. The server device 35 manages the relay device database 351 in Table 1 based on this location information. The server device 35 can communicate with each relay device across the gateway based on this location information. In FIG. 2, in the initial state, the relay device 15 and the relay device 25 are logged in to the server device 35. First, the relay device 25 notifies the server device 35 of the logout status information (step S101), and the server device 35 responds to this (S102). The server device 35 executes the logout process of the relay device 25, and updates the "status" field of the relay device 25 to logout in the relay device database 351.
In this state, when the relay device 15 requests the server device 35 to notify the status information (S103), the server device 35 responds (S104), and then notifies that the relay device 25 is in the logout state. (S105). The relay device 15 responds to this notification (S106).
Next, the relay device 25 notifies the server device 35 of the login status information (step S107), and the server device 35 responds to this (step S108). The server device 35 executes the login process of the relay device 25, and updates the "status" field of the relay device database 351 to login. Further, the server device 35 notifies the relay device 15 that the relay device 25 has been logged in (S109). The relay device 15 responds to this notification (S110).
When the relay device 15 receives the notification that the relay device 25 is in the login state, the relay device 15 then transmits a connection request to the relay device 25 to the server device 35 (S111). As illustrated in the figure, this connection request is a SIP "INVITE request message", and TCP connection information is included in the body part following the blank line. In the example shown in the figure, the IP address (200.1.1.1) of the relay device 15 (source), the TCP port number (6109), and the like are included. The server device 35 relays this connection request to the relay device 25 (S112). In response to this request, the relay device 25 sends a response to the server device 35 to allow the connection (S113). This response is a SIP "200 OK" as illustrated in the figure. It is a "response message", and the TCP connection information is included in the body part following the blank line. In the example shown in the figure, the IP address (200.2.2.2) of the relay device 25 (source), the TCP port number (7109), and the like are included. The server device 35 relays this response to the relay device 15 (S114). In this way, the relay device 15 and the relay device 25 use the SIP INVITE request and the OK response to exchange TCP connection information and negotiate to establish a TCP connection. In response to this response, the relay device 15 sends a TCP connection request to the relay device 25 (S115). As a result, a TCP connection is established between the relay device 15 and the relay device 25.
The above processing is executed by, for example, the network administrator of LAN10 or LAN20. In other words, if the network administrator prepares to dynamically execute the connection with other LANs, he / she logs in the relay device in the network to the server device 35 as shown in step S107. is there. This prepares you to receive TCP connection requests from other relay devices. Then, when the network administrator wants to connect to another LAN, he / she accesses the server device 35 to acquire the status of the other party's relay device, and the other party's relay device becomes the logged-in state. When it knows that it is, it sends a connection request to the server device 35.
That is, in the present invention, the relay device 15 establishes a TCP connection (media session) for relay by transmitting a SIP INVITE request via the server device 35. That is, since the relay path as a media session is generated by using the call control protocol, the communication path for relay can be dynamically established.
When a TCP connection is established between the relay device 15 and the relay device 25 in this way, the relay device 15 and the relay device 25 hold the TCP connection. Then, when the relay device 15 receives the data to be transmitted from the communication devices 11, 12, etc. to the communication devices 21, 22, etc., the relay device 15 relays this data to the relay device 25. The relay device 25 further relays the relayed data to the communication devices 21, 22 and the like (S116). The data transmitted from the communication devices 21, 22 and the like is also relayed to the communication devices 11, 21 and the like via the relay device 25 and the relay device 15 (S117).
In order to communicate between LAN 10 and LAN 20 via such WAN 30, each relay device 15 and 25 manages a list of device names of communication devices connected to their respective LANs. Then, when a TCP connection is established between the relay device 15 and the relay device 25, this list is exchanged. Then, when the communication device connected to the LAN 10 and the communication device connected to the LAN 20 communicate with each other, the device name of the relay device of the destination LAN and the device name of the communication device of the destination should be specified together. do it. In other words, since a unique device name is given to the relay device that uses this communication system (registered in the relay device database 351), the device name of the relay device and the device name of the communication device are specified together. By doing so, the communication device of the transmission destination can be uniquely identified. For example, a name such as communication device name @ relay device name may be used. In addition, each relay device is specified by the communication device name @ relay device name because the correspondence between the communication device name and the IP address is known for the communication device connected to the LAN to which the own device is connected. It is possible to relay data to the communication device.
When the transmission / reception of data between the communication devices is completed and the connection between the relay device 15 and the relay device 25 is no longer necessary, the network administrator disconnects the connection. First, the relay device 15 transmits a disconnection request for the relay device 25 to the server device 35 (S118). The server device 35 relays this request to the relay device 25 (S119). The response from the relay device 25 is transmitted to the server device 35 (S120) and relayed to the relay device 15 (S121).
FIG. 3 is a flowchart focusing on the processing of the relay device 15 in the processing described with reference to FIG. First, the relay device 15 transmits a relay connection start request to the server device 35 (step S201). The relay device 25 of the relay destination is specified in this start request. When the response from the server device 35 reveals that the relay device 25 at the relay destination is logged out (NO in S202), it waits until a login notification is received (S203). When the login notification is received, the process proceeds to step S204.
When it is found in step S202 that the relay device 25 of the relay destination is logged in, TCP connection information is generated (S204) and a connection request is transmitted (S205). Then, it waits for a response from the relay device 25 (S206), and when it receives the response, it analyzes the TCP connection information during the response (S207). That is, the port number information and the like included in the response transmitted from the relay device 25 are acquired. Then, a TCP connection is made to the relay device 25 (S208).
When the communication device 11 or the like transmits relay data (YES in S209) while the TCP connection is established and held, the data is relayed and transmitted to the communication device 21 or the like (S210). When the relay data for the communication device 11 or the like is received (YES in S211), the data is relayed and transmitted to the communication device 11 or the like of the relay destination (S212). When a disconnection request is received from the relay device 25 (YES in S213), a response is transmitted (S214), and the TCP connection is disconnected (S215).
On the other hand, when the disconnection request is made by the network administrator of LAN10 (S216), the disconnection request is sent to the relay device 25 (S217), and if a response is received (YES in S218), TCP Disconnect the connection (S219).
FIG. 4 is a flowchart focusing on the processing of the relay device 25 in the processing described with reference to FIG. First, the LAN20 network administrator decides whether to prepare a connection with another LAN. When preparing to connect to another LAN, perform an operation to enable the relay function for the relay device 25. When the relay function is enabled (YES in step S301), a login command is sent to the server device 35 (S302). Then, the response is received from the server device 35 (S303), and the process of enabling the relay function is completed.
In this way, the relay device 15 dynamically establishes a TCP connection to the relay device 25 if the relay device 25 at the relay destination is in the logged-in state, that is, if the relay device 25 is in the state of accepting the connection. Data can be sent and received via WAN30 such as the Internet. For example, when traffic is constantly generated stably, such as at the head office and branch offices of a certain company, it is sufficient to use a VPN that has been used conventionally and connect LANs in a fixed manner. On the other hand, when it is desired to connect to a different network via WAN30 for data communication at an arbitrary timing, the communication system of the present embodiment may be used.
Further, according to the communication system of the present embodiment, even if the connection environment (IP address or port number) of the relay device of the other party is changed, the relay device first negotiates (S111 to S114). It is possible to reliably establish a connection for data relay.
Further, the relay devices 15 and 25 of the present embodiment can establish a TCP connection with a plurality of relay devices. For example, as shown in FIG. 5, the relay device 15 can establish a TCP connection individually with the three relay devices 25, 45, 55. The method of establishing a TCP connection with the relay devices 45 and 55 is the same as the processing performed on the relay devices 25. Then, each of the relay devices 15, 25, etc. establishes a TCP connection with the plurality of relay devices and relays the data to the plurality of relay devices. In the example of FIG. 5, the relay device 15 relays the data transmitted from one communication device to the relay device 45, and relays the data transmitted from another communication device to the relay device 55.
The method of disconnecting the TCP connection with each of the relay devices 45 and 55 is the same as the process performed on the relay device 25. That is, it is possible to establish a TCP connection individually with a plurality of relay devices 25, 45, 55 and disconnect the TCP connection individually.
In the past, when multiple LANs were connected in a VPN or the like, the multiple LANs were connected as one VPN. On the other hand, the communication system of the present embodiment is useless because it can be individually connected only to the relay device to be communicated with and can be disconnected from the relay device that no longer needs to communicate. An efficient communication system can be constructed without consuming resources.
{Second embodiment} Next, a second embodiment of the present invention will be described. In the first embodiment, the relay devices are dynamically connected according to the instruction of the network administrator. In the second embodiment, the connection between the relay devices is made by the designation from the communication device. Specifically, in the first embodiment, the network administrator performs an operation of connecting and disconnecting the relay devices assuming the state of communication generated between the communication devices. On the other hand, in the second embodiment, connection and disconnection control between relay devices is performed more dynamically in response to communication processing generated from the communication device. In the following description, the same description as in the first embodiment will be omitted.
FIG. 6 is a configuration diagram of the communication system according to the second embodiment. Although LAN40 is added in FIG. 6 in addition to the system configuration of FIG. 1, the basic system configuration is the same as that of the first embodiment. As for LAN40, the communication device 41 and the relay device 45 are also connected, and the LAN40 is connected to the WAN30 via the gateway 46.
The relay devices 15, 25 and 45 are provided with relay connection databases 151, 251, 451 respectively. Table 2 is a table showing a registration example of the relay connection database 151 included in the relay device 15.
<tables num="2"><img file="JP4492575B2_D0002.tif" /></tables>
The relay connection database 151 is a database that manages the TCP connection currently established by the relay device 15. In the "Client" field, the device name of the communication device that requested the connection with the relay device (referred to as the request source communication device as appropriate in the following description) is set. ClientX and ClientY in the table are, for example, the names of devices assigned to communication devices 11, 21, and the like. The URL and IP address of the relay device of the relay destination are set in the "relay destination URL" and "IP address" fields. The port number of the generated TCP connection is set in the "connection number" field, and the time when the TCP connection is generated is set in the "generation time" field.
In the present embodiment, a TCP connection is established with the relay device of the communication destination by the designation from the request source communication device, but it is the request source that can perform communication using this TCP connection. Only communication devices are available. That is, as shown in Table 2, there is a one-to-one correspondence between the communication device and the TCP connection.
The contents of the relay connection databases 251,451 are the same as those of the relay connection database 151 shown in Table 2. The status of the TCP connection currently established by the relay devices 25 and 45, respectively, is registered.
The flow of communication processing in the communication system having the above configuration will be described with reference to FIGS. 7 to 9. FIG. 7 is a diagram showing the overall processing flow of the communication system including the communication devices 11, 12, the relay devices 15, 25, and the server device 35. In the following description, the communication between the relay devices 15 and 25 and the server device 35 will be described by using SIP (Session Initiation Protocol) as an example, but other protocols may be used. ..
Similar to the first embodiment, each of the relay devices 15 and 25 sends a SIP "REGISTER request message" to the server device 35 at the time of initialization or periodically, and the position information (IP address, port) of the relay device is transmitted. The number, etc.) is notified to the server device 35. In FIG. 7, in the initial state, the relay device 15 and the relay device 25 are logged in to the server device 35. First, the relay device 25 notifies the server device 35 of the logout status information (step S401), and the server device 35 responds to this (step S402). The server device 35 executes the logout process of the relay device 25, and updates the "status" field of the relay device 25 to logout in the relay device database 351.
In this state, the communication device 11 transmits the relay transmission request and the status confirmation request of the data for which the relay device 25 is specified to the relay device 15 (S403). When the relay device 15 requests the server device 35 to notify the status information (S404), the server device 35 responds (S405), and then notifies that the relay device 25 is in the logout state (S406). .. The relay device 15 responds to this notification (S407). Further, the relay device 15 notifies the communication device 11 that the relay device 25 is in the logout state (S408). As a result, the communication device 11 waits until the relay device 25 is logged in.
Next, the relay device 25 notifies the server device 35 of the login status information (step S409), and the server device 35 responds to this (S410). The server device 35 executes the login process of the relay device 25, and updates the "status" field of the relay device database 351 to login. Further, the server device 35 notifies the relay device 15 that the relay device 25 has been logged in (S411). The relay device 15 responds to this notification (S412). Further, the relay device 15 notifies the communication device 11 that the relay device 25 is in the logged-in state (S413).
Upon receiving the notification by S413, the standby communication device 11 again makes a relay transmission request specifying the relay device 25 (S414). In this embodiment, the communication device 11 waits until the relay device 25 is notified that the relay device 25 has been logged in, but does not wait for such a notification and periodically makes a relay transmission request. It may be in the form of transmitting to the relay device 15.
When the relay device 15 receives the relay transmission request from the communication device 11, the relay device 15 transmits the connection request to the relay device 25 to the server device 35 (S415). This connection request is a SIP "INVITE request message" as described in the first embodiment, and includes TCP connection information. The server device 35 relays this connection request to the relay device 25 (S416). In response to this request, the relay device 25 sends a response to the server device 35 to allow the connection (S417). This response is a SIP "200 OK response message", as described in the first embodiment, and includes TCP connection information. The server device 35 relays this response to the relay device 15 (S418). In this way, the relay device 15 and the relay device 25 exchange TCP connection information. In response to this response, the relay device 15 sends a TCP connection request to the relay device 25 (S419). As a result, a TCP connection is established between the relay device 15 and the relay device 25.
The above processing is dynamically processed, for example, when a communication processing from the communication device 11 to the communication device 21 occurs. In other words, the relay devices are not fixedly connected, but are connected by triggering the occurrence of traffic. However, in order to prepare for the connection request from the other party's relay device, the network administrator needs to log in to the server device 35 to prepare the relay device in the network as shown in step S409. ..
In the present invention, the relay device 15 transmits a SIP INVITE request via the server device 35 in response to an instruction from the communication device 11, thereby establishing a TCP connection (media session) for relay. That is, when a connection request is generated from the communication device, the relay path as a media session is generated by using the call control protocol, so that the communication path for relay can be dynamically established.
When a TCP connection is established between the relay device 15 and the relay device 25 in this way, the relay device 15 and the relay device 25 hold the TCP connection. Then, when the communication device 11 transmits data to the communication devices 21, 22 and the like (S421), the relay device 15 relays the data to the relay device 25 (S422). The relay device 25 further relays the relayed data to the communication devices 21, 22, and the like. Similarly, the data transmitted from the communication devices 21, 22 and the like is relayed to the relay device 15 via the relay device 25 (S423), and further relayed to the communication device 11 via the relay device 15 (S). S424).
When the relay transmission using the relay device 25 is completed, the communication device 11 transmits a disconnection instruction to the relay device 15 (S425). The relay device 15 transmits a disconnection request for the relay device 25 to the server device 35 (S426). The server device 35 relays this request to the relay device 25 (S427). The response from the relay device 25 is transmitted to the server device 35 (S428) and relayed to the relay device 15 (S429). As a result, the TCP connection between the relay device 15 and the relay device 25 is disconnected, and the relay device 15 notifies the communication device 11 that the TCP connection has been disconnected (S430).
In such a state, when another communication device 12 again makes a relay transmission request specifying the relay device 25 (S431), the connection request is transmitted from the relay device 15 to the server device 35 (S432). If the relay device 25 is in the logout state at this point, the server device 35 notifies the logout state (S433), and the communication device 12 is notified that the other party's relay device 25 is in the logout state. In the communication device 12, the relay transmission request to the relay device 25 is made again when the relay device 25 is logged in, as in the process of the communication device 11 described above. As a result, a TCP connection is established between the relay device 15 and the relay device 25.
FIG. 8 is a flowchart focusing on the processing of the relay device 15 in the processing described with reference to FIG. First, the relay device 15 confirms whether or not a relay instruction has been generated from the communication devices 11, 12, etc. (step S501), and if so, confirms whether or not a status confirmation instruction has been generated. (S502). If a status confirmation instruction is issued, it is checked whether the relay device at the relay destination is logged in (S503). When it is found that the relay device at the relay destination is logged out (NO in S503), it waits until a login notification is received (S504).
When the server device 35 receives the notification that the relay device of the relay destination is in the login state, the request source communication device is notified that the relay destination is logged in (S505). Then, it waits again until it receives a relay instruction from the communication devices 11, 12, etc. (S506). When it receives a relay instruction, it shifts to S508. Further, in S503, when it is found that the relay device of the relay destination is logged in, the process immediately shifts to S508. If the request from the communication device does not include a status monitoring instruction (NO in S502), if the relay destination is logged in (YES in S507), the process shifts to S508 and the relay destination is logged in. If not, it returns to S502 and repeats the process. That is, when a status monitoring instruction is received from the requesting communication terminal, the relay device at the relay destination monitors until the login status is received, and when the notification of the login status is received, the information is also sent to the requesting communication device. Notify.
The relay device 15 then generates TCP connection information (S508) and sends a connection request (S509). Then, it waits for a response from the relay device 25 (S510), and if there is no response, an error notification is sent to the requesting communication device (S511), and the process returns to S501 and repeats the process. When a response is received, the TCP connection information being responded is analyzed (S512). That is, the port number information and the like included in the response transmitted from the relay device 25 are acquired. Then, a TCP connection is made to the relay device 25 (S513). Notify the requesting communication device that the connection with the relay destination is completed (S514). Then, the newly generated TCP connection information is registered in the relay connection database 151 (S515).
Move on to the flowchart of FIG. When relay data is transmitted from the communication device 11 or the like (YES in S516) while the TCP connection is established and held, the data is relayed to the communication device 21 or the like (S517). When the relay data for the communication device 11 or the like is received (YES in S518), the data is relayed and transmitted to the communication device 11 or the like of the relay destination (S519). When a disconnection request is received from the relay device 25 (YES in S520), a response is transmitted (S521), and the TCP connection is disconnected (S522). If a disconnect request is made by the requesting communication device (YES in S523), a disconnect request is sent to the relay device 25 at the relay destination (S524), and if a response is received (YES in S525), TCP Disconnect (S526). Then, the requesting communication device is notified that the connection with the relay destination has been disconnected (S527), and the TCP connection information registered in the relay connection database 151 is deleted (S528).
As described above, according to the second embodiment, when a relay instruction is generated from the communication device, a TCP connection is dynamically established with the relay device at the relay destination, and communication between private networks is possible. Become. Unlike conventional VPNs that are fixedly set, when a communication request occurs, the connection required for that communication is established, so resources can be used efficiently.
Further, in the second embodiment, only the requesting communication device can use the communication connection generated in response to the request from a certain communication device. For example, when a communication request is generated from the communication device 11 to the communication device 21, and a TCP connection is established between the relay device 15 and the relay device 25 in response to this request, this TCP connection becomes the communication device. It is used only for communication between 11 and the communication device 21. In other words, the relay device 15 and the relay device 25 relay only the data transmitted and received between the communication device 11 and the communication device 21 to this TCP connection. Therefore, the connection generated by the request generated from the communication device can be exclusively owned by the communication device.
In the example shown in FIG. 6, it is assumed that the relay device 15 and the relay device 25 are connected by the request of the communication device 11, and the relay device 15 and the relay device 45 are connected by the request of the communication device 12. To do. In this case, it was explained with reference to FIG. 5 that individual data relay connections are generated. Therefore, the communication device 11 and the communication device 12 perform relay transmission using different TCP connections. On the other hand, when the communication device 11 is performing relay transmission with the relay device 25 specified, and the communication device 12 also gives a relay instruction with the same relay device 25 specified, it is already generated in this case as well. Since the TCP connection is exclusively used by the communication device 11, another communication connection is formed.
{Third embodiment} Next, a third embodiment of the present invention will be described. In the third embodiment as well, as in the second embodiment, the relay devices are connected in response to the request from the communication device. However, the third embodiment is different from the second embodiment in that when a connection between the relay devices is already formed, other communication devices also share the connection. Hereinafter, the points different from the second embodiment will be mainly described.
Table 3 is a table showing a registration example of the relay connection database 151 included in the relay device 15 in the third embodiment. As shown in the table, multiple clients (communication devices) are associated with one TCP connection. In the example of this table, the connection number 49583 because the relay transmission request is generated from the two communication devices (ClientX, ClientY) and both communication devices specify the same relay device (Relayserver1@sample.net). It shares the TCP connection of.
<tables num="3"><img file="JP4492575B2_D0003.tif" /></tables>
The contents of the relay connection databases 251, 451 provided in the relay devices 25 and 45 are the same as those of the relay connection database 151 shown in Table 3. The status of the TCP connection currently established by the relay devices 25 and 45, respectively, is registered.
The flow of communication processing in the communication system having the above configuration will be described with reference to FIGS. 10 to 12. FIG. 10 is a diagram showing the overall processing flow of the communication system including the communication devices 11, 12, the relay devices 15, 25, and the server device 35. In the following description, the communication between the relay devices 15 and 25 and the server device 35 will be described by using SIP (Session Initiation Protocol) as an example, but other protocols may be used. ..
In FIG. 10, the processes from step S701 to step S724 correspond to steps S401 to S424 in FIG. 7, respectively, and are the same processes, and thus the description thereof will be omitted. That is, a relay transmission request for which the relay device 25 is specified is generated from the communication device 11, and a TCP connection is established between the relay device 15 and the relay device 25. Then, data is transmitted and received between the communication device 11 and the communication device 21 and the like.
In such a state, another communication device 12 again makes a relay transmission request specifying the relay device 25 (S725). Since the relay device 15 currently has a TCP connection with the relay device 25, the relay device 15 notifies the communication device 12 that the relay transmission of data is OK (S726). As a result, when data is transmitted from the communication device 12 (S727), the relay device 15 relays the data transmitted from the communication device 12 to the relay device 25 by using the TCP connection that has already been established. There is (S728). The relay device 25 also relays the data transmitted from the communication device 21 or the like to the communication device 12 to the relay device 15 by using the already established TCP connection (S729). The relay device 15 further transmits the received data to the communication terminal 12 (S730).
As described above, in the third embodiment, if a TCP connection has already been established between the relay devices and the TCP connection can be used for the generated relay transmission request, a new TCP connection is established. do not do. The same TCP connection is shared by multiple communication terminals. This makes it possible to reduce the load required to establish a TCP connection and speed up communication between different networks. In addition, it is possible to save the resources of the relay device. For example, when a large number of communication terminals connected to LAN10 and a large number of communication terminals connected to LAN20 communicate via the Internet, it is possible to speed up processing and save resources, which is effective. .. It is also effective when the amount of data relayed and transmitted from one communication device is small.
In a state where the communication device 11 and the communication device 12 share the TCP connection and perform data communication as described above, the communication device 11 sends a disconnection instruction to the relay device 15 (S731). Since the communication device 12 uses the same TCP connection, the relay device 15 does not particularly process the instruction of S731, but only responds (S732).
After that, when the relay transmission using the relay device 25 is completed, the communication device 12 transmits a disconnection instruction to the relay device 15 (S733). Since the relay device 15 has already received the disconnection instruction from the communication device 11 and can determine that the shared TCP connection is no longer needed, the relay device 15 transmits a disconnection request to the relay device 25 to the server device 35 (S734). The server device 35 relays this request to the relay device 25 (S735). The response from the relay device 25 is transmitted to the server device 35 (S736) and relayed to the relay device 15 (S737). As a result, the TCP connection between the relay device 15 and the relay device 25 is disconnected, and the relay device 15 notifies the communication device 11 that the TCP connection has been disconnected (S738).
FIG. 11 is a flowchart focusing on the processing of the relay device 15 in the processing described with reference to FIG. First, the relay device 15 confirms whether or not a relay instruction is generated from the communication devices 11, 12, etc. (step S801). If a relay instruction has been issued, check whether a TCP connection has already been established with the relay device at the relay destination (S802). That is, it is confirmed whether or not the same relay device has already been specified by another communication device and communication is established with the relay device.
If the connection is already made to the specified relay destination (YES in S802), the requesting communication device is notified that data can be relayed (S815). Then, the information in the relay connection database 151 is updated (S816). That is, since the TCP connection is already registered in the database, a client (communication device) is added. In the example shown in Table 3, for example, if ClientX and the TCP connection with connection number 49583 are registered in association with each other, ClientY is added to the client field of this record.
If the connection with the relay destination specified in S802 has not been established yet, the processing of S803 to S814 is executed. This process corresponds to the processes of S502 to S513 in FIG. 8 and is the same process, so the description thereof will be omitted.
Move on to the flowchart of FIG. When relay data is transmitted from the communication device 11 or the like (YES in S817) while the TCP connection is established and held, the data is relayed to the communication device 21 or the like (S818). When the relay data for the communication device 11 or the like is received (YES in S819), the data is relayed and transmitted to the communication device 11 or the like of the relay destination (S820). When a disconnection request is received from the relay device 25 at the relay destination (YES in S821), a response is transmitted (S822), and the TCP connection is disconnected (S823). In this way, when the TCP connection is disconnected from the relay device 25 of the relay destination, the communication device performing the relay transmission is notified that the connection with the relay destination is disconnected (S824). If the disconnected TCP connection is shared by multiple communication devices, the disconnection is notified to all communication devices (S824, S825).
When a disconnection request is made by the requesting communication device (S826), the relay device 15 checks whether the TCP connection instructed to disconnect is shared with another communication device (S827). When shared with other communication devices, a formal disconnection notification is sent to the instructed communication device without disconnecting the instructed TCP connection (S828). Then, the information in the relay connection database 151 is updated (S829). In other words, the information of the client (communication device) that requested the disconnection instruction is deleted from the shared TCP connection information. In this way, the relay device 15 always manages the currently established TCP connection and the communication device sharing the TCP connection.
If the TCP connection instructed to disconnect is not shared with other communication devices (NO in S827), a disconnect request is sent to the relay device 25 (S830), and if a response is received (YES in S831). ), Disconnect the TCP connection (S832). Then, the requesting communication device is notified that the connection with the relay destination has been disconnected (S833), and the TCP connection information registered in the relay connection database 151 is deleted (S834).
As described above, according to the third embodiment, when a relay instruction is generated from the communication device, a TCP connection is dynamically established with the relay device at the relay destination, and communication between private networks is possible. Become. Further, when a relay instruction is generated, if a TCP connection has already been established with the relay destination, the connection is shared. As a result, high-speed processing and effective use of resources are realized.
<figref num="1">It is a block diagram of the communication system which concerns on 1st Embodiment.</figref><figref num="2">It is a figure which shows the processing flow of the communication system which concerns on 1st Embodiment.</figref><figref num="3">It is a flowchart focusing on a relay device.</figref><figref num="4">It is a flowchart focusing on a relay device.</figref><figref num="5">It is a figure which shows the image which a plurality of relay connections are established.</figref><figref num="6">It is a block diagram of the communication system which concerns on 2nd Embodiment.</figref><figref num="7">It is a figure which shows the processing flow of the communication system which concerns on 2nd Embodiment.</figref><figref num="8">It is a flowchart focusing on a relay device.</figref><figref num="9">It is a flowchart focusing on a relay device.</figref><figref num="10">It is a figure which shows the processing flow of the communication system which concerns on 3rd Embodiment.</figref><figref num="11">It is a flowchart focusing on a relay device.</figref><figref num="12">It is a flowchart focusing on a relay device.</figref>
Code description
10 LAN 11 Communication equipment 15 Relay device 16 gateway 20 LAN 21 Communication equipment 25 Relay device 26 gateway 30 WAN 35 Server device
15 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15
Every citation, both ways
| Document | Relation | Office |
|---|---|---|
| JP2006067045A | Cites | Japan |
| JP2006050006A | Cites | Japan |
| JP2002217943A | Cites | Japan |
| JP06090236A | Cites | Japan |
| JP2003032310A | Cites | Japan |
| JP10247946A | Cites | Japan |
| 奥村 伸二,技術解説 SIP(session initiation protocol),日経コミュニケーション,日本,日経BP社,2003年 9月22日,第399号,p.150~p.158 | Non-patent | – |
| デジタルアドバンテージ,NetBIOS名の登録,[online],2002年 8月16日,[検索日:平成21年11月16日],インターネット<URL:http://www.atmarkit.co.jp/fwin2k/network/baswinlan005/baswinlan005_02.html> | Non-patent | – |
11 members in 3 offices
Members11
| Document | Office | Kind | |
|---|---|---|---|
| CN101047603A | China | A | |
| US2007233844A1 | United States of America | A1 | |
| JP2007267136A | Japan | A | |
| JP2007267137A | Japan | A | |
| JP2007267138A | Japan | A | |
| JP4333684B2 | Japan | B2 | |
| JP4492575B2This record | Japan | B2 | |
| JP4535019B2 | Japan | B2 | |
| CN101047603B | China | B | |
| US2012102205A1 | United States of America | A1 | |
| US8499083B2 | United States of America | B2 |
27 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of completion of termEXPY | EXPY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Report on retrievalJAPANESE INTERMEDIATE CODE: A971007A977 | A977 |
Numbers
- Publication
- 4492575
- Application
- 90690
Titles2
- Japanese
- 中継装置および通信システム
- English
- Relay device and communication system
Classification
- IPC, 2
- H04L12 70
- H04L12 56
