KR100698236B1 - A service method with server-client unification network system based on peer to peer - Google Patents

Abstract

The present invention relates to a method of constructing a network on a peer-to-peer basis and implementing a variety of services such as a resource sharing method and messages between peers in the network and providing a service in an integrated manner.

The integrated middleware of the present invention integrates and centralizes services such as event transmission, database handling, update, remote, and streaming as well as transfer of specific files, and implements them in a server area within a peer to enhance the function as a server of each peer and the entire network Device's physical networking method and use because it supports network-based programming, consists of components at the application level, and exchanges information between devices using various OS regardless of wired or wireless. Regardless of the environment, there is an advantage that the system can be constructed, and thus, there is no need to develop a program for the network, and it saves a lot of time and manpower.

Peer-to-Peer, Integrated Middleware, Applications, Components, Authentication, File Transfer, Message Transfer, Event Transfer, Remote, Database Handling

Description

A unified service providing method using server-client integrated network based on peer to peer {A SERVICE METHOD WITH SERVER-CLIENT UNIFICATION NETWORK SYSTEM BASED ON PEER TO PEER}

1 is a diagram showing the basic configuration of a data packet format based on the X-Talk protocol of the present invention.

2 is a diagram schematically showing a packet structure of communication between X-Talk clients (applications with X-Talk components embedded) of the present invention.

3 is a diagram illustrating a schematic configuration for mapping an X-Talk Peer ID and a peer code of the present invention.

4 is a diagram schematically showing a bit structure of a Peer ID code of the present invention.

5 is a schematic structural diagram of an X-Talk component of the present invention.

6 is a view schematically showing the interface structure of the present invention.

7 is a flowchart illustrating a basic Service Request and Reply process in X-Talk as an embodiment of the present invention.

8 is a schematic flow diagram of a process for transmitting Return Event / Return Data from a destination peer B to a source peer A in accordance with an embodiment of the present invention.

FIG. 9 is a flowchart illustrating a schematic process of transmitting an Event / Message from an application of a source peer A to an application of a destination peer B. Referring to FIG.

FIG. 10 is a diagram illustrating a schematic meaning of file transfer according to the present invention when there are three peers.

FIG. 11 is a diagram showing another embodiment of FIG. 10.

FIG. 12 is a flowchart illustrating the overall overall process when the peer A of FIG. 10 wants to instruct the peer B to transfer the file of the peer B to the peer C.

13 is a flow diagram illustrating a schematic process for free database handling between peers.

14 is a configuration diagram showing a schematic configuration of a B-Server of the present invention.

15 is a schematic system configuration view of the present invention from the perspective of a B-Server.

The present invention relates to a method of constructing a network on a peer-to-peer basis and implementing various services such as message sharing and resource sharing between peers in the network.

In general, networks may be classified as having a client-server (C / S) structure or a peer-to-peer (P2P) structure. In P2P-based networks, one device or network node is considered a peer, and each peer may communicate directly with each other, requiring no central network structure, and these peers also cooperate with each other to provide services and services. Since resources are shared with each other, so-called peer-groups are formed. In addition, peers can be connected to or disconnected from the network at any time, can arbitrarily join and leave the system, or can form a dynamic network because peer-groups have the property of being separated or merged. . On the other hand, the network structure of the client-server has the advantage of managing and coordinating the network in an integrated manner, which is useful not only in terms of technology but also in terms of business.

However, in the configuration of these networks, when each server and client has a different communication system or different heterogeneous devices, there is a problem in that a solution for creating a unified communication system is needed, and in particular, heterogeneous devices such as home networks. Is a network device, and if the clients on the network are mobile devices with complexity and diversity of applications, it is difficult to design an integrated middleware to construct a sophisticated network.

In particular, in the coming ubiquitous environment, a unified communication system between heterogeneous heterogeneous systems, easy development, sharing, and deployment of applications should be premised, and the environment in which users can share desired information anytime, anywhere is a specific service between specific devices. However, it should be easier to establish a unified system that each device can understand by breaking up specific protocols. However, if all the solutions are aimed at product development, it is necessary to go further from this broader concept and have economic purpose. The economics here mean that the engineer creating the solution should be able to more easily build a sophisticated network in the shortest amount of time, which inevitably leads to a technical environment.

In the conventional network programming, the development time is long because network functions have to be implemented in consideration of application languages such as C / C ++, Basic, Java, HTML, and XML. This, of course, led to an increase in development costs.

