KR100698234B1 - 피어 투 피어 기반에서의 서버-클라이언트 통합 네트워크시스템 - Google Patents

Abstract

본 발명은 피어 투 피어 기반에서의 네트워크의 구성 및 그 네트워크에서의 피어들간의 자원 공유방법과 메시지 등의 각종 서비스를 구현하는 시스템에 관한 것이다.

본 발명은 P2P방식의 네트워크를 채용함으로써 기본적으로 각 피어들로 분산된 자원을 효과적으로 활용할 수 있을 뿐만 아니라, 각 피어들의 디바이스의 어플리케이션 계층에 구현되어 있는 통합 미들웨어 컴포넌트에 클라이언트 영역뿐만 아니라 서버 영역을 구성하면서 각각의 피어들간에 자원의 송수신 프로세스가 클라이언트-서버간의 그것과 같은 특징을 갖도록 하는 한편, 각 피어들의 네트워크 접속을 B-Server가 관리하도록 함으로써 전체 시스템을 통합적으로 관리할 수 있는 장점이 있다. 또한, 피어 상호 간에 분산되어 있는 데이터베이스를 원격에서 핸들링하거나, 다른 피어에 저장되어 있는 파일을 또 다른 피어에게 전송할 수 있도록 함으로써 네트워크 구성에 있어 높은 유연성을 구현하며, 각 피어는 자신에 저장되어 있는 데이터나 파일이 아니더라도 다른 피어에게 있는 자원을 컨트롤하게 되고, 또한 업그레이드와 A/S가 피어들 상호 간에 자발적으로 이루어지도록 구성된다.

피어 투 피어, 통합 미들웨어, 어플리케이션, 컴포넌트, 인증, 파일 전송, 메시지 전송, 이벤트 전송, 원격, 데이터베이스 핸들링, 네트워크

Description

피어 투 피어 기반에서의 서버-클라이언트 통합 네트워크 시스템{A SERVER-CLIENT UNIFICATION NETWORK SYSTEM BASED ON PEER TO PEER}

도 1은 본 발명의 X-Talk 프로토콜 기반의 데이터 패킷 포맷의 기본적인 구성을 나타내는 도면이다.

도 2는 본 발명의 X-Talk 클라이언트(X-Talk 컴포넌트를 내장한 어플리케이션) 간에 이루어지는 통신의 패킷 구조를 개략적으로 나타낸 도면이다.

도 3은 본 발명의 X-Talk Peer ID와 피어 Code의 매핑에 대한 개략적인 구성을 나타낸 도면이다.

도 4는 본 발명의 Peer ID Code의 비트구성을 개략적으로 나타낸 도면이다.

도 5는 본 발명의 X-Talk 컴포넌트의 개략적인 구성도이다.

도 6은 본 발명의 인터페이스 구조를 개략적으로 나타낸 도면이다.

도 7은 본 발명의 일 실시예로서 X-Talk에서의 기본 Service Request and Reply 프로세스를 나타낸 플로우도이다.

도 8은 본 발명의 실시예에 따라 목적지 피어 B로부터 출발지 피어 A에게로 Return Event/Return Data를 전송하는 프로세스에 대한 개략적인 플로우도이다.

도 9는 출발지 피어 A의 어플리케이션에서 목적지 피어 B의 어플리케이션으로 Event/Message를 전송할 때의 개략적인 과정에 대한 플로우도이다.

도 10은 세 개의 피어가 있는 경우의 본 발명에 따른 파일 전송의 개략적인 의미를 나타낸 도면이다.

도 11은 위 도 10의 다른 실시형태를 나타낸 도면이다.

도 12는 위 도 10의 피어 A에서 피어 B에 명령하여 피어 B의 file을 피어 C에 전송하고자 할 때의 개략적인 전체 프로세스를 나타낸 플로우도이다.

도 13은 피어 상호 간에 자유로운 Database 핸들링에 관한 개략적인 프로세스를 나타낸 플로우도이다

도 14는 본 발명의 B-Server의 개략적인 구성을 나타낸 구성도이다.

도 15는 본 발명을 B-Server의 관점에서 바라본 개략적인 시스템 구성도이다.

본 발명은 피어 투 피어 기반에서의 네트워크의 구성 및 그 네트워크에서의 피어들간의 자원 공유방법과 메시지 등의 각종 서비스를 구현하는 시스템에 관한 것이다.

일반적으로 네트워크들은 클라이언트-서버(C/S) 구조나 피어-투-피어(P2P) 구조를 갖는 것으로 분류될 수 있다. P2P 기반의 네트워크에서, 하나의 디바이스 또는 네트워크 노드(node)는 피어(peer)로 간주되며, 각 피어들은 서로 직접 통신할 수도 있어 중앙 네트워크 구조가 요구되지 않으며, 이들 피어들은 또한 서로 협 조하여 서비스와 자원을 서로 공유하므로, 소위 말하는 피어-그룹을 형성한다. 또한, 피어들은 어느 때나 네트워크에 연결될 수 있거나 네트워크로부터 분리될 수 있으며, 그 시스템에 임의로 결합하기도 하고 탈퇴하기도 하며, 또는 피어-그룹들은 분리되거나 합쳐지는 특성을 갖기 때문에 다이내믹한 네트워크를 형성할 수 있다. 반면에 클라이언트-서버의 네트워크 구조는 네트워크를 통합적으로 관리, 조정할 수 있는 장점이 있으며, 이러한 장점은 기술적인 면뿐만 아니라 비즈니스 관점에서는 유용하게 활용된다.

그런데 이러한 네트워크들의 구성에 있어서, 각 서버와 클라이언트들이 다른 통신체계를 갖고 있다거나 서로 다른 이기종 디바이스인 경우에는 통일된 통신 체계를 만들기 위한 솔루션이 필요하다는 문제점이 있으며, 특히 홈네트워크 등 상이한 이기종의 디바이스들이 네트워크로 관련되는 경우와 네트워크상의 클라이언트들이 어플리케이션의 복잡성과 다양성을 갖고 있는 모바일 디바이스인 경우에는 통합 미들웨어를 설계하여 정교한 네트워크를 구성하는 데 어려움이 있다.

특히 도래하는 유비쿼터스(Ubiquitous) 환경에서는 이기종 간의 통일된 통신체계, 응용프로그램의 쉬운 개발, 공유, 배치가 전제되어야 하고, 언제 어디서나 원하는 정보를 공유할 수 있다는 사용환경은 기존의 특정한 디바이스들간의 특정한 서비스, 특정한 프로토콜을 해체하여 각 디바이스가 이해할 수 있는 통일된 체계 확립이 보다 용이하게 제공되어야 한다. 그런데 모든 솔루션이 그러하듯 제품개발까지를 목표로 한다면 이러한 광범위한 개념에서 한발 더 나아가 경제적인 면에서 합목적성을 가져야 하는 것은 필수조건이다. 여기에서 말하는 경제적인 면이라 함 은 솔루션을 제작하는 기술자가 가장 짧은 시간 내에 정교한 네트워크를 보다 용이하게 제작할 수 있어야 함을 의미하기 때문에 이는 곧 기술적인 환경과 결부될 수밖에 없다.

종래의 네트워크 프로그래밍은 C/C++, Basic, Java, HTML, XML 등 어플리케이션의 언어를 각각 고려하여 Network Function을 구현하여야 했기 때문에 개발시간이 길어지는 문제점이 있었다. 물론 이는 개발 코스트의 증가를 초래하였다.

