KR20060107014A - A mobile network system consisted of only pda - Google Patents

Abstract

The present invention relates to a network system using a PDA (Personal Digital Assistant), and more particularly, to a network system in which a terminal of a network using a peer-to-peer based integrated middleware consists of only a PDA.

According to the present invention, all the peers belonging to the entire network are composed of only PDAs, and each PDA is an equivalent peer in which an integrated middleware component unique to the present invention is embedded, and each peer is assigned a unique ID and performs management. The B-Server also allows the PDA terminal to perform the communication between the respective terminals through the X-Talk protocol, thereby enabling the construction of a dynamic network system using the PDA.

PDAs, Networks, P2P, Middleware, Components, Applications, Bridging Servers

Description

Network system between PCA terminals {A MOBILE NETWORK SYSTEM CONSISTED OF ONLY PDA}

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.

16 illustrates an embodiment of a mobile network system in accordance with the present invention.

17 schematically illustrates the concept of an extended system according to the present invention.

The present invention relates to a network system using a PDA (Personal Digital Assistant), and more particularly, to a network system in which a terminal of a network using a peer-to-peer based integrated middleware consists of only a PDA.

In order to better understand the technical idea of the present invention, a general approach to basic network configuration and a consideration thereof are required.

In general, networks may be classified as having a client-server (C / S) structure or a peer-to-peer (P2P) structure. In a P2P-based network, 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, if 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. In the case of mobile devices, it is difficult to design integrated middleware to form a sophisticated network.

On the other hand, since PDA is a portable personal information terminal that functions as a small computer, it has an advantage of having its own DB and managing information, and can form a wireless communication network using a communication module such as a wireless LAN. There is a need for a more efficient dynamic network configuration using the same.

SUMMARY OF THE INVENTION The basic object of the present invention is to provide a network system consisting of only PDAs, while performing the functions of both a client and a server on the PDA terminal itself, while each terminal is regarded as the same peer, sharing the database of each terminal. It also aims to implement a network system unique to active and flexible PDA terminals by providing the basic networking technology that various functions such as distribution and free handling of database can be achieved between each terminal.

In addition, another object of the present invention is to enable the server application configured in the PDA to be connected to the web server of another network via the Internet to facilitate the scalability of the network.

In order to achieve the above objectives, first, the need for middleware that can be independently or flexibly combined with a slim legacy solution to a large legacy solution, and secondly, most mobile devices are limited to their role as thin clients. On the other hand, given the anticipated high performance of mobile devices, the complexity and diversity of applications that are foreseen in the future require a more sophisticated development environment. Therefore, developers can easily adapt to such rapid development environment changes while adapting to the market demand level. Third, the middleware as a tool to help the task should be developed to play a role, and the third developed middleware should be considered to have a price advantage over other systems having a concise structure and having a plurality of complex structures.

Still other objects of the present invention will be described below, which is intended to be broader by means of the description and the disclosure of the embodiments of the claims of the present invention, as well as by means and combinations within the range easily conceivable therefrom. It is to be noted that it will be subsumed and will correspond to the unique effects of the present invention.

In order to achieve the above object, the present invention is a peer to peer (Peer to Peer) -based integrated network between the PDA (Personal Digital Assistant) terminal:

N (N is an integer greater than 1) PDA peer terminals;

An integrated middleware component ("X-Talk Component") configured as a component in each PDA peer terminal and divided into a server area including an integrated service resource and a client area performing a network connection and service request process; And

A bridging server PDA terminal, which performs a function of a bridging server (B-Server) which gives a unique peer ID code when a network connection of other PDA peer terminals is performed. It includes, characterized in that the protocol between each PDA peer terminal is formed in the application layer.

The integrated middleware component is connected to the application through an interface,

X-Talk P2P Connector module for transmitting and receiving data packets as a connection module between the PDA peer terminal;

A Packet Parser module for receiving a data packet through the X-Talk P2P Connector module, classifying the data packet and determining a process according to the classification;

Sync for determining the command transmission and data processing method according to the result data of the data packet classified by the Packet Parser module. Coordinator module;

An X-Talk Server module executing a request service of a counterpart PDA peer terminal transmitted from the Packet Parser;

An integrated service library module including contents necessary for executing a request service of a counterpart PDA peer terminal and connected to resources of the peer terminal; And

And a naming module for retrieving information of the other party's PDA peer terminal through the B-Server PDA terminal and assigning a peer ID.

The Sync. Coordinator module decides whether to send Sync or Async.

In the case of a sync transmission, the second client waits until a response is received from the second client until a predetermined waiting time of the first PDA peer terminal. In the case of an Async transmission, the control right is immediately transmitted without waiting after sending a command to the second client. 1 It is desirable to return to the application of the PDA peer terminal.