In particular, the language of each client / server application must be considered to construct a network for associating a client / server network model with a peer-to-peer model, as well as information exchange programming or a solution of existing client / server applications and peer-to-peer applications. Therefore, there was a problem in that a new peer-to-peer solution must be re-developed for each network or a specific service to be designed. Furthermore, for the efficiency of the network, each peer in the network should be configured to handle the database between peers remotely. The interface between the background application and the front-end application must be implemented, and each peer must have a background. There was a problem in developing a new DB Handling application.

Moreover, when each peer's device is a mobile device such as a PDA or a mobile phone, the implementation of the basic P2P concept itself was difficult, and not only the human resources required for sophisticated coding were required, Due to the difficulty in standardizing the behavior of the client, it was very difficult to combine the client / server network with the P2P based network in the mobile environment. In addition, the problem of the upgrade of the application of the mobile device client or the remote A / S problem is a problem after the network is configured, so it seems that the problem cannot be solved unless the network configuration is easy. It is designed to be upgraded, but the program of PDA or mobile phone is not easy to upgrade, and it is hard to avoid instability when there are many clients and applied at the same time).

In other words, when configuring a network considering both the flexibility of a P2P network and the integration of a C / S network, it is difficult and inflexible to configure the network, especially when a mobile device is included among a large number of peers in the network. There was a risk of losing money and there was also a problem of economic weakness.

In order to solve the above problems, the inventors have confirmed the following points through a long study, and set this as a basic technical problem. First, there is a need for middleware that can be independently or flexibly combined with slim-sized solutions to large legacy solutions. Second, while most mobile devices are limited to their role as thin clients, the complexity and diversity of applications that are foreseen in the future, given the expected high performance of mobile devices, requires a more sophisticated development environment. Therefore, it is necessary to develop middleware as a tool to help developers adapt to such rapid development environment changes and to adapt to market demands. Third, in order for middleware to be applied to various applications of ISV (Independent Software Vendor) or SI (System Integration) partner, it is essential not to feel the burden in terms of development cost. Therefore, the developed middleware is composed of concise structure, Branches should have a price advantage over other systems.

This technical challenge meets the purpose of making the server-client integrated network more concise on the basis of peer-to-peer based network when the peer, which is a mobile device, is included in the network. Is touching.

Further objects and advantages of the present invention will be described below, which is further broadened by means of the disclosure in the claims and the disclosure of the embodiments thereof, as well as means and combinations within the range readily recited therefrom. It will be added to the scope and will correspond to the unique effects of the present invention.

In order to achieve the above object, the present invention, each peer (Peer) terminal is a pre-installed integrated middleware component having an integrated service library, B-Server to give a peer ID code to each peer terminal and perform authentication Is provided, each peer terminal and the B-Server is characterized in that using a network system to communicate through the integrated middleware P2P Connector module,

Calling a specific method of an integrated service through an interface via an application of a first peer terminal that is a requesting peer;

Accessing the B-Server to obtain a peer ID of a first peer terminal;

Transmitting a request command of a specific service to a second peer terminal in which the first peer terminal is a destination peer;

The second peer terminal creating a response to the requested service through its integrated service library and transmitting the response to the first peer terminal;

And checking, by the first peer terminal, the response received from the second peer terminal, and notifying its application.

The method for providing a unified integrated service through a client-server integrated network on a peer-to-peer basis of the present invention may include: determining whether a transmission of a request command of the specific service is a Sync transmission or an Async transmission; And

In the case of a sync transmission, the second peer terminal waits until a response is received until a predetermined waiting time of the first peer terminal. In the case of an Async transmission, the control right is immediately transmitted without waiting after transmitting a command to the second peer terminal. The method may further include returning to the application of the first client.

In addition, the request command of the specific service, it is very likely that the first peer terminal to set the third peer terminal as the target peer, and to request the second peer terminal to transmit its own resources to the third peer terminal. It establishes itself as a useful embodiment.

In addition, the integrated service library is integrated with a module for database handling (DB Handling) between peer terminals, access to files stored in peers, or database upgrade, event / message transmission, file transfer,

It is preferable that an application of the first peer terminal selects one or more of those modularized in the integrated service library and invokes a specific method.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, when it is determined that the subject matter of the present invention may be unnecessarily obscured as a matter already known to those skilled in the art, such as a known function or a known configuration, the detailed description thereof will be omitted.

1. Definition