특히 클라이언트/서버 네트워크 모델과 피어 투 피어 모델을 결부시키기 위한 네트워크를 구성하기 위해서도 각각의 클라이언트/서버 어플리케이션의 언어를 고려해야 함과 아울러 기존의 클라이언트/서버 어플리케이션과 피어 투 피어 어플리케이션의 정보교환 프로그래밍 또는 솔루션이 필요하였으며, 따라서 설계하고자 하는 네트워크마다 또는 특정 서비스마다 각각 새로운 피어 투 피어 솔루션을 다시 개발하여야 하는 문제점이 있었다. 나아가 네트워크의 효율성을 위하여 네트워크 내에서의 각 피어들은 피어들 상호 간의 데이터베이스를 원격에서 핸들링할 수 있도록 구성되어야 하는데, Background 어플리케이션과 Front-end 어플리케이션과의 인터페이스를 구현하여야 하며, 이때 각 피어들 마다 Background DB Handling 어플리케이션을 새롭게 개발하여야 하는 문제점이 있었다.

더욱이 각 피어의 디바이스가 PDA나 휴대폰과 같은 모바일 디바이스인 경우에는, 기본적인 P2P 개념 구현 자체가 어려웠으며, 정교한 코딩에 수반되는 인력자원이 막대하게 요구되었을 뿐만 아니라 각각의 피어의 디바이스가 운전되는 OS에서의 동작 표준화에 어려움이 있었기 때문에, 모바일 환경에서 P2P 기반의 네트워크 에 클라이언트/서버 네트워크를 결합한다는 것은 대단히 곤란한 문제였다. 또한, 모바일 디바이스 클라이언트의 어플리케이션의 업그레이드의 문제 또는 원격 A/S의 문제는 네트워크가 구성된 이후의 문제이기 때문에 네트워크 구성이 용이하지 않은 이상 해결될 수 없는 문제로 보였다(물론 종래의 업그레이드는 FTP를 통해 업그레이드할 수 있도록 제작되었으나, PDA나 휴대폰의 프로그램은 업그레이드가 용이하지 않을 뿐만 아니라, Client가 다수이고 동시에 적용하는 경우에는 불안정성을 면하기 힘들다).

즉 P2P 네트워크의 유연성과 C/S 네트워크의 통합성을 모두 고려하면서 네트워크를 구성하는 경우에, 특히 네트워크 내의 다수의 피어들 중 모바일 디바이스가 포함되는 경우에는 네트워크 구성의 정교함을 기하기가 어렵고 오히려 유연성을 잃을 위험이 있으며, 또한 경제적인 취약함을 낳는 문제점이 있었다.

위와 같은 문제점을 해결하기 위하여, 본 발명가는 다음과 같은 점을 오랜 연구를 통해 확인하였으며, 이를 기본적인 기술적 과제로 설정하였다. 첫째 Slim-Sized Solution에서부터 Large Legacy Solution에 독립적으로 혹은 유연하게 결합될 수 있는 미들웨어(Middleware)가 필요하다는 것이다. 둘째 대부분의 모바일 디바이스가 Thin Client로서의 역할에 한정되어 있는데 반해, 향후 예상되는 모바일 디바이스의 고성능화를 고려할 때 미리 예견되는 어플리케이션의 복잡성과 다양성은 보다 정교한 개발환경을 요구한다. 이에 개발자가 이러한 급속한 개발환경 변화에 쉽게 적응하면서도 시장에서의 요구수준에 적응하는 것을 돕는 도구로서의 미들 웨어가 역할을 하도록 개발해야 한다는 것이다. 셋째 미들웨어가 ISV(Independent Software Vendor)나 SI(System Integration) Partner의 다양한 어플리케이션에 적용되기 위해서는 개발 코스트 측면에서 부담을 느끼지 않도록 하는 게 필수이므로, 개발된 미들웨어는 간결한 구조로 구성되어 다수의 복합 구조를 가지는 여타의 시스템에 비하여 가격적인 장점을 가져야 한다는 것이다.

이러한 기술적 과제는 모바일 디바이스인 피어가 네트워크에 포함된 경우에 피어 투 피어 기반에서의 서버-클라이언트 통합 네트워크를 더욱 간결하게 구성할 수 있음과 아울러 네트워크 구성의 유연성 및 다양한 응용성을 높여야 한다는 목적에 맞닿아 있다.

본 발명의 또 다른 목적 및 장점들은 하기에 설명될 것이며, 이는 본 발명의 청구범위에 기재된 사항 및 그 실시예의 개시내용뿐만 아니라, 이들로부터 용이하게 추고 할 수 있는 범위 내의 수단 및 조합에 의해 더욱 넓은 범위로 포섭될 것이며, 본 발명의 특유한 효과에 대응될 것임을 첨언한다.

위와 같은 목적을 달성하기 위하여, 본 발명은 서로 다른 응용 프로그램이 탑재된 이기종 디바이스간에 이루어지는 피어 투 피어(Peer to Peer) 기반의 통합 네트워크 시스템으로서:

N(N은 1보다 큰 정수)개의 피어(Peer) 단말;

상기 각각의 피어 단말 내에 컴포넌트로 구성되며, 통합된 서비스 자원을 포함하는 서버 영역과 네트워크 접속 및 서비스 요청 프로세스를 진행하는 클라이언 트 영역으로 구분되는 통합 미들웨어 컴포넌트("X-Talk Component"); 및

상기 클라이언트들의 네트워크 접속시 고유한 피어 ID 코드를 부여하는 브릿징 서버(B-Server);를 포함하며, 각 피어 단말 간의 프로토콜이 어플리케이션 계층에 형성되는 것을 특징으로 한다.

상기 통합 미들웨어 컴포넌트는, 인터페이스를 통해 피어 단말기의 어플리케이션과 연결되며,

피어 단말 간의 연결모듈로서 데이터 패킷이 송수신되는 X-Talk P2P Connector 모듈;

상기 X-Talk P2P Connector 모듈을 통하여 데이터 패킷을 수신하며, 데이터 패킷을 분류하고 그 분류에 따라 프로세스를 결정하는 Packet Parser 모듈;

상기 Packet Parser 모듈에서 분류된 데이터 패킷의 결과 데이터에 따라 명령전송과 데이터 처리방식을 결정하는 Sync. Coordinator 모듈;

상기 Packet Parser로부터 전송된 상대방 피어 단말의 요청 서비스를 실행하는 X-Talk Server 모듈;

상대방 피어 단말의 요청 서비스를 실행할 때 필요한 컨텐츠를 포함하며, 피어 단말의 자원과 연결되는 통합 서비스 라이브러리 모듈; 및

상대방 피어 단말의 정보를 상기 B-Server를 통해 검색하며 피어 ID를 부여하는 네이밍 모듈을 포함하여 이루어진다.

또한, 상기 Sync. Coordinator 모듈은 Sync 전송인지 또는 Async 전송인지를 결정하며,

Sync 전송의 경우에는 제 1 피어 단말의 미리 결정된 대기 시간까지는 제 2 피어 단말에서 응답이 올 때까지 대기하며, Async 전송인 경우에는 제 2 피어 단말에게 명령을 전송한 다음에 대기하지 않고 곧바로 제어권을 제 1 피어 단말의 어플리케이션으로 돌려주는 것으로 구성될 수 있다.

