KR200349700Y1 - Apparatus for virtual routing on Web Service - Google Patents

Abstract

The present invention provides a packet receiving unit for receiving and providing a packet composed of XML, and extracting the destination information of the packet from the packet composed of the XML, and if the extracted destination information corresponds to its own IP address, Extracting and providing a type of service; otherwise, a service splitter for providing the packet; and a routing processor for performing virtual routing using the destination information included in the packet provided by the service splitter. A virtual routing device based on a web service including a network interface module for virtual routing and a search module for searching whether the content is stored according to a content search command received from a client connected through the Internet or the network interface module. It is about.

Description

Virtual routing device based on web service {Apparatus for virtual routing on Web Service}

The present invention relates to a virtual routing device and a search device based on a web service to share contents of various sites on the Internet. More specifically, when a client connected to one server requests content from the server, The present invention relates to a virtual routing device and a retrieval device for retrieving content stored in another server and making it available to a client if the user does not have the requested content.

The development of the Internet has allowed computer users to access a variety of content online, including pictures, music, movies, and education. As a result, various service providers providing contents through the Internet have been created. Accordingly, users have a wider choice of contents. Recently, as the types, characteristics, and capacities of contents provided by service providers are diversified, service providers providing similar types of contents gradually tend to be associated with each other. In addition, users want to be able to enjoy Internet contents more comfortably by searching contents provided by numerous service providers in one search site.

In the past, attempts were made to meet these expectations by using TCP / IP-based standalone applications. However, these methods could not fully satisfy users' expectations due to the limitation of scalability, and each of the above services was provided as a web-based service. Service providers are building services with their own technologies and methods, so it is not easy to combine them organically.

In order to solve this problem, a new technology called web service has recently been developed. Web service is a technology that provides a foundation for sharing data between sites based on XML data format. The Data Transfer Protocol (Simple Object Access Protocol), and many other management protocols and devices are defined.

However, Web services have only created the basis for data transmission, and in fact, the level of devices for performing various services is insufficient, and service providers still have to make great efforts to share their developed contents with each other. For the reasons described above, there is a need for a method and apparatus for easily searching for contents distributed in multiple servers as a practical technology for easily sharing contents that are made by various vendors.

The object of the present invention is to provide a search apparatus that allows service providers to share contents provided through separate servers with each other through the Internet.

Another object of the present invention is to provide a web service based virtual protocol structure for the device, and a virtual routing socket module.

1 is an exemplary view showing a search apparatus using a virtual routing according to the present invention.

2 is an exemplary view showing a virtual routing socket module according to the present invention

Figure 3 is an embodiment processing flow diagram showing the operation of the virtual routing socket module according to the present invention

4 is an exemplary view showing an XVIP protocol stack according to the present invention

5 is an exemplary view showing a connection structure for routing according to the present invention

6 is an exemplary diagram showing a connection process of a new data server using a control server according to the present invention.

7 is a flowchart showing an embodiment of a basic extended search method according to the present invention.

8 is a flowchart showing an embodiment of a backward extended search method according to the present invention.

9 is a flowchart illustrating an exemplary embodiment of a forward extended search method according to the present invention.

10 is an exemplary view showing a forward extended search step according to the present invention

In order to achieve the above technical problem, the present invention is a packet receiving unit for receiving and providing a packet composed of XML, and after extracting the destination information of the packet from the packet composed of the XML, the extracted destination information is its IP address If it corresponds to the type of service is extracted from the packet and provided, otherwise, the service splitter for providing the packet, and the virtual routing using the destination information included in the packet provided by the service splitter Characterized in that the network interface module for virtual routing including a routing processor to perform the.

In addition, in order to achieve the technical problem, the present invention includes a search module for searching whether the content is stored according to a content search command received from a client or network interface module connected to the network interface module and the Internet. It is characterized by a virtual routing device based on the web service.

In addition, in order to achieve the above technical problem, the present invention is characterized by a virtual routing device based on a web service including two or more of the virtual routing device, preferably receiving a server search command and the corresponding content exists It further includes a control server to find a virtual IP address of the server to send a content search command to the server.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

For reference, the transmission method in the device of the present invention is a method of transferring the Internet Protocol version 4 (IPv4), which is the data transmission protocol of the Internet, directly to the application layer. Similar to Therefore, a unique IP address is given to all web service servers in charge of sending and receiving, and the IP address used for sending and receiving in the present invention is an IP address of an application layer, thus transmitting and receiving datagrams on the existing Internet. It is a virtual address space that is completely different from the IP address.

1 is an exemplary view showing a search apparatus using a virtual routing according to the present invention, showing that the client provides the search results from a plurality of servers using a communication system that communicates using a packet composed of XML. The thick solid line shown in FIG. 1 represents the flow of the results through the basic search to the server 21 to which the server 21 is connected, and the broken line shows a plurality of servers (through the network to which the server 21 that received the search request from the client 10 is connected). 22, 23 is searched to show the flow of results through an extended search that collects, aggregates, and provides the search results from the respective servers 22, 23. Meanwhile, each server 21, 22, and 23 may include a virtual routing socket module 100, a search module 200, and a content DB 300 corresponding to a network interface module for virtual routing. The virtual routing socket module 100 is a platform-based service module called a web service. The web service refers to a platform that can provide various services by sharing various services through communication of standardized XML data. The virtual routing socket module 100 of the present invention also transmits data based on XML. One module that provides functions such as receiving, retransmitting, and so on.