As an important term used in the present invention, it provides a base for sharing distributed resources among heterogeneous peers including mobile devices, and integrates P2P functions and C / S models by integrating with Backoffice and modularized integrated services in components. An integrated middleware of the present invention that implements the integrated server function for each peer using libraries and integrated resources is defined as "X-Talk".

2. X-Talk Protocol

Unlike the Client-Server (C / S) system model, which secures critical resources on the server and transmits information and resources according to the client's needs, the peer-to-peer system model is basically any peer computer or device. This is a model to build in an environment where resources are distributed among the fields. Therefore, each peer device must include both client and server components. In addition, each application or service must respond and respond in real time. To this end, we established a new networking infrastructure that facilitates peer-to-peer system building on top of primitive networking.

1 shows the basic configuration of a data packet format based on the X-Talk protocol among peers. The OSI 7 Layer to Transport Layer is TCP / IP based and the actual X-Talk protocol belongs to the application layer. Basically, C / S, P2P or low-level networks are the same. However, it is appropriate to configure a basic communication channel dedicated to X-Talk separately at the application level because it is entirely application related to which model to configure the system based on.

Fig. 2 shows a packet structure of communication between X-Talk clients (applications with X-Talk components), where "Receiver" is a Peer ID for receiving data packets, "Sender" is a Peer ID for sending data packets, "Command" is a service request command, "Check Code for Command-Reply Pair" is a code for checking which command a specific packet received is a response. "Date_NuM" is the number of bytes of sub data, and "Data" is a command. Refers to the actual data involved.

X-Talk Name System, Peer ID, Peer Name

3 shows a schematic configuration for mapping X-Talk Peer ID and peer code. When an X-Talk client connects to a bridging server (hereinafter referred to as "B-Server"), a unique peer ID code mapped one-to-one to a peer ID of a unique string value is obtained from the B-Server. The mapping between Peer ID Code and Peer ID is managed by X-Talk Name System. The application uses the unique Peer ID Code and the Peer ID is used inside the X-Talk client. This is similar to the domain name that can be read when transmitting data in the existing Internet application is translated into the actual IP address through this DNS.

The Peer ID Code is composed of 32 bits and each bit has the same meaning as in FIG. 4. "User Code", "Group Code" and "Class Code" are used to group multiple peer groups, and the maximum number of peers that can be expressed as "User Code" is 256, which means one Group. This group has a maximum of 4096. In addition, a group having a group code as one cell is expressed in a "class code", and a maximum of 4096 pieces are possible. "User Code", "Group Code", and "Class Code" may be appropriately allocated according to the size of peer group and assigned to computers and wired and wireless devices on the Internet.

2. X-Talk Component

5 shows a schematic configuration of an X-Talk component.

The X-Talk component is connected to the application (1) via the interface (2), Sync. Coordinator (3), Packet Parser (4), X-Talk Server (5), Service Library (6), Resources (7), Peer Connection Monitor (8), X-Talk Local Name System (10) and X-Talk P2P Connector (9), divided into server area and client area to perform the function, the functions in the divided area is C + serial number, S + serial in FIG. The numbers are shown with arrows in the description.

Packet Parser (4)

All data packets coming through the X-Talk P2P Connector 9 enter the Packet Parser 4. The classification of packets determines the process to be processed and gives the process control and data. Each packet classification and an embodiment thereof is as follows.

Case 1: Data that comes as a response when a user sends a command to another peer:

When peer A sends a service request command to peer B, peer B sends the processing back to peer A. The result data enters the Packet Parser (4), and upon confirmation as Case 1, Sync. Sent to the Coordinator (3). Sync. Coordinator (3) memorizes all commands sent by peer A, checks whether the result data from Packet Parser (4) is the result of any previously sent command, and notifies Application (1) of the result as appropriate. (Notify)

# Case 2: Data coming from other peers unilaterally pushed or streamed

This is the voice steaming function of X-Talk. Compressed voice data is transmitted from peer B to peer A at regular intervals. In this case, there is no specific command corresponding to the received packet. In other words, because it plays packet received by peer A unilaterally, voice is played in X-Talk Server immediately.

Case 3: data requesting a specific service from another peer

This is the case when peer B requests a specific service from peer A. This includes file transfers, event transfers, message transfers, and DB Handling. The data categorized as Case 3 is sent to the X-Talk Server (5), and X-Talk finds and calls the specific service requested in the Integrated Services Library (6), which is a separate thread (in the X-Talk Server (5)). Thread).