또한, 상기 B-Server는 1개의 피어 투 피어 기반에서의 클라이언트-서버 통합 네트워크에 1개가 형성되며,

또 다른 B-Server가 형성하는 네트워크와 현재의 네트워크를 연결하기 위하여 상기 B-Server에 네트워크 게이트웨이를 구비하는 것이 좋다.

이하 본 발명에 따른 바람직한 실시예를 첨부한 도면을 참조하여 상세히 설명한다. 그리고 본 발명을 설명함에 있어서, 관련된 공지기능 혹은 공지 구성 등 이미 이 분야의 기술자에게 자명한 사항으로서 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는 그 상세한 설명을 생략한다.

1. 정의

본 발명에서 사용하는 중요한 용어로서, 모바일 디바이스를 포함한 이기종 피어들간의 분산된 자원을 공유하는 기반을 만듦과 동시에 Backoffice와 연동시킴으로써 P2P 기능과 C/S 모델의 기능을 통합하며 컴포넌트 내에 모듈화된 통합 서비스 라이브러리 및 통합 리소스들을 이용하여 각 피어 마다 통합 서버의 기능을 구현하는 본 발명 고유의 통합 미들웨어를 "X-Talk"라 정의한다.

2. X-Talk Protocol

서버에 중요자원을 확보하고 클라이언트의 요구에 따라 정보와 자원을 전송 하는 C/S(Client-Server) 시스템 모델과 달리 피어 투 피어(Peer-to-Peer) 시스템 모델은 기본적으로 모든 피어 컴퓨터나 기기들에 자원이 분산되어 있는 환경에서 구축하는 모델이다. 따라서 각각의 피어 기기들은 클라이언트적인 요소와 서버적인 요소를 모두 포함하여야 한다. 또한, 실시간으로 각각의 어플리케이션이나 서비스가 반응하고 대응해야 한다. 이를 위하여 Primitive Networking 기반 위에 피어 투 피어 시스템 구축을 용이하게 하는 새로운 Networking Infrastructure를 구축하였다.

도 1은 피어들 사이에서 X-Talk 프로토콜 기반의 데이터 패킷 포맷의 기본적인 구성을 나타내고 있다. OSI 7 Layer에서 Transport Layer까지는 TCP/IP 기반이며 실제 X-Talk 프로토콜은 어플리케이션 계층에 속한다. 기본적으로 C/S나 P2P나 low-level 네트워크는 동일하다. 그러나 어느 모델을 기반으로 시스템을 구성할 것인가 하는 것은 전적으로 어플리케이션과 관계된 것이므로, X-Talk 전용의 기본 통신 채널을 어플리케이션 레벨에서 별도로 구성하는 것이 타당하다.

도 2는 X-Talk 클라이언트(X-Talk 컴포넌트를 내장한 어플리케이션) 간에 이루어지는 통신의 패킷 구조를 나타내고 있으며, 각각 "Receiver"는 데이터 패킷을 받는 Peer ID, "Sender"는 데이터 패킷을 보낸 Peer ID, "Command"는 서비스 요청 Command, "Check Code for Command-Reply Pair"는 Receive한 특정 패킷이 어떤 Command에 대한 응답인지를 확인하는 코드, "Date_NuM"은 하위 데이터의 바이트 수, "Data"는 Command가 수반하는 실제 데이터를 의미한다.

X-Talk Name System 및 Peer ID, Peer Name

도 3은 X-Talk Peer ID와 피어 Code의 매핑에 대한 개략적인 구성을 도시하고 있다. 브릿징 서버(Bridging Server, 이하 "B-Server"라 한다)에 X-Talk 클라이언트가 접속하였을 때 고유한 String 값의 Peer ID에 일 대 일로 매핑된 고유한 Peer ID Code를 B-Server로부터 얻는다. Peer ID Code와 Peer ID 간의 매핑 X-Talk Name System에서 관리하며, 어플리케이션에서는 고유한 Peer ID Code로 사용하고 X-Talk 클라이언트 내부에서는 해당 Peer ID가 사용된다. 이것은 기존의 인터넷 어플리케이션에서 데이터 전송시 읽을 수 있는 Domain Name이 이 DNS를 거쳐 실제 IP Address로 번역되어 처리되는 것과 유사하다.

상기 Peer ID Code는 32 비트로 구성되어 있으며 각각의 비트들은 도 4와 같은 의미를 갖는다. "User Code", "Group Code", "Class Code"는 여러 피어 집단을 그룹화(Grouping)하는데 사용되며, "User Code"로 표현할 수 있는 피어의 최대수는 256개가 되며, 하나의 Group을 의미하는데, 이 Group은 최대 4096개를 갖는다. 또한, Group Code를 하나의 셀로 하는 그룹은 "Class Code"에서 표현되며 최대 4096개가 가능하다. "User Code", "Group Code", "Class Code"는 피어 집단의 규모에 따라 적절히 할당되어 인터넷상의 컴퓨터 및 유무선 기기들에 할당할 수 있다.

2. X-Talk Component

도 5는 X-Talk 컴포넌트의 개략적인 구성을 나타내고 있다.

X-Talk 컴포넌트는 인터페이스(2)를 통해 어플리케이션(1)과 연결되며, 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) 및 X-Talk P2P Connector(9)로 이루어지고, 서버 영역과 클라이언트 영역으로 구분되어 기능을 수행하며, 구분된 영역에서의 기능은 상기 도 5에 각각 C+일련번호, S+일련번호가 병기되어 있는 화살표로 도시되어 있다.

Packet Parser(4)

X-Talk P2P Connector(9)를 통해 들어오는 모든 데이터 패킷(Data Packet)은 모두 Packet Parser(4)로 들어간다. 패킷의 분류에 따라 처리할 프로세스가 결정되고 그 프로세스에 데이터와 제어권을 넘겨 주는 역할을 한다. 각각의 패킷 분류와 그에 따라 실시예를 나타내면 다음과 같다.

# 케이스 1 : 자기가 다른 피어에게 command를 전송했을 때 응답으로서 오는 데이터:

피어 A가 피어 B에게 서비스 요청 Command를 보냈을 때 피어 B는 처리결과를 피어 A에게 되돌려 보낸다. 이 결과 데이터는 상기 Packet Parser(4)로 들어와서, 케이스 1로 확인되면 즉시 Sync. Coordinator(3)으로 보내진다. Sync. Coordinator(3)에서는 피어 A가 전송한 command를 모두 기억하고 있다가 Packet Parser(4)로부터 오는 결과 데이터가 그 이전에 보낸 어떤 command의 결과 값인지를 확인하고 적절히 Application(1)에 그 결과를 통지(Notify)해 준다.

# 케이스 2 : 다른 피어에서 데이터를 일방적으로 푸쉬(Push)하거나 스트림(Stream)형태로 오는 데이터

X-Talk의 기능 중 음성 Steaming 기능이 여기에 해당한다. 압축된 음성데이터는 일정한 간격으로 피어 B에서 피어 A로 전송된다. 이 경우는 받은 Packet에 해당하는 특정한 command가 없다. 즉 일방적으로 피어 A가 받은 Packet을 재생시키는 것이므로 곧바로 X-Talk Server에서 음성 재생이 된다.

# 케이스 3 : 다른 피어에서 특정 서비스를 요청하는 데이터