On the other hand, the B-Server PDA terminal forms a network system based on one peer-to-peer, and when connecting the network formed by another B-Server and the current network, the B-Server PDA terminal is a gateway Plays the role of.

Furthermore, in the present invention, N (N is an integer greater than 1) PDA peer terminals are provided with an integrated middleware component having an integrated service library in advance, and any one PDA terminal among the N PDA peer terminals is provided with each PDA peer terminal. It performs the function of a bridging server (B-Server) that assigns a peer ID code to the authentication and performs authentication. Peer-to-peer is based on a network system where communication between PDA peer terminals is performed through an integrated middleware P2P connector module. As a method for configuring a network system between PDA terminals in a base station:

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

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

Transmitting, by the first PDA peer terminal, a request for a specific service to a second PDA peer terminal which is a destination peer;

Generating, by the second PDA peer terminal, a response to the requested service through its integrated service library, and transmitting the response to the first PDA peer terminal; And

And checking the response received from the second PDA peer terminal by the first PDA peer terminal and notifying the application thereof.

In addition, determining whether the transmission of the request command of the specific service is a Sync transmission or Async transmission; And

In the case of a sync transmission, the second PDA peer terminal waits until a response is received until a predetermined waiting time of the first PDA peer terminal, and in the case of Async transmission, does not wait after transmitting a command to the second PDA peer terminal. And immediately returning control to the application of the first PDA peer terminal.

On the other hand, the request command of the specific service, the first PDA peer terminal to set the third PDA peer terminal as the target peer, the second PDA peer terminal to transmit the resources it has to the third PDA peer terminal Requesting is considered a very important embodiment.

In addition, the integrated service library of the present invention is provided with a unified module for database handling (DB Handling) between PDA peer terminals, access to files stored in peers, or database upgrade, event / message transfer, and file transfer. It may be understood that the application of the first PDA peer terminal selects one or more of those modularized in the integrated service library and calls a specific method.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. However, after presenting a richer description of the integrated middleware of the present invention embedded in the PDA terminals as components, the embodiment of the configuration of the network system of the PDA terminals of the present invention based on the integrated middleware will be described. Shall be. In the following description of the present invention, if 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 creates a base for sharing distributed resources among mobile device peers, and simultaneously integrates P2P function and C / S model function by interworking with Backoffice and modularized integrated service library and integrated resources in components. By using these, each peer defines an integrated middleware unique to the present invention that implements the functions of an integrated server as well as a client element 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 "Class Code" and a maximum of 4096 can be used. "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), which is divided into a server area and a client area to perform a function, the functions in the divided areas are shown in Figure 5 "C + serial number", " S + serial number " On the other hand, when the application 1 is configured as a PDA terminal system, an efficient system at the event event or short-term installation operation, it can be understood as a mobile application that realizes the specific purpose that the system seeks.

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 data and control. 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 the 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. 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 classified 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) to separate threads within 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 partner 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 enhancing the function as a server of each peer by integrating necessary contents, and does not require individual programming for 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 the other peer, search for peer information corresponding to Peer ID before checking from B-Server. to be.

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. Coordinator (3) transmits the information to the X-Talk P2P Connector (9), X-Talk P2P Connector (9) creates an X-Talk Packet and transmits 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 of 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, and the application program that adopts 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 a 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 the Sync. 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, the 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). The X-talk Server 5 calls the corresponding Service Library 6 to respond to the requested service, and the 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). 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 match is completed, calculate whether the transfer of the corresponding file to peer C of peer B made by peer A transfer command is completed (S122). If completed, the file transfer completion signal is transmitted as return data to the X-Talk P2P Connector 9 of the 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 matches the transfer command code, obtains a Notify event code, and notifies the application 1 of peer A of the completion of transfer (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 in recent years, 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).

Fig. 13 shows a function that allows a peer to freely access and read / modify / insert a database. 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

B-Server can forcibly terminate the connection of X-Talk currently connected and can also restrict 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.

16 schematically shows an embodiment of the invention.

All PDA terminals are equipped with the X-Talk component described above in detail, and on top of that, an operational application for implementing the characteristics of the PDA mobile network is configured. In addition, by implementing the function of the B-Server in one specific PDA belonging to the network is responsible for authentication and management of other PDA terminals. The communication module of each terminal may be connected via a wireless LAN, and may be connected by direct wireless communication between the terminals or through the Internet.

For example, peer A sends a message / event to peer B as shown in FIG. 9, and a process of instructing peer A to send data stored in peer B's database to peer C as a target peer is described in detail with reference to FIG. 12. As shown.