Sync. Coordinator (3)

Sync. Coordinate (3) is a part of Sync / Async processing of X-Talk command. When the command performs Sync or Async operation, it means that the application 1 is notified of the counterpart's processing result, which directly affects the application design.

In X-Talk, there are basically two types of service request commands to the peer. One is to send a command and wait for a response from the other peer (the peer that sent the command is in Block state, and you can set a time limit, so if the response does not come for a specified time, the Block state is released and Fail Notify And the other is the case of returning to the application 1 directly without waiting for the result data after transmission. The former is Sync. Called Command and the latter Async. Called Command. The former use is mainly used when there is no reason to proceed with Application (1) without receiving the result. The latter is mainly used when the application 1 waits more than necessary if the service requested by the peer takes a long time to complete.

The detailed process from command transmission to result data processing is as follows.

-Sync. Command

Peer A syncs service request data. Send to Coordinator (3). Coordinator (3) assigns a unique key to the command and stores it in memory. After transmitting the command packet, it waits for the result data to be classified from the packet parser 4. When the result data comes from the Packet Parser 4, it is checked whether the Key included therein exists among the keys stored before the command transmission, and then the control right is returned to the application 1. If data does not come from the Packet Parser 4 within a predetermined time, it declares time out and notifies the application 1 of fail.

Async. Command

When Peer A requests service request data, the Sync. Send to Coordinator (3). Sync. The coordinator (3) also stores the key unique to the command and the event code sent from the application (1) in memory. After sending to the peer, it returns immediately to the application 1 without waiting. After that, when the result data comes from the packet parser 4, it is checked whether the key included therein is present among the keys stored before the command transmission, and the application 1 is notified of the stored event code.

 X-Talk Server (5)

This is a process to execute the service requested by the peer. A separate processing thread is created for each service, and the result data is also returned to the request peer through the individually created channel. X-Talk Server (5) itself is an execution environment and the code corresponding to the actual service is taken from the integrated service library (6) and executed.

Service Library (6)

The integrated service library 6 of the present invention is a place that contains contents necessary when a peer serves as a server, that is, when a peer performs a service requested. This includes routines such as file information service, file transfer service, peer management service, audio / video processing, DB transaction, resources management service, message and event processing, etc. In a conventional network, each peer performs only one of the routines. In contrast, the integrated service library 6 of the present invention unifies the various services by strengthening the functions as a server of the peer by integrating the necessary contents, and does not require individual programming for the individual services.

Resources (7)

The integrated resource 7 is all the resources that the peer can manage / control. This includes computers running peers, mobile phones, PDAs, embedded system files, databases, multimedia content, I / O peripherals, and so on.

 X-Talk Local Name System (10)

Receive peer information belonging to one B-Server from B-Server and keep it on its own. When checking the information of other peer, give peer code corresponding to Peer ID by searching first before checking from B-Server. System.

X-Talk Component Interface (2)

X-Talk is implemented to have different components and interfaces according to the platform, and FIG. 6 schematically illustrates this. X-Talk components are implemented in the form of COM (Component Object Model) for Microsoft's Win 98 / NT / 2000 / XP and Pocket PC / Win CE.Net platforms. In the case of a system with resources, components were configured based on the Java 2 Platform Micro Edition (J2ME) to construct a Java Virtual Machine (Java VM) environment. The Mobile Information Device Profile (MIDP) / Connected Limited Device Configuration (CLDC) is a core element of J2ME and provides the core application functions required by mobile applications in the same form as the standard Java runtime environment.

Date Communication & Collaboration between two X-Talk peers

Describes Date Communication and Collaboration with Peer B based on Peer A. Regardless of the platform on which X-Talk runs, data communication and collaboration between peers is the same.

The basic Service Request and Reply mechanism in X-Talk is:

Referring to FIG. 7, when describing a request for a specific service or sending an event / message to peer B, that is, when peer A operates as a client, first, the method of interface 2 is called from applications 1 (S11). ). Next, Sync. Coordinator (3) obtains the Peer ID corresponding to the Peer Name designated by the application (1) by requesting the X-Talk Name System (S12), Sync. When the coordinator 3 transmits the information to the X-Talk P2P Connector 9, the X-Talk P2P Connector 9 creates an X-Talk Packet and transmits it to the designated destination Peer ID (S13). The contents of the service requested by peer A to peer B are in the command of the X-Talk Data Packet, and the related information is in the data.