Figure 2 is an exemplary view showing a virtual routing socket module according to the present invention, the input of the virtual routing socket module 100 receives packets from other servers, and from the CMS using the virtual routing socket module 100 Can be divided into Packets received from other servers pass through the packet inspector 110 to filter only valid packets and are stored in the input buffer 112. The packet generator 120 receives a command from the CMS, generates different XML packets according to the type of the command, and stores the generated packet in the input buffer 122. The service splitter 130 receives the XML packet from the input buffers 112 and 122 and the server including the virtual routing socket module 100 should receive the received XML packet to another server. In this case, if the packet is to be received, the packet is stored in the reception buffer 140 based on the process delimiter, and in the case of a packet to be transmitted to another server, the routing processor 150 stores the packet from the packet. After extracting information about the destination of the packet through the routing process, the packet is transmitted to the output buffer 160, and the output buffer 160 transmits the packet to another server connected to each buffer.

On the other hand, the virtual routing socket module 100 for data transmission between the virtual database and the CMS is a network interface in the form of a web service using a SOAP protocol. It is composed of XML. The connection between network interfaces is a method of having one centralized communication server. However, in order to increase data transmission and provide reliable service to a dynamic network, a distributed communication network must be established like the current Internet network. Accordingly, the packet is composed of XML by extracting only the parts necessary for the construction of the virtual database and the data transmission between the CMS from the structure of IP (Internet Protocol), the protocol of the Internet network. The service splitter 130 illustrated in FIG. 2 identifies a destination of received packets, interprets a type of service (TOS) included in the packet, and distributes the packet to an appropriate service. To know the destination of the packet, the header of the received packet is extracted, and the destination information obtained from the header is compared with its address from an environment variable to distinguish whether the packet has arrived. If the destination is a different server, the service splitter 130 transmits the packet to the routing processor 150. Otherwise, the service splitter 130 performs a task such as environment variable management or routing table management according to the type of service (TOS). In the case of a packet transmitted to an application from another server, the packet is input to the appropriate receiving buffer 140 by referring to an application-related variable.

An example of a schema representing a packet construction method and a configuration of a packet is as follows.

<Packet>

- Explanation :

Indicates that this is a packet document

Element:

+ <Header>: Part that records packet transmission information and packet service information

+ <Data>: portion of data to be sent

+ <Request>: used in requests such as Search

+ <Response>: used in response to a request

Schema

<xsd: element name = "Packet"> <xsd: complexType> <xsd: sequence> <xsd: element name = "Header" type = "HeaderType"> </ xsd: element> <xsd: element name = "Data" type = "DataType"> </ xsd: element> </ xsd: sequence> </ xsd: complexType> </ xsd: element> <xsd: complexType name = "DataType"> <xsd: sequence> <xsd: element name = "Request" minOccurs = "0" type = "RequestType" /> <xsd: element name = "Response" minOccurs = "0" type = "ResponseType" /> </ xsd: sequence> </ xsd: complexType>

<Header>

- Explanation :

Part that records the transmission information of the packet and the information about the service of the packet

Element:

+ <TTL>: Time To Live, how many hops the communication module can route

+ <Protocol>: Enter protocol to interpret packets

+ <ScrIP>: Virtual IP of the transmitting end

+ <DestIP>: Virtual IP of the receiver

+ <Ext>: part defining extended search

+ <Ext>: part defining the level of extended search

+ <Opt>: enter routing options

Schemas and examples:

<xsd: complexType name = "HeaderType"> <xsd: sequence> <xsd: element name = "TTL" type = "xsd: integer" /> <xsd: element name = "Protocol" type = "xsd: string" / > <xsd: element name = "SrcIP" type = "xsd: string" /> <xsd: element name = "DestIP" type = "xsd: string" /> <xsd: element name = "Ext" type = "xsd : string "/> <xsd: element name =" ExtLevel "type =" xsd: integer "/> <xsd: element name =" Options "type =" xsd: string "/> </ xsd: sequence> <xsd: attribute name = "Version" type = "xsd: string" /> <xsd: attribute name = "TOS" type = "xsd: string" /> </ xsd: complexType> Example) <Header Version = "1.0" TOS = "Search"> <TTL> 32 </ TTL> <Protocol> TelezenSearchWebService_Ver1.0 </ Protocol> <SrcIP> 61.33.50.1 </ SrcIP> <DestIP> 61.33.50.4 </ DestIP> <Ext> Base </ Ext> <ExtLevel> 0 </ ExtLevel> <Options> NOOP </ Options> </ Header>

<Request>

- Explanation :

Used when requesting search or necessary information between communication modules

Element:

+ <Command>: Indicates the requesting statement

+ <ID>: Requester's Identification

+ <PW>: Requestor's password

+ <Code>: Encryption code to identify the requestor

+ <Keyword>: keyword used in the search

Schemas and examples:

<xsd: complexType name = "RequestType"> <xsd: sequence> <xsd: element name = "Command" type = "xsd: integer" /> <xsd: element name = "ID" type = "xsd: string" / > <xsd: element name = "PW" type = "xsd: string" /> <xsd: element name = "Code" type = "xsd: string" /> <xsd: element name = "Keyword" type = "xsd : string "/> <xsd: element name =" Discern "type =" xsd: string "/> </ xsd: sequence> <xsd: attribute name =" id "type =" xsd: string "/> </ xsd : complexType> Example) <Data> <Request id = "00364322"> <Command> GetImage </ Command> <ID> jonah </ ID> <PW> telezen </ PW> <Code> tlz2003 </ Code> <Keyword > Dog </ Keyword> <Discern> all </ Discern> </ Request> </ Data>

<Response>

- Explanation :

As response data, it is possible to utilize search results, data transmission status, routing table, etc.