피어 B가 피어 A에게 특정 서비스를 요청하는 경우이다. 파일 전송, 이벤트 전송, 메시지 전송, DB Handling 등등이 여기에 해당된다. Case 3으로 분류된 데이터는 X-Talk Server(5)로 보내지고 X-Talk는 요구된 특정 서비스를 통합 서비스 라이브러리(6)에서 찾아내고 호출해서 X-Talk Server(5)내에서 별도의 스레드(Thread)로 실행된다.

Sync. Coordinator(3)

상기 Sync. Coordinate(3)은 X-Talk command의 Sync/Async 처리를 하는 부분이다. Command가 Sync나 Async동작을 하는 것은 어플리케이션(1)이 상대 피어의 처리결과를 통보받는 방식이 다르다는 것을 의미하며, 이는 직접적으로 어플리케이션 설계에 영향을 미친다.

X-Talk에서는 기본적으로 상대 피어에 대한 서비스 요청 명령이 두 가지 형태를 가진다. 하나는 명령을 전송하고 상대 피어에서 응답이 올 때까지 기다리는 것(이때 명령을 전송한 피어는 Block 상태가 된다. 그리고 시간 제한을 둘 수가 있어서 응답이 지정한 시간 동안 오지 않으면 Block 상태가 해제되고 Fail Notify를 어플리케이션(1)에게 하게 된다)과, 또 하나는 전송 후 결과 데이터를 기다리지 않 고 곧바로 어플리케이션(1)으로 복귀하는 경우다. 전자는 Sync. Command라 부르고 후자는 Async. Command라 부른다. 전자의 사용은 주로 그 결과를 받지 않고서는 Application(1)의 진행을 해서는 안 되거나 할 이유가 없는 경우에 사용된다. 후자는 주로 상대 피어에게 요청한 서비스가 완료하는 데 시간이 많이 걸릴 경우 어플리케이션(1)이 필요 이상으로 대기하는 경우에 사용된다.

명령전송과 결과 데이터 처리까지의 상세 과정은 다음과 같다.

- Sync. Command

피어 A가 서비스 요청 데이터를 Sync. Coordinator(3)에 보내면 Sync. Coordinator(3)는 그 명령에 고유한 Key를 할당하고 메모리에 저장해 둔다. Command Packet을 전송한 후 상기 Packet Parser(4)로부터 결과 데이터가 분류되어 오기를 기다린다. Packet Parser(4)로부터 결과 데이터가 오면 거기에 포함된 Key가 명령전송 전에 저장한 키들 중에 존재하는가를 확인한 다음 어플리케이션(1)에 제어권을 돌려준다. 만약 정해진 시간 안에 상기 Packet Parser(4)로부터 데이터가 오지 않으면 time out을 선언하고 어플리케이션(1)에 fail을 통지한다.

- Async. Command

피어 A가 서비스 요청 데이터를 요청할 때 command뿐만 아니라 완료 event Code도 함께 상기 Sync. Coordinator(3)에 보낸다. Sync. Coordinator(3)는 그 명령에 고유한 Key와 어플리케이션(1)에서 보내진 event code도 함께 메모리에 저장한다. 피어에 전송한 후 기다리지 않고 곧바로 어플리케이션(1)으로 복귀한다. 이후 상기 Packet Parser(4)로부터 결과 데이터가 오면 거기에 포함된 Key가 명령전 송 전에 저장한 키들 중에 존재하는가를 확인한 후 함께 저장되었던 event code를 어플리케이션(1)에 통지한다.

X-Talk Server(5)

상대 피어가 요청한 서비스를 실행할 프로세스이며, 각각의 서비스마다 별도의 처리 스레드(thread)가 생성되며 결과 데이터 또한 개별적으로 생성된 채널을 통해 요청 피어로 되돌려 진다. X-Talk Server(5) 자체는 실행환경이며 실제 서비스에 해당하는 코드는 통합 서비스 라이브러리(6)에서 가져와서 실행한다.

Service Library(6)

본 발명의 통합 서비스 라이브러리(6)는 피어가 서버로서 역할을 할 때 즉 상대 피어가 요청한 서비스를 실행할 때 필요한 컨텐츠(Contents)를 포함하고 있는 장소이다. 파일정보 서비스, 파일 전송 서비스, 피어 관리 서비스, Audio/Video 처리, DB Transaction, Resources 관리 서비스, 메시지 및 이벤트 처리 등등의 루틴이 이에 해당되며, 종래의 네트워크에서는 각 피어들이 상기 루틴 중 어느 하나만을 수행하였던 것에 반하여, 본 발명의 통합 서비스 라이브러리(6)는 필요한 컨텐츠를 통합적으로 보유함으로써 다양한 서비스를 일원화하고 피어의 서버로서의 기능이 강화되며, 개별 서비스에 대한 개별적인 프로그래밍을 요구하지 않는다.

Resources(7)

통합 리소스(7)는 피어가 관리/통제할 수 있는 모든 자원이다. 피어가 실행되는 컴퓨터, 핸드폰, PDA, Embedded System의 파일들, 데이터베이스, 멀티미디어 콘텐츠, I/O 주변장치 등등이 이에 해당된다.

X-Talk Local Name System(10)

하나의 B-Server에 귀속된 피어들의 정보를 B-Server로부터 받아 자체적으로 보관하고 있어서 상대 피어의 정보를 확인할때 B-Server로 부터 확인하기 전에 먼저 검색하여 Peer ID에 해당하는 Peer Code를 주는 시스템이다.

X-Talk Component Interface(2)

X-Talk는 플랫폼에 따라 각기 다른 컴포넌트 및 인터페이스를 갖도록 구현하였으며 이에 대해서는 도 6이 개략적으로 나타내고 있다. X-Talk 컴포넌트는 Microsoft(이하 MS)사의 Win 98/NT/2000/XP, Pocket PC/ Win CE.Net 플랫폼용의 경우에는 COM(Component Object Model) 형태로 구현하였고, 모바일 디바이스인 핸드폰과 같이 제한된 리소스를 갖는 시스템의 경우에는 Java Virtual Machine(Java VM) 환경을 구성하기 위하여 J2ME(Java 2 Platform Micro Edition) 기반에서 컴포넌트를 구성하였다. MIDP(Mobile Information Device Profile)/CLDC(Connected Limited Device Configuration)은 J2ME의 핵심요소로서 표준 Java runtime 환경에서와 같은 형태로 모바일 응용프로그램에서 요구되는 핵심 응용프로그램 함수를 제공한다.

두 X-Talk 피어 상호 간에 Date Communication & Collaboration

피어 A를 기준으로 피어 B와의 Date Communication과 Collaboration을 설명한다. X-Talk가 동작하는 플랫폼에 관계없이 피어들 사이의 Data Communication 및 Collaboration은 동일하다.

- X-Talk에서의 기본 Service Request and Reply 체계는 다음과 같다:

도 7을 참조하여 피어 B에게 특정 서비스를 요청하거나 Event/Message 를 보낼 때, 즉 피어 A가 클라이언트로서 작동할 때를 기술하면, 먼저 Applications(1)에서 Interface(2)의 Method를 호출한다(S11). 다음으로, Sync. Coordinator(3)은 어플리케이션(1)이 지정한 Peer Name에 해당하는 Peer ID를 X-Talk Name System에 의뢰하여 획득하고(S12), Sync. Coordinator(3)는 그 정보를 X-Talk P2P Connector(9)로 전달하면, X-Talk P2P Connector(9)는 X-Talk Packet을 만들어 지정한 목적지 Peer ID로 전송한다(S13). 피어 A가 피어 B에게 요청하는 서비스의 내용은 X-Talk Data Packet의 Command에 있고 관련 정보는 Data에 있기 된다.