Sync. Coordinator (3) has a different operation depending on whether the application (1) wants to send a sync or Async (S14). If it is a Sync transmission, it waits without ending the routine until a response is received from the destination peer. In other words, Application (1) will not be able to perform other actions until a response is received. However, if there is no response from the destination peer for a specified period of time, for example t> t _o (t _o is a predetermined wait time), control is returned to the application (1) with an error code. This Sync transfer process is used when it is necessary to check in real time whether a Message / Event transmission or a specific service request is delivered to the destination peer. On the other hand, the Asyn transmission process sends an Event / Message / Service Request to the destination peer immediately after Sync. Coordinator (3) returns control to the application (1) of the source peer A. In other words, the application 1 of the peer A can return to the control right after the call to the interface 2, and thus can perform other tasks.

8 schematically illustrates a flow for transmitting Return Event / Return Data from a destination peer B to a source peer A. FIG. After the transmitted Event / Message / Service Request arrives at the destination peer B (S21), the destination peer B transmits Return Event / Return Data to the source peer A again (S22). When peer A receives Return Event / Return Data, it checks with Check Code for Command-Reply Pair to see which Event / Message / Service Request is Return Event / Return Data (S23), and then the corresponding Application (1). A notification is made to (S24).

All of the functionalities provided by X-Talk above operate according to the flow described above, and this operating system is closely coupled with the X-Talk protocol. Hereinafter, a detailed process performed under the X-Talk protocol will be described in detail.

① Event / Message transmission

FIG. 9 shows a process for transmitting an Event / Message from the application 1 of the source peer A to the application 1 of the destination peer B. FIG.

First, the interface 2 and Sync. The process of arriving at the packet parser (4) via the coordinator (3) via the peer A's X-talk P2P connector (9) and peer B's X-talk P2P connector (9) starts from step S31 and proceeds to step S38. Is done through. Next, in the packet parser 4 of peer B, data transmission is performed in two directions. One is to notify the application of the Event / Message through the interface of the peer B (S38, S39), the other is to send a return signal that the Event / Message has arrived to the peer A (S40). Meanwhile, the return signal transmission process is finally notified to the application 1 of the peer A through S40 (S41 to S43). By using the above functions, real-time text and events can be exchanged between mobile phone, PDA, PC, and Embedded System. It is an application program that adopts them, and it can monitor and remotely monitor the status of messenger and control devices between real-time devices.

② File transfer

In order to disclose the preferred embodiment of file transfer in X-Talk, we assume three peers involved. In other words, you specify that Peer A sends specific files on Peer B to Peer C. This gives you more flexibility than FTP, which means you can only transfer files from your peer to the peer. For example, a peer device in a network with a small network bandwidth, such as a cell phone or PDA, can control large file transfers between two other peers.

FIG. 10 illustrates a case where three peers are divided into an order peer, a source peer, and a target peer, respectively. When a peer A, an order peer, instructs peer B, a source peer, to transmit a specific file with peer C as a target, FIG. In this case, peer B actually transmits the specific file to peer C, the target peer. FIG. 11 illustrates a case in which the order peer and the source peer are the same peer, unlike the mechanism, and peer A, which commands file transfer, transfers its file to peer C, which is a target peer.

FIG. 12 illustrates the flow in which peer A in FIG. 10 instructs peer B to transfer a file of peer B to peer C in more detail (peer A: order peer, peer B: source peer, peer). C: target Peer)

In the application A of peer A, the file transfer method of interface 2 is called (S101). Interface (2) receives the file transfer call command of the Application (1) and sync it. Coordinator (3) to pass (S102), Sync. The coordinator 3 inquires of the X-Talk Name System 10 to obtain the actual Peer ID of the peer B name received from the application 1 (S103). Next, it transmits to the X-talk P2P Connector (9). The transmission method is Peer B as the source peer, requesting the file transfer service to Peer C as the target peer, and then receiving control again. Since there is a need to perform the Asyn transmission method will be (S104). When the transmission command is completed, the application 1 is notified of the completion (S105 to S105 ″).