Meanwhile, FIG. 17 illustrates system scalability through connection with another network in a PDA-only network system. In this case, the B-Server of the PDA mobile network and the B-Server of another network serve as mutual gateways. Done.

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

As described above, according to the present invention, all of the peers belonging to the entire network are configured with only PDAs, and each PDA is an equivalent peer with an integrated middleware component unique to the present invention, and each ID has a unique ID. The PDA terminal also performs and manages the B-Server which is assigned and manages, and the communication between the respective terminals is performed through the X-Talk protocol, thereby enabling a dynamic network system configuration.

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, and the effect of the present invention is not only the matters described in the above-described embodiments and claims of the present invention, but these It is noted that it will be encompassed by a wider range of potential effects that may occur within a range that can be easily drafted from, and potential advantages that contribute to industrial development.

Claims (8)

A peer-to-peer-based integrated network between PDA (Personal Digital Assistant) terminals: N (N is an integer greater than 1) PDA peer terminals; An integrated middleware component ("X-Talk Component") configured as a component in each PDA peer terminal and divided into a server area including an integrated service resource and a client area performing a network connection and service request process; And A bridging server PDA terminal, which performs a function of a bridging server (B-Server) which gives a unique peer ID code when a network connection of other PDA peer terminals is performed. And a protocol between each PDA peer terminal is formed in the application layer. The method of claim 1, The integrated middleware component is connected to the application through an interface, X-Talk P2P Connector module for transmitting and receiving data packets as a connection module between the PDA peer terminal; A Packet Parser module for receiving a data packet through the X-Talk P2P Connector module, classifying the data packet and determining a process according to the classification; Sync for determining the command transmission and data processing method according to the result data of the data packet classified by the Packet Parser module. Coordinator module; An X-Talk Server module executing a request service of a counterpart PDA peer terminal transmitted from the Packet Parser; An integrated service library module including contents necessary for executing a request service of a counterpart PDA peer terminal and connected to resources of the peer terminal; And And a naming module for retrieving information of a counterpart PDA peer terminal through the B-Server PDA terminal and assigning a peer ID. The method of claim 1, Sync. Coordinator module decides whether to send Sync or Async. In the case of a sync transmission, the second client waits until a response is received from the second client until a predetermined waiting time of the first PDA peer terminal. In the case of an Async transmission, the control right is immediately transmitted without waiting after sending a command to the second client. 1 Network system between PDA terminals to return to PDA peer application. The method of claim 1, The B-Server PDA terminal forms a network system based on one peer to peer, In the case of connecting a network formed by another B-Server and the current network, the B-Server PDA terminal serves as a gateway, network system between PDA terminals. N (N is an integer greater than 1) PDA peer terminals are pre-installed with an integrated middleware component having an integrated service library, and any one of the N PDA peer terminals assigns a peer ID code to each PDA peer terminal. It performs the function of a bridging server (B-Server) that performs authorization and performs authentication. Based on a network system where communication between each PDA peer terminal is performed through an integrated middleware P2P connector module, the PDA terminal is peer-to-peer based. To configure a network system between: Invoking a specific method of an integrated service through an interface via an application of a first PDA peer terminal that is a requesting peer; Accessing the B-Server PDA terminal to obtain a peer ID of a first PDA peer terminal; Transmitting, by the first PDA peer terminal, a request for a specific service to a second PDA peer terminal which is a destination peer; Generating, by the second PDA peer terminal, a response to the requested service through its integrated service library, and transmitting the response to the first PDA peer terminal; And And checking the response received from the second PDA peer terminal by the first PDA peer terminal and notifying the application thereof. The method of claim 5, Determining whether the transmission of the request command of the specific service is a Sync transmission or an Async transmission; And In the case of a sync transmission, the second PDA peer terminal waits until a response is received until a predetermined waiting time of the first PDA peer terminal, and in the case of Async transmission, does not wait after transmitting a command to the second PDA peer terminal. And immediately returning control to the application of the first PDA peer terminal. The method of claim 5, The request for the specific service may include requesting a first PDA peer terminal to set a third PDA peer terminal as a target peer and requesting the second PDA peer terminal to transmit its own resources to the third PDA peer terminal. That is, a network system configuration method between PDA terminals. The method according to any one of claims 5 to 7, The integrated service library is provided with unified modules for database handling (DB Handling) between PDA peer terminals, access to files stored in peers, or database upgrade, event / message transfer, and file transfer. The application of the first PDA peer terminal selects one or more that is modularized in the integrated service library to call a specific method, the network system configuration method between PDA terminals.

Images