이때 Sync. Coordinator(3)는 Applications(1)이 Sync 전송을 원하는지 아니면 Async 전송을 원하는지에 따라 다른 동작을 하게 된다(S14). 만약 Sync 전송이라면 목적지 피어에서 응답이 올 때까지 해당 루틴을 끝내지 않고 대기한다. 즉 Application(1)은 응답이 올 때까지 다른 동작을 하는 것이 불가능해질 것이다. 그러나 지정한 일정시간 동안 목적지 피어에서 응답이 없다면, 예컨대 t>t_o (t_o은 미리 결정된 대기 시간)인 경우에는 Error Code와 함께 제어권을 Application (1)에게 돌려준다. 이러한 Sync 전송 프로세스는 Message/Event 전송 또는 특정 서비스 요청이 목적지 피어에게 무사히 전달되는지를 Real-Time으로 확인할 필요가 있을 때 사용한다. 반면에 Asyn 전송 프로세스는 목적지 피어에 Event/Message/서비스 요청을 전송한 후 곧바로 Sync. Coordinator(3)가 출발지 피어 A의 Applications(1)에게 제어권을 돌려준다. 즉 피어 A의 어플리케이션(1)은 Interface(2)를 호출한 후 곧바로 제어권을 돌려받기 때문에 다른 작업을 수행할 수 있다.

도 8은 목적지 피어 B로부터 출발지 피어 A에게로 Return Event/Return Data를 전송하는 플로우에 대하여 개략적으로 도시하고 있다. 전송된 Event/Message/서비스 요청이 목적지 피어 B에 도착한 다음에(S21), 목적지 피어 B는 다시 Return Event/Return Data를 출발지 피어 A에게 전송한다(S22). 피어 A가 Return Event/Return Data를 받으면 이것이 어떤 Event/Message/서비스 요청에 관한 Return Event/Return Data인지를 Check Code for Command-Reply Pair를 보고 확인하고(S23), 그런 다음에 해당 Application(1)에 통지하게 된다(S24).

이상의 X-Talk가 제공하는 Functionality는 모두 위에서 설명된 플로우를 따라서 동작되며, 이러한 동작체계는 X-Talk 프로토콜과 밀접하게 결합되어 있다. 이하에서는 X-Talk 프로토콜 기반하에서 이루어지는 구체적인 프로세스에 대하여 상세히 설명한다.

① Event/Message 전송

도 9는 출발지 피어 A의 어플리케이션(1)에서 목적지 피어 B의 어플리케이션(1)으로 Event/Message를 전송할 때의 과정을 도시하고 있다.

먼저, 피어 A의 어플리케이션(1)에서 인터페이스(2) 및 Sync. Coordinator(3)를 거쳐 피어 A의 X-talk P2P Connector(9), 피어 B의 X-talk P2P Connector(9)를 경유하여 Packet Parser(4)에 도착하는 과정은 S31 단계에서부터 시작하여 S38 단계를 통해 이루어진다. 그 다음으로 피어 B의 Packet Parser(4)에 서는 두 가지 방향으로 데이터 전송이 이루어진다. 하나는 피어 B의 인터페이스를 통해 어플리케이션에 Event/Message를 통지하는 것이며(S38, S39), 다른 하나는 피어 A에게 Event/Message가 도착했다는 결과 Return Signal을 전송하는 것이다(S40). 한편 Return Signal 전송 과정은 상기 S40을 거쳐 최종적으로 피어 A의 어플리케이션(1)으로 통지된다(S41 ~ S43). 이상의 기능을 이용하여 핸드폰과, PDA, PC, Embedded System간에 실시간 텍스트와 이벤트를 교환할 수 있으며, 이를 채용한 응용프로그램으로 실시간 기기간 Messenger, Control 장치의 상태 감시 및 리모팅을 할 수 있다.

② File 전송

X-Talk에서 파일 전송의 바람직한 실시형태를 개시하기 위하여 우리는 관여하는 세 개의 피어를 상정한다. 다시 말하면 피어 A가 피어 B에 있는 특정 파일을 피어 C에게 전송하도록 지정하는 방식이다. 이러한 방법은 자신의 피어에서 상대 피어로만 파일을 전송하는 즉 FTP 방식보다 더 많은 유연성을 준다. 예컨대 핸드폰이나 PDA처럼 네트워크 Bandwidth가 작은 망에 있는 Peer Device가 다른 두 개의 피어들 사이의 대용량 파일 전송을 제어할 수 있게 한다.

도 10은 세 개의 피어가 각각 Order Peer, Source Peer, Target Peer로 각각 구분되어 있는 경우를 나타내며, Order Peer인 피어 A가 Source Peer인 피어 B에게 피어 C를 타깃으로 하여 특정 파일을 전송할 것을 명령하면, 피어 B는 Target Peer인 피어 C에게 해당 특정 파일을 실제로 전송하게 된다. 도 11은 이러한 메커니즘과는 달리 Order Peer와 Source Peer가 같은 Peer 인 경우로서, 파일전송을 지령 하는 피어 A가 자신의 파일을 Target Peer인 피어 C에 전송하게 된다.

도 12는 위 도 10의 피어 A에서 피어 B에 명령하여 피어 B의 file을 피어 C에 전송하고자 할 때의 플로우를 보다 구체적으로 도시하고 있다(피어 A : order Peer, 피어 B : source Peer, 피어 C : target Peer)

피어 A의 Application(1)에서 Interface(2)의 file transfer method를 호출한다(S101). Interface(2)는 상기 Application(1)의 파일 전송 호출명령을 받아 이를 Sync. Coordinator(3)로 전달하고(S102), Sync. Coordinator(3)는 X-Talk Name System(10)에게 문의하여 상기 Application(1)에게서 받은 피어 B Name의 실제 Peer ID를 얻는다(S103). 다음으로, X-talk P2P Connector(9)로 전송하게 되는데, 그 전송방식은 피어 B로 소스 피어로 하여 타깃 피어인 피어 C로 파일 전송 서비스를 요청한 다음에 제어권을 다시 돌려받아 자신은 다른 작업을 수행할 필요성이 있으므로 Asyn 전송방식이 될 것이다(S104). 그리고 전송지령이 완료되면 그 완료된 사실을 상기 어플리케이션(1)에 통지한다(S105 ~ S105″).