Next, a process from peer A to peer B is initiated by transmitting a command packet (S106) to peer B's X-talk P2P connector 9 via peer A's X-talk P2P connector 9. The peer B's X-talk P2P connector 9 forwards the command packet to the Packet Parser 4 (S107), and the Packet Parser 4 checks the command included in the Packet and the X-Talk Server (5). Transfer to (S108). X-talk Server (5) calls the corresponding Service Library (6) to respond to the requested service, and Service Library (6) uses the resource (7) of its own to perform the requested work from peer A (S109). In this case, since the specific file of peer B is transmitted to peer C, peer B's X-Talk Server (5) creates a new process and enters a state to respond to another service request. In other words, the file transfer takes time until the task itself completes the transfer, so create a new process for the task and leave it there and the X-Talk Server (5) itself goes to a waiting state for service requests from other peers. . This is a method of efficiently using the peer B CPU. The newly created file transfer process transfers the file segment to peer C in the background (a file segment is file data that is broken up into large units of specific size).

In order to prepare for transmission to peer C, the peer B's X-Talk Server (5) is the Sync. Coordinator 3 is requested to transmit the file segment (S110), the Sync. Coordinator (3) will deliver the file segment to the X-Talk P2P Connector (9) (S111).

Next, the file segment enters the peer C's X-Talk P2P connector 9 via peer B's X-Talk P2P connector 9 (S112). After arriving at the Packet Parser 4 (S113), the command sent by the peer B is interpreted and sent to the X-Talk Server 5 (S114). Peer C's X-Talk Server (5) recognizes that the service request sent by Peer B should store the data sent with the command as a file in its specific directory, and calls SaveFileData from its Service Library (6). To store (S115). On the other hand, peer B's X-Talk Server 5 and peer C's X-Talk Server 5 both receive service requests from peer A and peer B, but their contents are different. Peer B's X-Talk Server (5) breaks the files in Peer B's directory into peer C segments sent by Peer A to Peer C. Peer C's X-Talk Server (5) sends files sent by Peer B The segment is stored in the directory specified by peer B.

If all of the file segments have been transmitted, the X-Talk Server 5 requests the Packet Parser 4 to transmit a storage completion signal to the peer B (S116), and the Packet Parser 4 receives the segment storage completion signal. To the X-Talk P2P Connector 9 (S117).

In this way, when all files are sent, Peer B sends a completion signal to Peer A. To this end, the X-Talk P2P Connector 9 of peer C first transmits the return data of the storage completion signal to the X-Talk P2P Connector 9 of peer B (S118), and the X-Talk P2P Connector of peer B ( 9) transmits it to the packet parser 4 of peer B (S119), and the packet parser 4 parses the received return data and then transmits it to its Sync. If the transfer to the Coordinator (3) (S120), Sync. Coordinator (3) checks whether the return data and the transmission command code match and transmits to the X-Talk Server (5) (S121).

Since the file is currently transmitted in segments, it is necessary to calculate whether the entire file has been transferred to peer C. Therefore, the X-Talk Server 5 returns the return data and the transfer command code through S121. After checking whether or not the matching is completed, the operation is calculated whether all the transfers of the corresponding file to the peer C of the peer B made by the transfer command of the peer A are completed (S122). If not, the process starts again from the step S109. When it is completed, the file transfer completion signal is transmitted as return data to the X-Talk P2P Connector 9 of peer A via the Packet Parser 4 and the X-Talk P2P Connector 9 (S123, S124, S125). Peer A's X-Talk P2P Connector 9 sends the received return data to its Sync. Transfer to Coordinator (3) (S126), Sync. The coordinator (3) checks whether the return data of the file transfer completion and the transfer command code match, acquires a Notify event code, and notifies the application 1 of the peer A of the transfer completion (S127, S128). It is over.

When peer A transfers its file to peer B, it is as if peer A tells peer A to transfer peer A's file to peer B. All transfers are the same as above. That is, order peer: A, source peer: A, target peer: B.

③ DB Access

In the area where P2P model is applied, resources are distributed evenly among various computers or devices, so each related device must have both server and client in order to utilize each other's resources. Resource refers to files held by each peer, other physical devices connected to the device, and, above all, a database, so sharing a database is an important part of the function of a peer to peer. Occupies.

Most DB's have large capacity of CPU and hard disk, but recently, CPU and storage devices of PDAs and mobile phones are rapidly becoming highly functional and large-capacity, so these mobile devices have their own DB. The DB Access described here means that the peers must not only be free in accessing the peer peer's DB, but also be able to provide services without affecting the work of the peer. This means that even mobile devices must implement a background service (demon process).