- property :

+ <id>: response data recognition code

Element:

+ <URL>: URL type address of content store

+ <CATEGORY>: content category

+ <DISCERN>: Content Recognition Code

+ <NAME>: content title

Schemas and examples:

<xsd: complexType name = "ResponseType"> <xsd: sequence> <xsd: element name = "CONTENT" minOccurs = "0" maxOccurs = "unbounded"> <xsd: complexType> <xsd: attribute name = "URL" type = "xsd: string" /> <xsd: attribute name = "CATEGORY" type = "xsd: integer" /> <xsd: attribute name = "DISCERN" type = "xsd: string" /> <xsd: attribute name = "NAME" type = "xsd: string" /> </ xsd: complexType> </ xsd: element> </ xsd: sequence> <xsd: attribute name = "id" type = "xsd: string" /> </ xsd: complexType> Example) <Data> <Response id = "00364322"> <CONTENT URL = "http://WebtutorNet.telezen.com/Images/a.jpg" CATEGORY = "2" DISCERN = "image" NAME = "Puppy" /> <CONTENT URL = "http://WebtutorNet.telezen.com/Images/b.jpg" CATEGORY = "1" DISCERN = "image" NAME = "Genius Joe" /> <CONTENT URL = "http : //webtutornet.telezen.com/images/22_000037.JPG "CATEGORY =" 1 "DISCERN =" image "NAME =" Cambridge "/> <CONTENT URL =" http://webtutornet.telezen.com/images/22_000038 .JPG "CATEGORY =" 2 "DISCERN =" image "NAME =" Oxford "/> </ Response> </ Data>

The routing processor 150 receiving the packet from the service splitter 130 extracts header information from the received XML packet and decreases the time to live (TTL) by one. If the reduced value is 0 or less, the packet should be discarded from memory because it should be discarded. Otherwise, the destination address information is extracted from the header to obtain a list of all matchable output buffers from the routing table 152. In this case, the longest matching process is performed once again for the fastest routing, and the longest matching method selects the longest address of the subnet mask among the available addresses and consequently connects the most specific route. The packet is delivered to the address of the output buffer 160, and is properly distributed according to the QOS method and transmitted to another server.

3 is a flowchart illustrating an operation of a virtual routing socket module according to the present invention. When a web service server designates a receiving server for searching and transmits a search query and a search range to a virtual routing socket module, the virtual routing The socket module prepares a header of an XML packet, appends it to an existing content, and sends it to the designated receiving server. Upon receiving the XML packet, the designated receiving server decreases the TTL value by 1 (S1), checks whether the DstIP included in the packet is its own (S2), and if the DstIP is its own, a suitable web service according to the TOS. Pass a packet to a module in it. If the DstIP is not itself, the packet is delivered to the routing module S6, and data is transmitted according to the routing table (S8). After passing the packet to the routing module S6, the TOS, Ext, and ExtLevel tags of the packet are checked (S7). If the packet is to be transmitted to the search service module S4, the packet is transmitted to the search service module.

4 is an exemplary diagram illustrating an XVIP protocol stack according to the present invention. The XVIP emulates a communication function of IPv4 on a SOAP layer, and assigns a virtual IP to all servers, and each server. By providing a routing function to each other, it is possible to emulate the routing function of IPv4, to facilitate the expansion of the server network.

The XVIP is a protocol that provides scalability and stability of the network. In terms of scalability, generally, SOAP can perform necessary functions such as search and distribution. However, as servers are expanded in a distributed database, SOAP transmission is involved in each server. Complex modules need to be installed and a detailed description of the transfer is required. In addition, the more servers that participate in a distributed database group, the more effort should be made to keep all servers aware of each server. However, since the Internet is excellent in coping with the addition and deletion of routers, the present invention provides a new XML Virtual Internet Protocol (XVIP) to apply this concept to the addition and deletion of servers in a distributed database. By allowing them to perform routing functions, the scalability of distributed databases can be maximized. In the case of using the XVIP, each server does not need to remember a connection relationship with all servers, but only a connection relationship with adjacent servers. Each server stores only the history of which related content existed in each server for each search keyword in the search results, and each server can go to each server by routing. Since the concept of IP is used, it is possible to search by multiple servers at the same time by setting a specific flag and broadcasting, multicast, etc., and it is also possible to apply various extended search methods applying this. Using SOAP, it is difficult to extend a service because it is difficult to perform a systematic transport management service for a plurality of servers. In particular, in terms of activating distribution services among multiple companies, not the concept of distributed database in one CMS company, it is necessary to consider the number of servers participating in the distributed database. Therefore, create a communication protocol that can support multiple servers. It is very useful to apply it to distributed databases. On the other hand, in terms of stability, studies on maintaining information of routers on TCP / IP in the existing Internet have been and are still in progress. Currently, the most active researches have been conducted on the areas that respond appropriately to changes in the distributed environment, and the most advanced areas are this field. The same stability can be obtained by introducing. In addition, by placing the XVIP protocol on top of the SOAP protocol, it can be applied to direct content transactions between servers. Each server can directly connect a communication channel over TCP / IP, but there is a burden to involve TCP / IP, which is a lower-level protocol, and if there is a firewall in the communication path, it must be considered. Therefore, using SOAP that can communicate regardless of firewall can be a reasonable method. When SOAP communication is performed using XVIP, it is easy to make transmission application by using an interface similar to that of TCP / IP. It also has the advantage of being able to write.In addition, the security protocol and performance improvement techniques used in the Internet can be applied to the transmission process and the transmission management process, so that there is a great possibility of development.