다음으로, 상기 피어 A의 X-talk P2P Connector(9)를 거쳐 피어 B의 X-talk P2P Connector(9)로 command packet을 전송(S106)함으로써 피어 A에서 피어 B로의 프로세스가 개시된다. 상기 피어 B의 X-talk P2P Connector(9)는 상기 command packet을 Packet Parser(4)로 전달하며(S107), Packet Parser(4)는 Packet에 포함된 command를 확인하며 X-Talk Server(5)로 전달한다(S108). X-talk Server(5)에서는 요청받은 서비스에 대응하기 위하여 해당하는 Service Library(6)를 호출하고, Service Library(6)는 자신의 리소스(7)를 이용하여 피어 A에게서 요청받은 작 업을 수행한다(S109). 이 경우 피어 B의 특정 File을 피어 C에게 전송하는 것이므로 피어 B의 X-Talk Server(5)는 새로운 프로세스를 만들고 또 다른 서비스 요청에 대응할 상태로 들어간다. 즉 파일 전송이란 작업 자체가 전송완료할 때까지 시간이 걸리므로 그 작업을 위한 새로운 프로세스를 생성하여 그것에 작업은 맡기고 X-Talk Server(5) 자신은 다른 Peer에게서 오는 서비스 요청을 위한 대기상태로 간다. 이는 피어 B의 CPU를 효율적으로 이용하는 방법이 된다. 새롭게 생성된 file 전송 프로세스는 background에서 파일 세그먼트를 피어 C에게 전송하게 된다(파일 세그먼트(file segment)란 커다란 파일을 특정한 단위의 크기로 쪼갠 파일 데이터이다).

피어 C로의 전송준비를 위한 과정으로서, 상기 피어 B의 X-Talk Server(5)는 상기 Sync. Coordinator(3)에게 파일 세그먼트를 전송해줄 것을 의뢰하게 되며(S110), 상기 Sync. Coordinator(3)는 해당 파일 세그먼트를 X-Talk P2P Connector(9)로 전달하게 된다(S111).

다음으로, 상기 파일 세그먼트는 피어 B의 X-Talk P2P Connector(9)를 거쳐 피어 C의 X-Talk P2P Connector(9)로 들어간다(S112). 그리고 Packet Parser(4)에 도착한 다음에(S113), 피어 B가 보낸 command를 해석하여 X-Talk Server(5)로 보내진다(S114). 피어 C의 X-Talk Server(5)는 피어 B가 보낸 서비스 요청이 command와 함께 전송된 데이터가 자신의 특정 디렉토리에 파일로서 저장해야 하는 것을 인식하며, 자신의 Service Library(6)의 SaveFileData를 호출하여 저장한다(S115). 한편, 피어 B의 X-Talk Server(5)와 피어 C의 X-Talk Server(5)는 모두 피어 A와 피 어 B에게서 서비스 수행 요청을 받지만 그 내용은 다르다. 피어 B의 X-Talk Server(5)는 피어 A가 지정한 피어 B의 디렉토리의 파일을 세그먼트 단위로 쪼개서 피어 C로 보내도록 하는 것이고, 피어 C의 X-Talk Server(5)는 피어 B가 보낸 파일 세그먼트를 피어 B가 지정한 디렉토리에 저장하는 것이다.

상기 X-Talk Server(5)는 해당 파일 세그먼트가 모두 전송되었다면 상기 Packet Parser(4)에 저장 완료 시그널을 피어 B에게 전송해 줄 것을 요청하고(S116), Packet Parser(4)는 세그먼트 저장 완료 시그널을 자신의 X-Talk P2P Connector(9)로 전달하게 된다(S117).

이러한 방식으로 모든 파일이 다 전송되면 피어 B는 전송완료 시그널을 피어 A에게 전송한다. 그리고 이를 위하여 먼저 피어 C의 X-Talk P2P Connector(9)가 피어 B의 X-Talk P2P Connector(9)에게 저장 완료 시그널의 리턴 데이터를 전송하고(S118), 피어 B의 X-Talk P2P Connector(9)는 이를 피어 B의 Packet Parser(4)에게 전송하며(S119), Packet Parser(4)는 전송받은 리턴 데이터를 파싱한 다음에 이를 자신의 Sync. Coordinator(3)로 전달하면(S120), Sync. Coordinator(3)는 리턴 데이터와 전송 명령 코드의 일치 여부를 확인하여 X-Talk Server(5)에게 전송한다(S121).

그리고 현재 파일의 전송이 세그먼트 단위로 이루어지고 있기 때문에, 파일 전체가 피어 C로 전송완료되었는지를 연산할 필요가 있으며, 따라서 X-Talk Server(5)가 상기 S121를 통해 리턴 데이터와 전송 명령 코드가 일치 여부가 확인한 다음에 피어 A의 전송명령에 의하여 이루어진 피어 B의 피어 C로의 해당파일의 전송이 모두 완료되었는지 여부를 연산한 다음에(S122) 완료되지 않은 경우에는 상기 S109 단계부터 다시 시작하고, 완료된 경우에는 Packet Parser(4)와 X-Talk P2P Connector(9)를 거쳐 피어 A의 X-Talk P2P Connector(9)로 리턴 데이터로서 파일 전송 완료 시그널을 전송한다(S123, S124, S125). 그리고 피어 A의 X-Talk P2P Connector(9)는 수신받은 리턴 데이터를 자신의 Sync. Coordinator(3)에게 전달하고(S126), Sync. Coordinator(3)는 파일 전송 완료의 리턴 데이터와 전송명령 코드의 일치 여부를 확인하고 Notify event code를 획득하여 피어 A의 Application(1)에게 전송완료의 통지를 수행함으로써(S127, S128) 파일 전송은 끝나게 된다.

피어 A가 자신의 파일을 피어 B에게 전송할 경우는 마치 피어 A가 피어 A에게 피어 A의 파일을 피어 B에게 전송하라고 하는 것과 같다. 모든 전송과정은 위의 경우와 같다. 즉 order peer : A, source peer : A, target Peer : B가 된다.

③ DB Access

P2P의 모델이 적용되는 분야는 자원이 여러 컴퓨터나 디바이스에 골고루 분포되어 있어서 서로 자원을 활용하기 위해서는 각각의 관련된 기기들이 Server와 Client의 모습을 둘 다 가지고 있어야 한다. 여기서 말하는 자원이라 함은 각각의 Peer들이 보유하고 있는 파일들, 그 디바이스에 연결되어 있는 또 다른 물리적인 장치들, 그리고 무엇보다도 Database를 뜻하게 되며, 따라서 DB의 공유는 Peer to Peer의 기능 중 중요한 부분을 차지한다.

대부분의 DB는 CPU와 하드디스크의 용량이 큰 경우가 대부분이겠지만 최근에는 PDA와 핸드폰의 CPU와 저장장치도 급속도로 고기능화, 대용량화하고 있는 추세 여서 이런 Mobile Device들도 자체 DB를 보유하고 관리하게 된다. 여기서 설명하는 DB Access란 'Peer 상호 간에 상대 방 Peer의 DB를 Access하는데 있어서 자유로울뿐만 아니라 상대 Peer가 하고 있는 작업에 영향을 주지 않고 서비스가 가능해야 한다.'라는 것이다. 이는 모바일 디바이스 조차도 background service(demon process)를 구현해야 함을 의미한다.

도 13에서는 피어 상호 간에 Database를 자유롭게 억세스하여 read/modify/insert 할 수 있는 기능에 대하여 나타내고 있다. S131부터 S148 단계로 이어지는 플로우는 위 ①과 ②의 실시예와 큰 차이가 없지만, 상대방 피어의 리소스(7)에 있는 파일을 전송하는 것과는 달리 S140 및 S141을 통하여 피어 B의 Resource(7)에 저장되어 있는 데이터베이스를 억세스하여 읽거나 수정하게 된다. 즉 도 13의 실시예는 피어 A가 피어 B의 DB의 데이터를 읽어오거나 특정 데이터를 피어 B의 DB에 추가/삭제/수정할 때의 flow이다. 또한, 하나의 record단위가 아니라 작업단위(transaction 단위)로 처리해야할 데이터의 처리에 대해서도 설명한다.