In Fig. 13, the functions of freely accessing and reading / modifying / inserting a database between peers are shown. Although the flow from step S131 to step S148 is not significantly different from the above embodiments of ① and ②, unlike the transmission of the file in the resource 7 of the peer of the peer, the flow is stored in the resource of the peer B through S140 and S141. Accesses and reads or modifies the database. That is, the embodiment of FIG. 13 is a flow when peer A reads data of peer B's DB or adds / delete / modifies specific data to peer B's DB. It also describes the processing of data to be processed in units of work (transaction units) rather than in units of records.

In other words, the ExecuteSQL method of Interface (2) is called from Application (1) of peer A. Sync. Coordinator (3) requests X-Talk Name System (10) to get Peer B ID. Next, the command packet is transmitted to the X-Talk P2P connector (9), and is delivered to the packet parser (4) via the peer B's X-Talk P2P connector (9), and the packet parser (4) receives the received packet. Confirm that it is a service request and pass it to the X-Talk Server (5). The X-Talk Server (5) recognizes that the request service is a SQL statement execution, and calls and executes an appropriate function among the Service Library of the Service Library (6). The execution result is the result data of the requested records and returns it to peer A.

On the other hand, in case of transaction unit data update, Application (1) bundles several SQL statements into one packet. This is because multiple SQL statements to be processed must not be processed individually, but must all be executed one-time. In other words, multiple sql statements are processed in one command of X-Talk to ensure data integrity.

3. Bridging Server

Fig. 14 shows a schematic configuration of the B-Server of the present invention, and the main configuration thereof is the Common Service Library (10), the X-Talk Gateway (20), the Manager of Peer Session Resources (40), and the Authentication Process (70). It includes.

X-Talk Gateway (20)

The B-Server forms an X-Talk Network with its peers. In order to connect to the X-Talk Network formed by another B-Server, the related B-Servers must act as a gateway to each other. In addition to the common service for its peers, the B-Server also acts as a gateway.

Manager of Peer Session Resources (40)

This element includes Shared Resources and Locking Resources. Shared resources correspond to both resources managed by the B-Server and resources belonging to each peer. When multiple peers try to use a resource belonging to a specific peer at the same time, this resource is called Shared Resources (50). At this time, it is necessary to provide a control system in order to control the peer without using polluting the shared resources in a normal procedure, which is achieved through the Locking Resources (60) included in the Manager of Peer Session Resources (40).

Common Service Library (10)

In addition to the services that can be established between peers among X-Talk services, there are services that must be composed of 1: N (N is an integer greater than 1) or N: 1. In this case, the B-server has no choice but to participate in the service. The library related to processing is the Common Service Library. This is usually the case when a particular peer is a service that sends messages or events to multiple peers at the same time.

Authentication Process (70)

To participate in X-Talk, a peer must first authenticate and connect to a B-Server. In addition to authentication, B-Server performs basic services for peers such as registering new peers and setting permission levels.

FIG. 15 schematically illustrates a structure in which heterogeneous device peers form a network via a B-Server in a network in which a C / S scheme and a P2P scheme are converged. In this structure, the B-Server performs interaction with the X-Talk Component described above.

Interaction between B-Server and X-Talk Component

All X-Talk components can be used after connecting to the B-Server. The main functions of B-Server in X-Talk network are shown in Table 1 below.

TABLE 1

1. Registration and Information Management of New X-Talk Client 2. Authentication for X-Talk connection 3. Monitor and control the status of the connected X-Talk 4. Ability to share / control resources of connected X-Talks 5. Gateway function to connect from one X-Talk network to another X-Talk network

① Registration and information management of new X-Talk client

Before using X-Talk, you must create and use an account for a new X-Talk client on the B-Server. When an account is created, detailed information related to network and accessor such as hostname, IP, OS type (platform type), shared directory, and alias is stored in the database of B-Server. It also stores information about peer groups, account permissions, and friend settings between X-Talk parties.

② Authentication for X-Talk Connection

Every X-Talk has only one X-Talk network session assigned to one X-Talk ID. That is, if an X-Talk is using a specific ID, no other X-Talk can use the same ID.

③ Monitoring and control status of connected X-Talk

The B-Server can forcibly terminate the connection of the currently connected X-Talk and limit the use.

④ Ability to share / control resources of connected X-Talks

X-Talk network with multiple peers provides the ability to obtain the exclusive right of resource use in sharing resources with each other and release the right after use to other X-Talk. For example, if Peer A is transferring a file to Peer B, when another Peer C tries to create a file of the same name as Peer B, it needs to give Peer A permission to use it safely until the end of the transfer to Peer B. Do. As another example, when peer A is sending a sequential control signal to peer B's I / O device, peer s should be sent to peer A if the sequential control signal should not be interrupted by another peer. There must be a function to give monopoly rights to I / O, and this function is performed by the B-Server.