XVIP according to the present invention is mainly IP (Internet Protocol-IETF RFC791), UDP (User Datagram Protocol-IETF RFC768), TCP (Transmission Control Protocol-IETF RFC793), ICMP (Internet Control Message Protocol-IETF RFC792), ARP (Address References were made to protocols such as Resolution Protocol-IETF RFC826), Routing Information Protocol-IETF RFC1058 RIPv1, IETF RFC2453 RIPv2), and OSPF (Open Shortest Path First-IETF RFC1583 OSPFv2).

-Header structure of XVIP Packet field IPv4 XVIP usage Packet - Packet tag <Packet> </ Packet> Header - Header tag <Header> </ Header> Version IP version Version of XVIP Property of Header HeaderLength The length of the header - - TOS Type of Service Type of service (Search, Transfer, etc.) Property of Header Totallength The length of the entire packet - - Identification Reference Information for Packet Splitting -(No split) - Flags Reference Information for Packet Splitting -(No split) - FragmentOffset Packet segmentation information -(No split) - TTL Time-to-live Time-to-live <TTL> </ TTL> Protocol High Protocol High Protocol <Protocol> </ Protocol> HeaderChecksum Header Validation Value - - SourceIP Address Caller IP Outgoing Web ServiceServer IP <SrcIP> </ SrcIP> Destination IP Address Receiver IP Incoming Web ServiceServer IP <DestIP> </ DestIP> Ext - Broad match method <Ext> </ Ext> ExtLevel - Search Extensible Range <ExtLevel> </ ExtLevel> Options option option <Options> NOOP </ Options>

<Table 1> is an example of the head structure of XVIP. 'Packet' item is an item that does not exist in IPv4 and informs that the contents of the XML file are packets. In this design, the contents between the <Packet> and </ Packet> tags are used. The 'Header' item also exists in the existing IPv4, meaning that the content between <Header> and </ Header> is a header containing control information. The 'Version' item indicates the version of the protocol currently being used. Use numbers such as 0.9, 1.0, 1.532, etc., and the range of numbers can be written to the third digit after the decimal point. The 'Header Length' item indicates the IP header length of the IPv4. In the protocol of the present invention, even though the header length is not known, the </ Header> tag does not use the header. The 'TOS' item was also used in IPv4 and indicates the type of service. In the protocol of the present invention, 'Service', which refers to a search service, and 'Transfer', which refers to a direct data transmission service, may be the contents. The 'Total Length' item refers to the total length of a packet. Items used or not used in the present invention. Items such as 'Identification', 'Flags', and 'Fragment Offset' are used for packet splitting, which is the basic characteristic of IP routing, and are not used because the packet splitting function is not used in the present invention. Since the items introduced up to now after the header are all determined at the beginning of packet generation, they are designated as property values of the header tag. TTL is an item used during IP routing. It decreases every time it passes through a router. When the value reaches 0, the TTL loses its function as a packet and is soon destroyed. The same function in the present invention. The TTL value changes every time the router passes, so do not set it as a property of the header and set it as a separate item. The Protocol item is an item that refers to a type of service using a packet determined in the present invention. When the protocol of the present invention supports the performance of the service, it is an item to know the type of higher service, and this protocol provides a function to change the Protocol item to the upper protocol. The 'HeaderChecksum' item is IPv4. Was a special item for checking the validity of header information, but since the packet of this protocol has already been validated by the lower protocol, no additional validation is required. Therefore, this item is not used. The 'SourceIP Address' item is used to enter the sender's address. This is done by writing the IP address between <SrcIP> and </ SrcIP> tags. The 'DestinationIP Address' item is used to enter the recipient's address. This is done by entering the IP address between the <DestIP> and </ DestIP> tags. The 'Extension' and 'Priority' items are extended. Items used in the search method. 'Extension' item can execute its function by writing 'Base', 'Forward', 'Backward', etc. between <Ext> and </ Ext> tags. Base refers to the basic search method, Forward refers to the forward extended search method among extended search methods, and Backward refers to the extended backward search method among extended search methods. The 'ExtLevel' item indicates the detailed function of the extended search method. It is an item. The item is a general decimal number such as 0, 1, 2, 3, 4, etc. If the item is 0, the extended search method is not used. If the item is not 0, the extended search method is used. At this time, if the search method is backward extended search, the extended search is performed when the item is not 0. If the search method is 0, the extended search is not performed. If the search method is forward extended search and the item is 0, the extended search is not performed. If the item is a non-zero number, the extended level can be increased by a number. During the routing process, the non-zero extension level is decremented by one as it passes through one router, and when it reaches zero, the extended search is completed. <Table 2> is an example of how XVIP tag is applied to each search method. Option 'item is to write the information later to support the function required for the service. Currently, nothing is written.

Example of XVIP Tag Setting by Search Method Basic search Basic broad match Backward Extended Search Forward broad match Ext Base Backward orforward Backward Forward ExtLevel Don't care 0 As many as 1 to TTL According to the extended search level

XVIP Packet field Value

Table 3 shows an example of each field value of the XVIP packet.

XVIP Packet field Value Default example Remarks Version 1.0 1.0, 2.1, 3.5 The initial version is 1.0. TOS Search Search: Search packet Transfer: Data transmission packet Ack: Response packet - TTL One 1,2,3,4 ... Decrease by 1 each time you pass a router Ext Base Base: Basic Search Base Extension: Basic Extended Search Forward: Forward Extended Search Backward: Backward Extended Search It is ignored for packets other than search packets. ExtLevel 0 0: Basic expansion search 1, 2, 3, 4 ...: Forward expansion level It is ignored for packets other than search packets.