즉, 피어 A의 Application (1)에서 Interface(2)의 ExecuteSQL method를 호출한다. Sync. Coordinator(3)에서 X-Talk Name System(10)에게 의뢰해서 피어 B ID를 얻는다. 다음으로, X-Talk P2P Connector(9)로 command packet을 전송하고, 피어 B의 X-Talk P2P Connector(9)를 경유하여 Packet Parser(4)에 전달되고, Packet Parser(4)는 받은 패킷이 서비스 요청임을 확인하고 X-Talk Server(5)로 넘긴다. X-Talk Server(5)는 요청 서비스가 SQL 문장 실행임을 인식하고 Service Library(6)의 Service Library 중에서 적절한 function을 호출하여 실행한다. 실행 결과는 요청받은 records들의 결과 데이터이고 이것을 피어 A에 return한다.

한편, transaction단위 데이터 갱신인 경우, Application(1)에서는 여러 SQL 문장을 하나의 Packet으로 묶는다. 이는 처리해야할 여러 SQL 문장은 개별적으로 처리되어서는 안 되고 반드시 모두 one-time에 실행되어야 하기 때문이다. 즉 여러 sql 문장이 X-Talk의 one command에 처리되기 때문에 데이터 무결성을 보장할 수 있다.

3. Bridging Server

도 14는 본 발명의 B-Server의 개략적인 구성을 나타내고 있으며, 그 주요한 구성으로서 Common Service Library(10), X-Talk Gateway(20), Manager of Peer Session Resources(40), Authentication Process(70)를 포함하고 있다.

X-Talk Gateway(20)

B-Server는 그에 속한 피어들과 함께 X-Talk Network을 형성한다. 또 다른 B-Server가 형성하는 X-Talk Network과 연결시키기 위해서 관련된 B-Server들은 서로에게 게이트웨이(Gate Way)로서 작동돼야 한다. B-Server는 소속된 피어를 위한 common service 이외에 위와 같은 게이트웨이로서의 역할도 수행한다.

Manager of Peer Session Resources(40)

이 요소는 공유자원(Shared Resources)과 Locking Resources를 포함한다. 공유자원은 B-Server가 관리하는 자원과 각각의 피어에 귀속된 자원 모두에 해당된다. 특정 피어에 속한 자원을 여러 다른 피어가 동시에 사용하려 할 때 이 자원은 Shared Resources(50)라 부른다. 이때 이 공유자원을 오염시키지 않고 정상적인 절차를 통해서 사용하려는 피어에게 질서있게 제어권을 주는 체계가 필요한데 이는 상기 Manager of Peer Session Resources(40)에 포함된 Locking Resources(60)를 통해 이루어진다.

Common Service Library(10)

X-Talk 서비스 중에 피어들 간에 이루어질 수 있는 서비스 이외에 1 : N(N은 1보다 큰 정수) 또는 N : 1로 이루어져야 하는 서비스가 있다. 이 경우는 B-server가 서비스에 관여할 수밖에 없는데 이때 처리에 관련된 라이브러리가 Common Service Library이다. 주로 특정 피어가 다수의 피어에게 동시에 메시지나 이벤트를 보내는 서비스인 경우가 이에 해당한다.

Authentication Process(70)

피어가 X-Talk에 참여하기 위해서는 제일 먼저 B-Server에 인증을 받고 접속을 해야 한다. B-Server는 인증 이외에 새로운 Peer의 등록, 권한등급의 설정 등 피어를 위한 기본서비스를 수행한다.

도 15는 C/S 방식과 P2P 방식을 융합한 네트워크에 있어 이기종 디바이스 피어들이 B-Server를 매개로 네트워크가 형성되어 있는 구조를 개략적으로 나타내고 있다. 이러한 구조에서 B-Server는 위에서 설명한 상기 X-Talk Component와의 상호동작을 수행한다.

B-Server와 X-Talk Component와의 상호동작

모든 X-Talk Component는 B-Server에 접속된 후 사용될 수 있다. X-Talk 네 트워크에서의 B-Server의 주된 기능은 다음의 표 1과 같다.

[표 1]

1. 신규 X-Talk 클라이언트의 등록 및 정보관리

2. X-Talk 접속에 대한 인증

3. 접속하고 있는 X-Talk의 상태 감시 및 제어

4. 접속하고 있는 X-Talk들의 자원을 공유/조정해 주는 기능

5. 하나의 X-Talk 네트워크에서 다른 X-Talk 네트워크로 연결해주는 Gateway 기능

① 신규 X-Talk 클라이언트의 등록 및 정보관리

X-Talk는 사용하기 전에 B-Server에 새로운 X-Talk 클라이언트를 위한 계정을 생성하고 사용해야 한다. 계정이 생성되면 접속 Hostname, IP, OS type(Platform type), shared directory, alias 등 네트워크와 접속자와 관계된 상세 정보가 B-Server의 데이터베이스에 저장된다. 또한, 피어 그룹에 대한 내용, 계정의 사용권한에 대한 내용, X-Talk 상호 간에 friend 설정에 관한 내용도 함께 저장된다.

② X-Talk 접속에 대한 인증

모든 X-Talk는 하나의 X-Talk ID에 오직 하나의 X-Talk 네트워크 세션이 배정된다. 즉 어떤 X-Talk가 특정 ID를 사용 중에 있다면 다른 X-Talk는 같은 ID를 사용할 수 없다.

③ 접속하고 있는 X-Talk의 상태 감시 및 제어

B-Server는 현재 접속하고 있는 X-Talk의 연결을 강제로 종료시킬 수 있고 또한, 사용을 제한할 수도 있다.

④ 접속하고 있는 X-Talk들의 자원을 공유/조정해 주는 기능

여러 피어들이 참여하고 있는 X-Talk 네트워크에서는 서로 간에 자원을 공유함에 있어서 자원 사용의 독점권한을 얻고 사용 후 권한을 다른 X-Talk가 사용할 수 있도록 release해주는 기능을 제공한다. 예컨대 피어 A가 피어 B로 파일을 전송하고 있는 경우 또 다른 피어 C가 피어 B로 같은 이름의 파일을 생성하려고 할 때 피어 A가 피어 B로의 전송이 끝날 때까지 안전하게 사용할 수 있는 권한을 주는 것이 필요하다. 또 다른 예로서, 피어 A가 피어 B의 I/O 장치에 어떤 sequential한 제어신호를 전송하고 있을 때, 그 sequential한 제어신호가 다른 피어에게 방해받아서는 안 될 경우에, 피어 A에게 피어 B의 I/O에 대하여 독점권을 줄 수 있는 기능이 있어야 하며, 이러한 기능을 B-Server가 수행한다.

피어 A는 실시간으로 독점권한을 의미하는 문자열을 B-Server에 등록할 수 있다. 만약 다른 피어 즉 피어 B가 피어 A가 현재 사용하고 있는 자원을 사용하려면 먼저 B-Server에게 피어 A가 지정한 자원을 현재 사용할 수 있는지 문의해야 한다. 문의한 결과가 OK가 얻어지면(사실 문의에 대한 결과는 OK 시그널과 동시에 문의한 피어를 위해 Locking까지를 해서 전송한다) 사용할 수 있고, 그 결과가 not OK이면 현재 다른 피어가 사용 중에 있다는 것을 의미한다. 이러한 방식으로 구성하면 참여하고 있는 어플리케이션(X-Talk Component를 포함하는 어플리케이션)들은 서로간의 약속에 의하여 각각의 피어 자원을 안전하게 사용할 수 있으며, B-Server는 이와 같은 프로세스를 주관하게 된다.