Peer A may register a string representing the exclusive authority with the B-Server in real time. If another peer, peer B, wants to use the resources currently used by peer A, first ask the B-Server if the resources specified by peer A are currently available. If the result of the inquiry is OK (in fact, the result of the inquiry will be sent by locking for the inquiring peer at the same time as the OK signal). If the result is not OK, it means that another peer is currently in use. do. If configured in this way, participating applications (applications including X-Talk Component) can use each peer resource securely by mutual promise, and B-Server manages this process.

⑤ Gateway function to connect from one X-Talk network to another X-Talk network

One B-Server composes one X-Talk network. Therefore, when there are multiple B-Servers, that is, when there are multiple X-Talk networks, it serves as a gateway to connect peers belonging to different X-Talk networks.

The above embodiments are merely for illustrating the present invention, and the protection scope of the present invention is not limited by these embodiments.

According to the present invention described in detail above, by adopting a P2P network, not only can effectively utilize the resources distributed to each peer, but also the server area as well as the client area in the integrated middleware component implemented in each peer's device. The advantage of being able to manage the whole system collectively by allowing the B-Server to manage the network connection of each peer while allowing the process of sending and receiving resources between each peer while configuring the zone. There is this.

In addition, the network configuration can be remotely handled between peers, or a file stored in another peer can be transferred to another peer, thereby providing high flexibility in network configuration. Each peer stores data stored on its own. Even if it is not a file or a file, it can control the resources of other peers, so even if each peer is a mobile device rather than a PC, there is no obstacle in networking, and also a useful effect that upgrades and A / S can be done voluntarily among peers. There is.

In addition, since Sync & Async Mode can be supported, each peer can perform an effective task according to the characteristics or characteristics of the service required in the network.

Above all, the integrated middleware of the present invention consolidates and centralizes services such as event transmission, database handling, update, remote, and streaming as well as transfer specific files, and implements them in the server area within the peer to enhance the functions of each peer as a server. Increase the flexibility of the entire network, support network-based programming, configure components at the application level, and exchange information between devices using various operating systems, whether wired or wireless, using the same application interface. However, there is an advantage that the system can be built regardless of the use environment, and thus, there is no need to develop a program for the network separately, and it saves the number of people and time to be developed.

Furthermore, an independent management server (B-Server) is provided to support the component environment of the present invention so that a web server such as IIS or other server is not required for operation.

In addition, the unique effects generated by the peculiar constitution of the present invention can be easily estimated in the range described in the constitution of the present invention. It is noted that the scope will be encompassed by a wider range of potential effects that may occur within a range that can easily be derived from, and potential advantages that contribute to industrial development.

Claims (4)

Each peer terminal is provided with an integrated middleware component having an integrated service library in advance, and is provided with a B-Server which performs peer authentication and assigns a peer ID code to each peer terminal. As a method for providing a unified integrated service through a client-server integrated network on a peer-to-peer basis using a network system communicating through an integrated middleware P2P connector module: Calling a specific method of an integrated service through an interface via an application of a first peer terminal that is a requesting peer; Accessing the B-Server to obtain a peer ID of a first peer terminal; Transmitting a request command of a specific service to a second peer terminal in which the first peer terminal is a destination peer; It is determined whether the transmission of the request command of the specific service is a Sync transmission or an Async transmission. In the case of Sync transmission, the second peer terminal waits until a response is received until a predetermined waiting time of the first peer terminal. In the case of the step of returning the control right to the application of the first client without waiting after sending a command to the second peer terminal; The second peer terminal creating a response to the requested service through its integrated service library and transmitting the response to the first peer terminal; And Checking, by the first peer terminal, a response received from the second peer terminal, and notifying its application of the second peer terminal; The request for the specific service is characterized in that the first peer terminal sets the third peer terminal as the target peer, and requests the second peer terminal to transmit its own resources to the third peer terminal. , A method for providing unified integrated service through client-server integrated network on a peer-to-peer basis. delete delete The method of claim 1, The integrated service library is integrated with modules for database handling (DB Handling) between peer terminals, access to files stored in peers, or database upgrade, event / message transfer, file transfer, The method of claim 1, wherein the application of the first peer terminal selects one or more that is modularized in the integrated service library to call a specific method.

Images