-Packet example

<Packet> // packet now

<Header version = "1.0" TOS = "Search"> // Now the header,

// version: 1.0, Search Packet

<TTL> 40 </ TTL> // 40 hops available

<Protocol> XVTCP </ Protocol> // parent protocol is XVTCP

<SrcIP> 61.33.50.28 </ SrcIP> // Sender's virtual IP is 61.33.50.28

<DestIP> 163.239.143.167 </ DestIP> // Recipient's virtual IP:

163.239.143.167

<Ext> Forward </ Ext> // Extended match is Forward broad match

<ExtLevel> 4 </ ExtLevel> // Forward broad match up to 4hop

<Options> NOOP </ Options> // No Option

</ Header> // end of header

<Data> // start of data

</ Data> // end of data

</ Packet> // end of packet

5 is an exemplary view showing a connection structure for routing according to the present invention. After granting virtual IPs to servers, a network between each server should be configured. The ideal method for network configuration among servers is a full mesh structure in which all servers are completely connected, but it has a disadvantage in that it is difficult to support multiple servers. Therefore, the connection between each server has a virtual physical path according to the connection order to the main control server, and a routing path is established on the generated physical path. The routing pass can use various algorithms currently used in IPv4. Representative examples include RIP-1, 2, OSPF, etc., depending on the size of the servers participating in the network. In particular, when the protocol is activated and the number of servers participating in the network is very large, the Autonomous System, which is a group of servers, can be classified locally using the Boarder Gateway Protocol such as BGP used on the Internet. OSPF is used for small servers participating in the network. This is because the nature of OSPF can create optimal routing paths in small networks. In large cases, the RIP can be used to configure routing paths, and the latest routing technologies such as RIP-2, which are currently used on the Internet, can be applied. Regardless of which routing algorithm is applied, each routing module has a routing table that matches the transmission target and the corresponding interface. In this design, the complex routing table is limited to the necessary functions and simplified as much as possible. The basic function of the router was referred to RIP version 1. However, as the network expands in the future, other routing algorithms such as RIP version 2 or OSPF version 2 may be used. An embodiment of routing using RIP version 1 is as follows.

Routing Table (RIP) in Router RTA Destination Next hop Hop count 192.10.1.0 Connected (E0) - 192.10.2.0 Connected (S1) - 192.10.3.0 Connected (S2) - 192.10.4.0 192.10.2.2 (S1) 192.10.3.2 (S2) 11 192.10.5.0 192.10.2.2 (S1) One 192.10.6.0 192.10.3.2 (S2) One

The routing table of Table 4 is an example of a routing table using the routing method of RIP version 1, and is a virtual routing table created assuming the network structure shown in FIG. According to the routing table of Table 4, when a packet having a destination of 192.10.1.xxx enters the router 1, the router 1 forwards the packet to the E0 interface. At this time, 192.10.1.xxx hosts (for example, 192.10.1.2) are directly connected to Router 1, so the expression “Connected” is added. Since they are directly connected, the Hop Count is not recorded. Similarly, since 192.10.2.xxx and 192.10.3.xxx are directly connected addresses, they are processed in the same way as in 192.10.1.xxx. For destinations with addresses 192.10.4.xxx, 192.10.5.xxx, and 192.10.6.xxx, packets are sent to the corresponding interfaces according to the routing table. The address of 192.10.4.xxx can be sent to Router 2 and Router 3 for processing according to the routing table. As shown in FIG. 5, Host 1 having an address of 192.10.1.2 sends packets through Router 1 and Router 2 to send a packet to Host 3 having an address of 192.10.6.2. The packet is sent to the S2 interface according to the routing table so that the packet reaches the 192.10.3.2 interface of Router 3. Since Hop Count is 1, the TTL value is decreased by one at the router.

6 is an exemplary view illustrating a connection process of a new data server using a control server according to the present invention, when the data server 1 requests an IP, the control server performs an operation of assigning an IP (S1) to an adjacent router. It provides information about (S2) to be able to configure the network. The data server 1 receiving the information sends a message to neighboring routers to perform a connection establishment process and finally participate in the network. On the other hand, the IP assignment from the control server is to refer to the IP assignment method to the ISP that was performed by the network information center (NIC) of the existing Internet to perform the IP area allocation, and then to use the automatic IP granting method using DHCP. In principle. An example of using this IP allocation method is shown in <Table 5>.

Example of Address Allocation Area Address space Allocation area Remarks 61.0.0.0 to 62.255.255.255 movie Cultural contents 63.0.0.0 to 64.255.255.255 manga 128.0.0.0 to 191.255.255.255 music 192.0.0.0 to 193.255.255.255 Fiction, poetry 194.0.0.0 to 195.255.255.255 Folk Culture, History 196.0.0.0 to 198.255.255.255 theater 199.0.0.0 to 199.255.255.255 Musical, opera 200.0.0.0 to 201.255.255.255 shopping 202.0.0.0 to 204.255.255.255 Academic 1 Academic Content 205.0.0.0 to 206.255.255.255 Academic 2 207.0.0.0 to 208.255.255.255 Academic 3 209.0.0.0 to 210.255.255.255 University Educational Institution 211.0.0.0 to 212.255.255.255 Elementary, Middle and High School 213.0.0.0 to 214.255.255.255 Other educational institutions 215.0.0.0 to 216.255.255.255 Other genres 217.0.0.0 to 217.255.255.255 Agency