⑤ 하나의 X-Talk 네트워크에서 다른 X-Talk 네트워크로 연결해주는 게이트웨이 기능

하나의 B-Server는 하나의 X-Talk 네트워크를 구성한다. 따라서 여러 개의 B-Server가 존재하는 경우 즉 여러 X-Talk 네트워크가 있는 경우에는, 서로 다른 X-Talk 네트워크에 속한 피어들을 연결하도록 하는 게이트웨이의 역할을 수행한다.

이상의 실시예들은 단지 본 발명을 예시하기 위한 것이며, 본 발명의 보호범위가 이들 실시예에 의해 제한되는 것은 아니다.

이상에서 자세히 설명한 본 발명에 따르면, P2P방식의 네트워크를 채용함으로써 기본적으로 각 피어들로 분산된 자원을 효과적으로 활용할 수 있을 뿐만 아니라, 각 피어들의 디바이스에 구현되어 있는 통합 미들웨어 컴포넌트에 클라이언트 영역뿐만 아니라 서버 영역을 구성하면서 각각의 피어들간에 자원의 송수신 프로세스가 클라이언트-서버 간의 그것과 같은 특징을 갖도록 하는 한편, 각 피어들의 네트워크 접속을 B-Server가 관리하도록 함으로써 전체 시스템을 통합적으로 관리할 수 있는 장점이 있다.

또한, 피어 상호 간에 분산되어 있는 데이터베이스를 원격에서 핸들링하거나, 다른 피어에 저장되어 있는 파일을 또 다른 피어에게 전송할 수 있도록 함으로써 네트워크 구성에 있어 높은 유연성을 구현하였으며, 각 피어는 자신에 저장되어 있는 데이터나 파일이 아니더라도 다른 피어에게 있는 자원을 컨트롤할 수 있기 때문에, 각 피어들이 PC가 아닌 모바일 다바이스라 하더라도 네트워킹에 별다른 장애가 없으며, 또한 업그레이드와 A/S가 피어들 상호 간에 자발적으로 이루어질 수 있는 유용한 효과가 있다.

또한, Sync & Async Mode 지원이 가능하기 때문에, 네트워크에서 요구되는 서비스의 특징이나 성질에 따라 각 피어들의 효과적인 작업수행이 가능한 장점이 있다.

무엇보다도 본 발명의 통합 미들웨어는 특정 파일의 전송뿐만 아니라 이벤트 전송, 데이터베이스 핸들링, 업데이트, 리모팅, 스트리밍 등의 서비스를 통합하여 일원화하고 이를 피어 내에 서버 영역에 구현함으로써 각 피어의 서버로서의 기능을 강화하고 전체 네트워크의 유연성을 높였으며, 네트워크 기반의 프로그래밍을 지원하고 어플리케이션 레벨에서 컴포넌트로 구성되고, 유무선 관계없이 다양한 OS를 채용한 기기들간의 정보교환이 동일한 어플리케이션 인터페이스를 사용하기 때문에 기기의 물리적인 네트워킹 방법이나 사용환경에 관계없이 시스템 구축이 가능한 장점이 있으며, 이로써 네트워크를 위한 프로그램을 별도로 개발하지 않아도 되며, 개발에 투여되는 인원 및 시간을 절약할 수 있다.

나아가 본 발명의 컴포넌트 환경을 지원하기 위한 독립적인 관리서버(B-Server)가 제공됨으로써 운영을 위하여 IIS와 같은 웹 서버나 기타 다른 서버를 필요로 하지 않는다.

그밖에 본 발명의 특유한 구성으로 말미암아 발생하는 특유한 효과는 발명의 구성에서 설명한 범위에서 용이하게 추고 할 수 있으며, 본 발명의 효과는 이상에서 설명한 실시예 및 본 발명의 청구 범위에 기재된 사항뿐만 아니라, 이들로부터 용이하게 추고 할 수 있는 범위 내에서 발생될 수 있는 효과 및 산업발전에 기여하는 잠정적 장점의 가능성들에 의해 더욱 넓은 범위로 포섭될 것임을 첨언한다.

Claims (4)

1. 서로 다른 응용 프로그램이 탑재된 이기종 디바이스간에 이루어지며, 각 피어 단말 간의 프로토콜이 어플리케이션 계층에 형성되는 피어 투 피어(Peer to Peer) 기반의 통합 네트워크 시스템으로서:

   N(N은 1보다 큰 정수)개의 피어(Peer) 단말;

   상기 각각의 피어 단말 내에 컴포넌트로 구성되며, 통합된 서비스 자원을 포함하는 서버 영역과 네트워크 접속 및 서비스 요청 프로세스를 진행하는 클라이언트 영역으로 구분되는 통합 미들웨어 컴포넌트("X-Talk Component"); 및

   상기 클라이언트들의 네트워크 접속시 고유한 피어 ID 코드를 부여하는 브릿징 서버(B-Server);를 포함하며,

   상기 통합 미들웨어 컴포넌트는, 인터페이스를 통해 피어 단말기의 어플리케이션과 연결되며,

   피어 단말 간의 연결모듈로서 데이터 패킷이 송수신되는 X-Talk P2P Connector 모듈과,

   상기 X-Talk P2P Connector 모듈을 통하여 데이터 패킷을 수신하며, 데이터 패킷을 분류하고 그 분류에 따라 프로세스를 결정하는 Packet Parser 모듈과,

   상기 Packet Parser 모듈에서 분류된 데이터 패킷의 결과 데이터에 따라 명령전송과 데이터 처리방식을 결정하는 Sync. Coordinator 모듈과,

   상기 Packet Parser로부터 전송된 상대방 피어 단말의 요청 서비스를 실행하는 X-Talk Server 모듈과,

   상대방 피어 단말의 요청 서비스를 실행할 때 필요한 컨텐츠를 포함하며, 피어 단말의 자원과 연결되는 통합 서비스 라이브러리 모듈; 및

   상대방 피어 단말의 정보를 상기 B-Server를 통해 검색하며 피어 ID를 부여하는 네이밍 모듈을 포함하고,

   상기 Sync. Coordinator 모듈은 Sync 전송인지 또는 Async 전송인지를 결정하며,

   Sync 전송의 경우에는 제 1 피어 단말의 미리 결정된 대기 시간까지는 제 2 피어 단말에서 응답이 올 때까지 대기하며, Async 전송인 경우에는 제 2 피어 단말에게 명령을 전송한 다음에 대기하지 않고 곧바로 제어권을 제 1 피어 단말의 어플리케이션으로 돌려주며,

   상기 B-Server는 1개의 피어 투 피어 기반에서의 클라이언트-서버 통합 네트워크에 1개가 형성되며,

   또 다른 B-Server가 형성하는 네트워크와 현재의 네트워크를 연결하기 위하여 상기 B-Server에 네트워크 게이트웨이를 구비하는 것을 특징으로 하는, 피어 투 피어 기반에서의 클라이언트-서버 통합 네트워크 시스템.
2. 삭제
3. 삭제
4. 삭제

Images