If the server wants to join the network with an address assigned as shown in <Table 5>, it reports the genre handled by the server to the control server and waits for an IP grant. For example, if a server mainly dealing with the content about a play requests an IP from the control server, the control server performs a DHCP operation with IPs not assigned among the IPs between 196.0.0.0 and 198.255.255.255 to assign IP. do. After assigning the IP, the subtraction operation is performed on the IPs of the servers in the database and the current IP to find the nearest IP. In addition, the local tendency of each server and the distance from the control server are recorded to refer to finding the adjacent IP.

When a connection is established between each service provider using the XVIP, a basic environment for searching is created. The search method proposed in the present invention can be divided into a basic search method and an extended search method. The basic search method proceeds with a service flow in an existing search apparatus as it is, and the XVIP is used for the extended search method. The extended search method can be divided into basic extended search, backward extended search, and forward extended search according to the search direction.

7 is a flowchart illustrating a basic extended search method according to an embodiment of the present invention. The basic extended search is a method of receiving an extended search target by transmitting a search word to a control server. In order to perform such a search service, components such as a client, a data server, and a control server are required. A client is a data requester, who needs data. It requests data to data server 1 and receives necessary data from data server. The data server is responsible for providing data and performing actual search activities. Each server in charge of data service has its own contents and has an environment that can service them when requested by clients. When the data requested by the client is not in its database, the extended search can be performed according to a predetermined convention. The control server is a server that helps the organic coupling between the data servers. The control server has a function to register virtual IPs and keywords. The control server has a central control server and a secondary control server, there can be only one central control server, and there can be multiple secondary control servers per region, the location of the secondary control server is managed by the central control server. The central control server is responsible for the virtual IP registration service and the secondary control server assignment service, and the secondary control server is responsible for keyword registration and search response service. The virtual IP registration service of the control server functions to give a virtual IP to each data server. The IP assignment function uses a method of assigning by region by placing an IP management organization in the center as in the conventional IPv4. A data server that wants to join a new service group first registers with a central control server, receives an IP, receives a secondary control server that manages its own area, and performs a search service by interworking with the secondary control server. In addition, the keyword registration service of the control server is a function of registering the content search word, a unique function of the secondary control server. Each data server registers updated keywords for its contents with the control server immediately after the contents are secured or at regular intervals.

As shown in FIG. 7, when the basic extended search client sends a search word requesting content to the data server 1 (S100), the data server 1 searches for its own database (S110) and then, when there is no data, the control server. The search is requested at step S113. The control server searches for a table listing keywords sent from each data server (S120), creates a list of appropriate data servers (S121), and then returns the requested data server 1 including the data (S122). The requested data server 1 sends a search request message packet to the other data servers in the list received from the control server (S114), and the data servers in the message path perform routing operations (S130 and S140). To reach (S150). As an embodiment of the present invention, when the data server 1 includes the data server 4 in the server list provided from the control server, assuming a process of making a search request to the data server 4, the data server 1, 2, 3 When the virtual IP of, 4 is 61.33.50.1, 61.33.50.2, 61.33.50.3, and 61.33.50.4, the virtual IP packets generated by Data Server 1 are as follows.

<Packet>

<Header Version = "1.0" TOS = "Search">

<TTL> 32 </ TTL>

<Protocol> TelezenSearchWebService_Ver1.0 </ Protocol>

<SrcIP> 61.33.50.1 </ SrcIP>

<DestIP> 61.33.50.4 </ DestIP>

<Ext> Base </ Ext>

<ExtLevel> 0 </ ExtLevel>

<Options> NOOP </ Options>

</ Header>

<Data>

<Request id = "00364322">

<Command> GetImage </ Command>

<ID> jonah </ ID>

<PW> telezen </ PW>

<Code> tlz2003 </ Code>

<Keyword> Doggy </ Keyword>

<Discern> all </ Discern>

</ Request>

</ Data>

</ Packet>

Assuming 61.33.50.1 <-> 61.33.50.2 <-> 61.33.50.3 <-> 61.33.50.4 in the virtual IP structure, a packet departing from 61.33.50.1 arrives at 61.33.50.2. The TOS value of the property of the <Header> tag is "Search", but since the value of the <Ext> tag is "Base", only the routing function is performed. In other words, the <TTL> tag value is reduced by one in the original packet and sent to the 61.33.50.3 server. Thus, when the server receives a packet, the TTL tag is <TTL> 31 </ TTL>. Since the 61.33.50.3 server is not the final search target server, it performs the same operation as the 61.33.50.2 server, and passes the packet to the 61.33.50.4 server. Therefore, when the packet arrives at the 61.33.50.4 server, the TTL value is 30. The 61.33.50.4 server, the final target server for extended search, parses the XML packet in the virtual routing socket module and delivers the entire XML packet to the search engine when the TOS is "Search". The search engine returns the search results back to the 61.33.50.1 server based on the XML packet's Source ID. The reply packet has a structure similar to that of the outgoing packet, and the parts that are different from the outgoing packet are that the TOS property of the Header tag is changed from "Search" to "SendTo", the SourceIP and DestinationIP are changed, and the search result in the <Data> tag Is added. An example of a reply packet is as follows.

<Packet>

<Header Version = "1.0" TOS = "SendTo">

<TTL> 32 </ TTL>

<Protocol> TelezenSearchWebService_Ver1.0 </ Protocol>

<SrcIP> 61.33.50.4 </ SrcIP>

<DestIP> 61.33.50.1 </ DestIP>

<Ext> NOOP </ Ext>

<ExtLevel> 0 </ ExtLevel>

<Options> NOOP </ Options>

</ Header>

<Data>

<Response id = "00364322">

<IMAGE URL = "http://WebtutorNet.telezen.com/Images/a.jpg"

CATEGORY = "2" DISCERN = "image" NAME = "Doggy" />

<IMAGE URL = "http://WebtutorNet.telezen.com/Images/b.jpg"

CATEGORY = "1" DISCERN = "image" NAME = "Genius Joe" />

<IMAGE URL = "http://webtutornet.telezen.com/images/22_000037.JPG"

CATEGORY = "1" DISCERN = "image" NAME = "Cambridge" />

<IMAGE URL = "http://webtutornet.telezen.com/images/22_000038.JPG" CATEGORY = "2" DISCERN = "image" NAME = "Oxford" />

</ Response>

</ Data>

</ Packet>

Meanwhile, after the content retrieval process, the content transmission process is continued. In the XVIP according to the present invention, a transmission process has a direct transmission mode and an indirect transmission mode. The data server receiving the content search packet sends a response packet after searching the content. In this case, the response packet includes a URL including the URL of the searched content and metadata including basic information (the author of the content, the file size, the type of the content, and the like). The client requesting the search is requested to send the searched content to the data server by selecting the content to be finally transmitted based on the search result. In the case of the direct transmission mode, the data server may directly transmit content using the packet structure of the present invention. In other words, data can be sent in binary or text format in the <Data> </ Data> tag of the packet structure. Small picture files or text files can be directly targeted for the transmission mode. In addition, the search process has a simple advantage because it can be transmitted by utilizing the interface in the existing search environment. However, there is a disadvantage that a burden on the server is required to process large data. In contrast, in the indirect transmission mode, when a client selects a required content and requests a data server that owns the content, the data server and the client perform a data transmission using a protocol suitable for each content. The indirect transmission mode is used for a video file requiring streaming transmission or content to be transmitted in a special secure channel.

8 is a flowchart illustrating a method for searching a backward extension according to an embodiment of the present invention. The extended backward search method is an extension of the basic extended search method. Say how to do. Data server 1 receiving the client's request receives the search server target list from the control server and sends the search request packet to each server in the same way as the basic extended search method. The data servers search their databases (S231), search whether the content corresponding to the search word exists in their database (S231), and if so, send a message informing the fact to the transmitting data server (S233). As soon as the final destination database server receives the content request, it transmits the URL of the content to the transmission data server 1. The sending data server organizes the response message received for a certain period of time, and shows a list of contents for the requested search word to the requesting client, and the client performs a content request to each data server.

In the extended backward search, a preferred embodiment for performing a search function using the XVIP according to the present invention will be described. The client assumes that the data server has an environment for separately requesting basic and extended searches. This environment can be fully implemented with current web server technologies such as HTML, ASP, and PHP. As shown in FIG. 8, the data server 1 requests a server list for an extended search in a method of transmitting a keyword of content to a control server while performing a basic search process in response to a client request. When the server list for the requested content is provided from the control server, the data server 1 performs the backward extension search. For example, the data server 4 is included in the list of the provided servers, so that a request for searching for the data server 4 is performed. For example, the virtual IPs of the data servers 1, 2, 3, and 4 are 61.33.50.1, 61.33.50.2, and 61.33. Speaking of 50.3 and 61.33.50.4, the virtual IP packets generated by Data Server 1 are as follows:

<Packet>

<Header Version = "1.0" TOS = "Search">

<TTL> 32 </ TTL>

<Protocol> TelezenSearchWebService_Ver1.0 </ Protocol>

<SrcIP> 61.33.50.1 </ SrcIP>

<DestIP> 61.33.50.4 </ DestIP>

<Ext> Backward </ Ext>

<ExtLevel> 1 </ ExtLevel>

<Options> NOOP </ Options>

</ Header>

<Data>

<Request id = "00364322">

<Command> GetImage </ Command>

<ID> jonah </ ID>

<PW> telezen </ PW>

<Code> tlz2003 </ Code>

<Keyword> Doggy </ Keyword>

<Discern> all </ Discern>

</ Request>

</ Data>

</ Packet>

Assuming 61.33.50.1 <-> 61.33.50.2 <-> 61.33.50.3 <-> 61.33.50.4 in the virtual IP structure, a packet departing from 61.33.50.1 arrives at 61.33.50.2. Since the TOS value of the property of the <Header> tag is "Search", a copy is sent to the search service of the 61.33.50.2 server, and a value of <TTL> tag is reduced from the original packet and sent to the 61.33.50.3 server again. do. Thus, when the server receives a packet, the TTL tag is <TTL> 31 </ TTL>. Since the 61.33.50.3 server is not the final search target server, it performs the same operation as the 61.33.50.2 server, and passes the packet to the 61.33.50.4 server. Therefore, when the packet arrives at the 61.33.50.4 server, the TTL value is 30. Extended Search The final target server, 61.33.50.4, parses the XML packet from the socket and passes the entire XML packet to the search engine when the TOS is "Search". The search engine returns the search results back to the 61.33.50.1 server based on the XML packet's Source ID.

The reply packet has a structure similar to that of the outgoing packet, and the parts that are different from the outgoing packet are that the TOS property of the Header tag is changed from "Search" to "SendTo", the SourceIP and DestinationIP are changed, and the search result in the <Data> tag Is added. An example of a reply packet is as follows.

<Packet>

<Header Version = "1.0" TOS = "SendTo">

<TTL> 32 </ TTL>

<Protocol> TelezenSearchWebService_Ver1.0 </ Protocol>

<SrcIP> 61.33.50.4 </ SrcIP>

<DestIP> 61.33.50.1 </ DestIP>

<Ext> NOOP </ Ext>

<ExtLevel> 0 </ ExtLevel>

<Options> NOOP </ Options>

</ Header>

<Data>

<Response id = "00364322">

<IMAGE URL = "http://WebtutorNet.telezen.com/Images/a.jpg"

CATEGORY = "2" DISCERN = "image" NAME = "Doggy" />

<IMAGE URL = "http://WebtutorNet.telezen.com/Images/b.jpg"

CATEGORY = "1" DISCERN = "image" NAME = "Genius Joe" />

<IMAGE URL = "http://webtutornet.telezen.com/images/22_000037.JPG"

CATEGORY = "1" DISCERN = "image" NAME = "Cambridge" />

<IMAGE URL = "http://webtutornet.telezen.com/images/22_000038.JPG" CATEGORY = "2" DISCERN = "image" NAME = "Oxford" />

</ Response>

</ Data>

</ Packet>

Because of the extended backward search method, the 62.33.50.2 and 61.33.50.3 servers also interpret the packet and send a reply packet to the 61.33.50.1 server if the relevant content exists.

9 is a flowchart illustrating an example of a forward expanded search method according to an embodiment of the present invention. This method applies the multicast method of IPv4. When a data server that has received a content request does not have the requested content, it transmits the content request to another data server directly connected to it. After the requested other data server searches its own database, if there is no content, the other data server can continue to expand the search object by executing a content request to other data servers connected to it. In the forward extended search, a preferred embodiment of performing a search function using the XVIP according to the present invention will be described.

9, after the basic search process, the forward extended search function may be performed according to a user's selection. Whether to perform the forward extended search may be performed by a separate request of the client, on the premise that the environment for allowing the client to separately request the basic search and the extended search is provided in the data server as in the backward extended search function. Assume that XVIP maintains a virtual connection between each server. In FIG. 9, the data server 1 determines whether to perform an extended search. If it is decided to perform the forward extended search function, the data server 1 generates a search packet and performs an extended search against the servers connected to it. At this time, the generated data packet should be configured for forward extended search for the following two fields.

<Ext> Forward </ Ext>

<ExtLevel> 1 </ ExtLevel>

Ext tag can assign three field values, Forward, Backward, Basic, and set forward field value to perform forward extended search function. The ExtLevel field records the value to which the extended forward search function can be extended. Whenever the search range is expanded, the ExtLevel value is decreased by one, and thus the search range is extended by the value recorded in ExtLevel.

10 is an exemplary diagram illustrating a forward extended search step according to the present invention, in which a data server 1 that receives a 3-level forward extended search request of a client sends a search packet to a data server 2, a data server 3, and a data server 4 that are virtually connected. send. At this time, the ExtLevel field value of the search packet is 3. Since the TOS property of the packet is "Search", the data server 2, data server 3, and data server 4 that have received the extended search request perform a search in their database and transmit the result to the data server 1 if there is content of the search result. If no search results are found, no data is sent. As soon as the receive socket of each data server receives the packet, the receive socket subtracts the ExtLevel Field value by one from its original value, and the send socket checks the ExtLevel value and if it is 0, no further extended search packets are sent. Since ExtLevel = 2 at the sending sockets of Data Server 2, Data Server 3, and Data Server 4, the packet is sent to all other servers in its routing table. Data server 2 does not transmit any more because there is no server other than data server 1. Data server 3 sends a packet with ExtLevel = 2 to data server 8 and data server 9. Data server 4 sends a packet with ExtLevel = 2 to data server 5 and data server 6. The data server 5, data server 6, data server 8, and data server 9 that received the packet with ExtLevel = 2 perform the same process as the previous step. That is, the receiving socket subtracts the value of the ExtLevel field by 1, passes the packet to the search service, performs a search operation in its database, and transmits the result packet if there is content, but does not transmit the content. When ExtLevel = 1 when the packet is passed to the send socket, it checks its own routing table and sends the search packet to the server except the sender.

Those skilled in the art to which the present invention pertains will appreciate that the present invention can be implemented in other specific forms without changing the technical spirit or essential features. For example, the above description focuses on the Internet, but the Internet is not limited to the wired Internet but may be applied to the wireless Internet.

Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive. The scope of the present invention is shown by the following claims rather than the detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included in the scope of the present invention. do.

As described above, according to the present invention, it is possible for content consumers on the Internet to access a single site to access data on multiple sites, and content providers can easily and without spending a lot of time and effort in device integration. The content can be shared with other sites, and the environment for searching the scattered contents is also designed to be easily expanded, thereby minimizing the burden of adding a site.

In addition, with a layered protocol structure, a new method can be applied to a previously provided search engine to provide a foundation for enhancing a search function and its effect, and service providers can be combined to provide differentiated services.

Claims (4)

A control server searching for a virtual IP address corresponding to a server search command received through a network, and transmitting the searched virtual IP address to the network; Search for the content according to the content search command received from the client and transmit the content to the client or route the content request signal according to the content search command to the virtual IP address received from the control server through the network; And a plurality of data servers for transmitting the content received from the virtual IP address to the client according to a signal. The method of claim 1, wherein the plurality of data servers A packet receiver configured to receive a packet including the content; Extract destination information of the received packet, and transmit the content to the client if the IP address and its IP address in the destination information are the same; A service splitter for outputting the packet; And And a routing processor for performing virtual routing for transmitting to another data server through the network by destination information of the IP address of the packet inputted from the service splitter. Routing device. The virtual routing apparatus of claim 2, wherein the plurality of data servers comprises a search module for searching whether the content corresponding to the content search request signal is stored. delete