KR101224827B1 - Ｄａｃｏｎ 을 이용한 네트워크 시스템 및 네트워크 연결방법 - Google Patents

Ｄａｃｏｎ 을 이용한 네트워크 시스템 및 네트워크 연결방법 Download PDF

Info

Publication number
KR101224827B1
KR101224827B1 KR1020080055721A KR20080055721A KR101224827B1 KR 101224827 B1 KR101224827 B1 KR 101224827B1 KR 1020080055721 A KR1020080055721 A KR 1020080055721A KR 20080055721 A KR20080055721 A KR 20080055721A KR 101224827 B1 KR101224827 B1 KR 101224827B1
Authority
KR
South Korea
Prior art keywords
host
portal
network
dacon
content
Prior art date
Application number
KR1020080055721A
Other languages
English (en)
Other versions
KR20090129678A (ko
Inventor
최양희
고동일
조기덕
이문영
권태경
Original Assignee
재단법인서울대학교산학협력재단
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 재단법인서울대학교산학협력재단 filed Critical 재단법인서울대학교산학협력재단
Priority to KR1020080055721A priority Critical patent/KR101224827B1/ko
Publication of KR20090129678A publication Critical patent/KR20090129678A/ko
Application granted granted Critical
Publication of KR101224827B1 publication Critical patent/KR101224827B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/63—Routing a service request depending on the request content or context
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/104—Peer-to-peer [P2P] networks
    • H04L67/1074—Peer-to-peer [P2P] networks for supporting data block transmission mechanisms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

본 발명은 DACON (Decentralized and Autonomous Content-centric Overlay Networking) 을 이용하는 네트워크에 대한 발명으로서, 사용자들이 어떤 컨텍스트 정보를 기반으로 자신이 원하는 콘텐츠를 쉽게 찾고, 이를 임의의 특정 소스가 아니라 네트워크 자체로부터 손쉽게 얻을 수 있도록 한다. 또한, DACON 은 이러한 새로운 콘텐츠 네트워킹 서비스를 일반 인터넷 사용자들이 직접 구매하는 액세스 포인트 (access point; AP) 또는 홈 기지국 (base station; BS) 등의 장비를 통해 구축한다. 각각의 액세스 포인트나 홈 기지국은 사용자들의 자발적인 기증을 통해 이루어지게 되고, DACON 은 이들을 충분히 비집중화된 서비스 네트워크를 구성하는 일반적인 메커니즘을 제공한다.
DACON, 콘텐츠기반 네트워크

Description

ＤＡＣＯＮ 을 이용한 네트워크 시스템 및 네트워크 연결 방법{A NETWORK SYSTEM AND METHOD THEREOF WITH DACON}
인터넷은 패킷 라우팅과 TCP/IP 를 바탕으로 전 세계적인 네트워크가 되었으며, 웹의 등장과 함께 이제는 현실 세상과 떼어 놓을 수 없는 생활의 기본 인프라가 되었다. 하지만, 역설적으로 웹과 현실의 융합은 정보의 폭발적 증가를 일으켰으며, 이에 따라 많은 사람들은 많은 정보들 중에서 자신이 원하는 정보를 찾고 활용하는데 어려움을 겪게 되었다. 최근의 연구결과에서는 인터넷 트래픽 중 50%~90% 가 P2P 트래픽이며 현재의 인터넷 사용이 대용량 컨텐츠의 검색과 획득에 집중되고 있음을 보여준다. 하지만 현재의 접속 및 대화 중심의 인터넷 구조로는 이를 처리하는데 많은 문제가 따르게 된다. 이에 따라, 현재의 인터넷 구조의 다음과 같은 문제점을 보여주고 있다.
먼저, 기존의 접속 및 대화 중심의 네트워킹 메커니즘은 기본적으로 1 대 1 통신을 가정하고 있다. 따라서, 어떤 N 개의 데이터와 M 명의 사용자가 있을 때, 네트워크 대역폭 사용량은 N×M 이 된다. 이러한 문제를 해결하기 위해 IP 멀티캐스트 등이 개발되었지만 확장성의 부재와 혼잡 제어의 어려움 등으로 널리 보급되지는 못하고 있다. 이에 최근, P2P 와 그리드 딜리버리 (grid delivery) 등과 같이 응용 레벨에서 이런 문제들을 해결하려는 시도들이 생기고 있다.
또 다른 문제점으로는, 일반적으로 사용자들이 바라는 것은 대부분 어떤 데이터를 얻어 오는 것이지만 현재 네트워크의 기본 메커니즘은 어떤 특정 데이터 소스의 로케이터를 얻어내 접속을 설정하고 여기에서 데이터를 받는 번거로운 과정이 필요하다는 것이다. 또한, 어렵게 알아낸 소스로부터의 데이터 전송이 실패한다면 데이터의 확보 자체가 어려울 수도 있다. 최근의 P2P 의 확산은 이러한 불편함을 해소하기 위함 때문이라고도 볼 수 있다.
이러한 문제점들은 사용자의 요구를 기존의 인터넷 환경이 충족시켜주지 못하는 것에 기인하는 것으로서, 사용자의 요구를 충족시킬 수 있는 새로운 인터넷 환경이 요구되고 있다. 즉, 사용자들의 인터넷 사용 패턴이 대화 중심에서 대용량 데이터 중심으로 옮겨감에 따라 이를 처리하기 위한 인터넷 인프라가 크게 요구되고 있다. 또한 미래의 유비쿼터스 컴퓨팅 환경을 구축하기 위해 Mobile WiMAX, WSN 등의 새로운 기술의 네트워크에 대한 투자 역시 커지고 있다. 하지만 현재의 인터넷 서비스 공급자 (Internet Service Provider; ISP) 들은 투자를 더 늘린다고 해도 수익을 증가시킬 수 있는 요소가 제한적이기 때문에 투자에 대한 의욕을 가지기 어렵다. 또한, 사용자들은 집에서는 유선 인터넷 접속 비용을 부담하고, 휴대폰 망을 이용하기 위해 별도의 요금을 또 지출하고, 집 밖에서 인터넷을 사용하기 위해 다시 무선 인터넷 사용료를 지불하고 있다. 한 개인이 서비스를 이용할 수 있는 시간은 한정되어 있기 때문에 개인들은 이 모든 사용료를 지불하면서 의미있는 시간의 서비스를 이용할 수는 없을 것이고, 결국 이는 사용자 들이 새로운 서비스를 이용하는 데에 제약이 될 것이다.
기존의 접속 및 대화 중심의 네트워크에 대한 대안으로서 P2P (Peer to Peer) 네트워크가 등장했다. P2P 는 인터넷에 연결되어 있는 여러가지 형태의 리소스 (저장 공간, CPU 파워, 콘텐츠, 그리고 연결된 컴퓨터를 쓰고 있는 사람 그 자체) 를 이용하는 일종의 응용 프로그램이다. 순수 P2P 파일 전송 네트워크는 클라이언트나 서버란 개념 없이, 오로지 동등한 계층 노드들 (peer nodes) 이 서로 클라이언트와 서버 역할을 동시에 네트워크 위에서 하게 된다. 즉, 이들은 고정된 IP 주소도 없고, 연결이 되었다 안 되었다 하는 불안정한 형태로 존재하는 분산된 리소스이다. 따라서, P2P 노드는 종래의 DNS 외부에서 운용될 수 밖에 없으며 강력한 중앙의 서버들의 영향력이 미치지 않는다. 이와 같이 P2P 네트워크 구성 모델은 보통 중앙 서버를 통하는 통신 형태의 클라이언트-서버 모델과는 구별된다
또한, 데이터 취득과 서비스 액세스에 중점을 둔 DONA (Data-Oriented (and beyond) Network Architecture) 시스템이 제안되었다. DONA 는 기존의 호스트 중심의 네트워크에서 데이터 중심의 네트워크로의 전환을 제안하고 있다. 이를 위한 방법으로서, DONA 는 기존의 DNS 네임을 플랫하고, 자기인증하는 (flat, self-certifying) 네임으로 대체하고, DNS 네임 레졸루션을 IP 층 상위에 존재하는 네임기반의 애니캐스트로 대체할 것을 제안한다. 플랫 네임의 사용은 식별을 더욱 어렵게 하지만 공식적인 인증을 보다 용이하게 한다.
상술한 현재 인터넷의 문제점의 해결을 위해서는 데이터 배포 중심의 새로운 네트워크로서, 시간과 공간의 제약 없이 저렴하게 구축하고 이용할 수 있는 네트워크가 요구된다. 구체적으로, 사용자는 언제 어디서나 쉽게 네트워크에 접속할 수 있어야 하고, 단말 사용자 (end-user) 와 네트워크의 접속은 다양한 무선환경 (IEEE 802.11 WiFi 무선랜, IEEE 802.15.1 Bluetooth, UWB 등) 에서 가능해야 한다.
또한, 사용자가 네트워크를 사용하는 비용은 추가로 소요되지 않아야 하고, 누구나 쉽게 참여하고 활용하여 새로운 서비스를 창출할 수 있는 개방적인 네트워크여야 한다.
또한, 사용자는 네트워크에서 원하는 데이터를 쉬게 찾을 수 있어야 하고, 데이터는 임의의 특정 소스에서가 아니라 네트워크 자체를 통해 안정적으로 얻을 수 있어야 한다.
또한, 네트워크를 구축하기 위한 설치 비용 역시 최소화할 수 있어야 한다.
본 출원에서는 상술한 내용과 같은 요구사항을 만족시킬 수 있는 새로운 네트워크 구조로서, DACON (Decentralized and Autonomous Content-centric Overlay Networking) 을 제안한다. DACON 의 목적은 사용자들이 어떤 컨텍스트 정보를 기반으로 자신이 원하는 콘텐츠를 쉽게 찾고, 이를 임의의 특정 소스가 아니라 네 트워크 자체로부터 손쉽게 얻을 수 있도록 하는 것에 있다. 또한, DACON 은 이러한 새로운 콘텐츠 네트워킹 서비스를 일반 인터넷 사용자들이 직접 구매하는 액세스 포인트 (access point; AP) 또는 홈 기지국 (base station; BS) 등의 장비를 통해 구축한다. 각각의 액세스 포인트나 홈 기지국은 사용자들의 자발적인 기증을 통해 이루어지게 되고, DACON 은 이들을 충분히 비집중화하게 서비스 네트워크를 구성하는 일반적인 메커니즘을 제공한다.
P2P 및 DONA 와 DACON 의 차이점은 다음과 같다.
P2P 는 사용자들이 자신의 데이터를 전송받는 도중에만 네트워크에 참여를 하기 때문에 안정적이지 못한 반면에 DACON 은 사용자들이 기증한 네트워크 인프라를 통해 안정적인 네트워크를 구성한다. 따라서, 높은 이용가능성을 제공할 수 있다.
또한, DONA 의 경우 서비스 제공자가 모든 인프라를 설치해야 하는 반면에 DACON 은 사용자가 직접 네트워크 리소스를 기여함으로써 이루어지는 네트워크이다. 따라서 네트워크 배치를 위한 비용이 상대적으로 훨씬 적게 소요된다.
또한, DONA 는 어떤 콘텐츠의 고유의 id (principal 이라고 부름) 를 통해 콘텐츠를 찾지만 DACON 은 사용자들에게 보다 친숙한 콘텐츠 이름 등의 컨텍스트 정보를 이용하여 콘텐츠를 검색한다.
DONA 는 네트워크 구성 시에 물리적인 위치 정보 등이 고려되지 않지만 DACON 은 기본적으로 각 네트워크 실체들의 위치 정보에 밀접하게 연관되어 구성된다.
DONA 는 글로벌하게 보증된 데이터 네트워크 서비스를 제공하지만 DACON 은 사용자 참여로 구성되는 특성상 모든 DACON 간의 글로벌 연결을 보증하지는 않는다. 즉, 서로 분리된 DACON 이 존재할 수도 있다.
DONA 는 네트워크 액세스 자체에 비용이 청구될 가능성이 높지만, DACON 은 사용자의 참여에 의해 이루어지는 만큼 DACON 사용자의 액세스는 무료로 이루어질 수 있다.
상기와 같은 P2P, DONA 및 DACON 의 차이점을 아래의 표로 정리하였다.
P2P DONA DACON
안정성 약함 강함 강함
관리자 없음 (개인 사용자) 서비스 제공자 없음 (개인 기증자)
배치 분산적 중앙 집중적 분산적이고 자치적
로케이터 고유의 id 고유의 id 컨텍스트
지역성 고려하지 않음 고려하지 않음 고려함
글로벌 연결성 보증 보증 제한적으로 보증
액세스 비용 인터넷 접속에 대한 비용 인터넷 접속 및
데이터 서비스에
대한 비용		 없음
수혜자 없음 서비스 제공자 콘텐츠 창작자 및
기증자
본 발명의 제 1 실시양태는 단말 사용자의 이동성을 통해 네트워크 토폴로지를 구축하는 네트워크 방법에 대한 것으로서, 단말 사용자와 접속가능한 호스트를 구비하는 네트워크에 있어서, 단말 사용자가 제 1 호스트에 접속할 때, 단말 사용자가 이전에 접속했던 제 2 호스트의 네트워크 식별자를 제 1 호스트에 전달하는, 네트워크 방법이다. 또한, 제 1 호스트는 제 2 호스트에 대하여 피어링을 질문하고 제 2 호스트가 피어링에 대하여 응답하는 경우에는, 제 1 호스트 및 제 2 호스트는 피어링 관계를 형성하는, 네트워크 방법이다. 또한, 제 1 호스트가 제 2 호스트에게 합류를 요청하고 제 2 호스트가 이를 승인하는 경우에는, 제 1 호스 트는 제 2 호스트에 지정된 제 2 포털에 합류하게 되는 네트워크 방법을 개시한다. 또한, 제 1 호스트에 지정된 제 1 포털과 제 2 호스트에 지정된 제 2 포털이 통합되어 서로의 하위 호스트들의 네트워크 식별자들을 공유하는, 네트워크 방법을 개시한다. 또한, 제 1 네트워크에 속하는 제 1 호스트에 지정된 제 1 포털과 제 2 네트워크에 속하는 제 2 호스트에 지정된 제 2 포털이 연합되어, 제 1 네트워크와 제 2 네트워크가 제 1 포털과 제 2 포털을 통하여 서로 연결되는 네트워크 방법을 개시한다.
본 발명의 제 2 실시양태는 제 1 실시양태에서 구축된 네트워크 토폴로지를 이용하여 단말 사용자가 원하는 데이터를 검색하는 네트워크 방법에 대한 것으로서, 단말 사용자가 원하는 데이터를 검색하는 경우에 검색의 타입에 따라서, 단말 사용자가 접속한 호스트에서만 검색을 실시; 단말 사용자가 접속한 호스트 및 단말 사용자가 접속한 호스트와 피어링 관계인 호스트들에서만 검색을 실시; 단말 사용자가 접속한 호스트가 접속된 포털에서 검색을 실시; 단말 사용자가 속한 네트워크의 모든 포털에서 검색을 실시; 또는 단말 사용자가 속한 네트워크 및 외부의 네트워크에서 검색을 실시하여 데이터를 검색하는 방법에 대한 것이다.
이때, 데이터의 검색은 단말 사용자가 입력하는 컨텍스트와 호스트들에 저장된 데이터에 관한 정보를 포함하는 메타데이터를 비교하여 이루어질 수도 있다.
본 발명의 제 3 실시양태는 단말 사용자와 접속가능한 하나 이상의 호스트; 하나 이상의 호스트 중 일부와 접속되는 하나 이상의 포털; 및 하나 이상의 포털과 접속되는 보더 포털을 구비하는 네트워크 시스템으로서, 네트워크 시스템은 보더 포털을 통하여 다른 네트워크 시스템과 연결되는, 네트워크 시스템에 대한 것이다.
이 네트워크 시스템의 하나 이상의 호스트는 데이터 및 상기 데이터를 나타내는 메타데이터를 포함하고, 하나 이상의 포털은 하위 호스트들이 포함하는 메타데이터를 포함하며, 보더 포털은 하위 포털들이 포함하는 메타데이터를 포함한다.
또한, 본 네트워크 시스템은 검색 수단을 더 포함하여 사용자가 원하는 데이터를 검색할 수 있다.
본 발명의 제 4 실시양태는 제 1 실시양태의 네트워크 방법을 수행하도록 하는 명령어들을 포함하는 기계판독 가능한 매체이다. 이를 통해, 제 1 실시양태의 네트워크 방법을 컴퓨터 등의 기계판독기를 이용하여 수행할 수 있다.
또한, 제 2 실시양태의 검색 방법을 수행하도록 하는 명령어들을 포함하도록 하는 기계판독 가능한 매체일 수도 있다.
본 발명의 제 5 실시양태는 DACON 시스템을 이용하는 영업방법에 관한 것으로서, 고객은 영업자가 설치한 영업장 내의 호스트를 통해 네트워크에 접속하여 네트워크 액세스 또는 데이터의 다운로딩을 할 수 있고, 영업자는 호스트를 이용하여 영업장에서 제공할 수 있는 서비스를 주문받을 수 있는, 네트워크를 이용한 서비스 주문 방법으로서, 고객이 개인용 단말기를 이용하여 호스트에 접속하는 단계; 영업장에서 제공하는 서비스를 호스트에서 주문하는 단계; 및 주문에 대하여 호스트가 응답하는 단계를 포함하는, 네트워크를 이용한 서비스 주문 방법이다.
또 다른 실시양태로서, 고객은 영업자가 설치한 영업장 내의 호스트를 통해 네트워크에 접속하여 네트워크 액세스 또는 데이터의 다운로딩을 할 수 있고, 영업 자는 고객이 네트워크에 접속하는 경우에 자신이 원하는 메시지를 고객에게 전달하는, 네트워크를 이용한 메시지 전달 방법으로서, 고객이 개인용 단말기를 이용하여 호스트에 접속하는 단계; 고객이 원하는 네트워크에 액세스 하는 단계; 고객이 원하는 데이터를 검색하는 단계; 또는 고객이 검색한 데이터를 다운로딩하는 단계에서, 영업자가 원하는 메시지를 고객의 개인용 단말기에 디스플레이하는, 네트워크를 이용한 메시지 전달 방법이 있다.
본 발명의 제 6 실시양태는, DACON 시스템에서 사용자가 데이터를 다운로딩하는 경우에 상기 데이터의 다운로딩에 대한 결제를 수행하는 방법으로서, 사용자가 개인용 단말기를 이용하여 상기 호스트에 접속하는 단계; 사용자가 원하는 데이터를 검색하는 단계; 사용자가 검색된 데이터에 대한 라인센스를 보유하고 있는지 여부를 확인하는 단계; 및 사용자가 검색된 데이터에 대한 라이센스를 갖고 있는 경우에는 사용자의 개인용 단말기를 통해 검색된 데이터를 다운로딩하고, 사용자가 검색된 데이터에 대한 라이센스를 갖고 있지 않은 경우에는 검색된 데이터의 다운로딩에 대한 과금을 수행하고 라이센스를 제공받아 개인용 단말기를 통해 검색된 데이터를 다운로딩하는 단계를 포함하는, 데이터의 다운로딩에 대한 결제를 수행하는 방법이다.
DACON 을 이용한 네트워크 환경의 구성을 통해 데이터 획득 중심의 네트워크를 안정적으로 형성할 수 있다. 또한, DACON 시스템의 형성을 위한 인프라의 구축은 참여자의 자발적인 기증을 통해 이루어지므로 인프라 구축에 대한 비용이 발생하지 않고, 중앙의 서비스 관리자 없이 분산적이고 자치적인 네트워크 환경이 마련될 수 있다.
또한, DACON 은 컨텍스트를 통해 데이터를 검색하므로 사용자가 보다 용이하게 데이터를 검색할 수 있고, DACON 의 지역적 특성에 따라 불필요한 연결이 배제되어 보다 효율적인 네트워크 구축이 가능하다.
이하에서는 도면을 참고하여 본 발명의 구체적인 실시예를 설명한다.
본 출원에 개시된 본 발명의 실시예는 본 발명의 기술적 사상을 설명하기 위하여 예시적으로 개시된 것으로서, 본 발명의 기술적 사상이 실시예에 한정되는 것은 아니다. 당업자는 본 발명의 기술적 사상 및 범주를 넘지 않는 범위에서 다양한 변형, 치환, 조정 등이 가능함을 명확하게 이해할 수 있을 것이다.
Ⅰ. DACON 의 실체적 구성
먼저, DACON 을 구성하는 각각의 요소에 대하여 도 1 을 참고하여 설명한다.
1. DACON 사용자 ( end - user )
DACON 사용자 (11) 라 함은 DACON 서비스를 실제로 이용하는 사용자들과 그 사용자들의 단말을 총칭한다. DACON 은 다양한 통신 환경에서 접속이 가능하므로, 매우 다양한 이종 (heterogeneous) 의 단말을 사용하는 DACON 사용자가 존재할 수 있다. 각 DACON 사용자는 서로 다른 리소스 (예를 들어, 컴퓨팅 파워, 메모리, 저장체, 디스플레이 등) 을 가질 수 있다. 또한, 각 DACON 사용자 (11) 는 다양한 통신 메커니즘 (예를 들어, 직접 케이블 연결, 이더넷/IP, IEEE 802.11 WiFi, IEEE 802.15.1 Bluetooth, IEEE 802.15.3 UWB 등) 을 통해 DACON 에 접속할 수 있다.
2. DACON 호스트
DACON 호스트는 (12) 는 참여자의 자발적인 기증으로 네트워크 구성에 참여하게 되는 것으로서, DACON 을 구성하는 핵심 하드웨어 디바이스 및 그 위에서 구동되는 소프트웨어를 의미한다. 이하에서는 단순히 호스트라고 부를 수 있다.
DACON 에서 호스트는 다음과 같은 역할을 수행한다.
먼저, DACON 사용자 (11) 에게 DACON 액세스 서비스를 제공한다. 또한, DACON 사용자 (11) 가 요청한 콘텐츠를 해당 콘텐츠와 연관된 컨텍스트 정보를 바탕으로 DACON 내에서 검색하여 DACON 사용자 (11) 에게 제공한다. DACON 사용자 (11) 가 요청한 컨텍스트 정보와 이에 연관된 다른 컨텍스트 정보를 주소분해 (resolve) 하고 추정하여 관리한다. 또한, DACON 사용자 (11) 가 요청한 콘텐츠를 캐싱 (caching) 한다.
호스트 (12) 는 미리 설정된 개수의 피어 호스트들을 관리하고, 모든 호스트 (12) 는 하나의 담당 DACON 포털 (13) 을 설정해 두고 있다.
하나의 DACON 내의 호스트들 (12) 은 모두 동질한 네트워크 층 위에서 오버레이되어 있다고 가정한다. 이에 따라, 하나의 DACON 내에서 어떤 호스트의 네트워크 식별자, 예를 들어 네트워크 어드레스를 알 수 있다면 두 호스트는 바로 통신을 할 수 있다.
3. DACON 포털
DACON 포털 (13) 은 복수의 DACON 호스트 (12) 를 차일드 (child) 로 두는 구성으로서, 이하에서는 단순히 포털이라고 부를 수 있다.
포털 (13) 은 자신의 차일드 (child) 에 있는, 즉, 자신을 담당 포털로 설정하고 있는 모든 호스트들의 메타데이터 정보를 알고 있어야 한다. 하나의 DACON 에는 하나 이상의 포털이 존재하며, 이 포털들은 풀-메쉬 (full-mesh) 형태로 서로 통신이 가능해야 한다. 즉, 하나의 DACON 내의 임의의 포털은 자신이 속한 DACON 내의 자신 외의 다른 모든 포털들을 알고 있어야 한다.
4. DACON 보더 포털
DACON 보더 포털 (14) 은 DACON 간의 연결을 실행시켜 주는 구성으로서, 이하에서는 단순히 보더 포털이라고 부를 수 있다.
DACON 은 임의의 포털의 입장에서 볼 때, 다른 호스트들을 같은 DACON 내의 호스트와 다른 외부 DACON 에 속한 호스트로 나누어 간주하는 계층적 개념을 갖고 있는데, 이때 서로 다른 DACON 들은 보더 포털을 통해서만 연결된다. 만일 서로 다른 DACON 이 각각 다른 이종의 네트워크 위에 오버레이로 구성되어 있다고 하더라도 포털들 사이에서는 서로 통신할 수 있는 메커니즘이 제공될 수 있어야 한다. 이것이 불가능하다면 두 DACON 은 서로 연결될 수 없다. 이에 대해서는 이하에서 자세히 설명하도록 한다.
Ⅱ. DACON 의 계층 구조
앞에서 설명한 바와 같이 DACON 에서는 각 호스트 (12) 들이 후술되는 과정에 따라 지역적으로 인접하게 되고, 미리 설정된 메트릭을 만족하는 범위 내에서 자율적으로 하나의 DACON 을 구성하게 되는데, 이렇게 구성된 하나의 DACON 을 개념상 로컬 DACON 이라고 한다. DACON 에는 네트워크 아키텍처 또는 기술이라는 의미와 이와 같은 DACON 기술로 구성된 하나의 물리적 호스트들의 집합이라는 의미가 동시에 존재한다. 복수 개의 DACON 들은 서로 다른 DACON 들과는 공유 링크를 통해 연결되고, 하나의 DACON 에 속한 호스트의 입장에서 이 다른 DACON 을 외부 DACON (15) 이라고 한다. 공유 링크는, 모든 포털들이 풀-메쉬로 연결되어야 하는 로컬 DACON 내의 포털들과는 다르게, 보더 포털 (14) 들 사이의 연결만으로 구성된다.
DACON 을 계층적으로 구성하는 이유는 다음과 같다.
먼저, 기존의 구조적 P2P 나 DONA 와 같은 경우, 특정 콘텐츠를 찾기 위해 필요한 정보는 그 콘텐츠에 대한 고유의 id 이다. 하지만 DACON 에서는 그 콘텐츠를 설명하는 다양한 메타데이터 정보를 바탕으로 콘텐츠를 찾으며 이 메타데이터 정보는 한 콘텐츠당 매우 다양할 수 있으며 심지어 같은 컨텍스트도 사용자마다 서로 다르게 표현할 수 있다 (예를 들어, "Die Hard 4" 또는 "Die Hard Four"). 이런 수많은 메타데이터 정보를 네트워크상의 모든 호스트들이 알고 관리해야 한다면 확장성에 심각한 문제가 오게 된다. 따라서 이를 분할하여 관리하기 위해 계층적 아키텍쳐가 필요하다.
현재 예상되는 DACON 의 초기 배치 시나리오에 따르면 DACON 은 사용자들이 그들의 생활에서 콘텐츠 서비스의 필요성을 느끼지만 기존의 인터넷 접속이 제약적인 모바일 환경이나 실외 환경에서 별도의 비용 부담 없이 콘텐츠 서비스를 이용하 기 위해 사용될 가능성이 크다. 미래의 인터넷 환경은 언제 어디서나 네트워크에 접속하여 서비스를 이용할 수 있는 유비쿼터스 액세스 환경이 강조된다. DACON 호스트는 사용자의 무선 DACON 액세스 서비스를 제공하기 때문에 호스트들은 미래의 인터넷에서 유비쿼터스 컴퓨팅을 제공하는 훌륭한 인프라스트럭쳐가 될 것이다. 또한, 호스트들은 사용자들의 요구만이 아니라 호스트들을 통해 부가 수익을 올리고 자신이 원하는 홍보 등을 하거나 다른 서비스 애플리케이션을 고객에게 제공하고자 하는 참여자들의 자발적인 참여에 의해 구성된다. 이는 사용자들이 많이 존재하는 환경에 호스트들이 많이 설치되는 효과를 발생시킬 것이다. 다시 말해, 이는 각 호스트들이 실제 사용자로의 액세스 서비스가 제공되는 지역에 지역적으로 집중되어 배치될 확률이 크다는 것을 의미한다. 이때, 지역적으로 멀리 떨어진 호스트들이 같은 DACON 을 구성하고 있다면 그 DACON 의 성능을 저하시킬 위험이 크다. 또한, 특정 지역의 DACON 은 그 지역에 연관되는 컨텍스트 정보를 관리하고 있을 확률이 매우 높으며, 사용자들은 그 해당 호스트가 위치한 지역에 실제로 있을 때 그 정보가 유용할 확률이 매우 크다. 따라서 하나의 평면적인 네트워크가 아닌, 전체 네트워크의 지역성을 고려하여 여러 로컬 DACON 으로 분리하여 네트워크의 성능을 높이고, 불필요한 정보의 전파를 막기 위채 DACON 의 계층적 아키텍쳐를 도입한다.
DACON 은 기본적으로 어떤 미래 인터넷 네트워크 층 위에서 오버레이 네트워크로 구성된다. 하지만, 미래 네트워크 환경은 여러 층에 걸친 다양한 이종의 네트워크로 구성될 가능성이 크다. 예를 들어, 어떤 지역 내에 IEEE 802.11 로 구성된 무선 메쉬 네트워크와 3G 셀룰러 네트워크가 공존할 수 있으며 미래 인터넷 환경에서는 이런 다양한 네트워크 사이의 상호운용성이 중요해질 것이다. DACON 에서는 이런 이종의 각각의 네트워크들을 하나의 DACON 으로 각각 구성하고 이들의 외부 링크 연결을 통해 연동하는 방식으로 다양한 이종의 네트워크 사이의 데이터 서비스를 제공할 수 있다. 또한, DONA, P2P 오버레이 네트워크 등의 다른 콘텐츠 중심의 네트워크 사이에서도 포털들 사이에서만 상호운용성을 위한 기능을 제공함을 통하여, 이런 상이한 네트워크를 마치 외부 DACON 으로 간주하여 시스템을 구성할 수 있다.
Ⅲ. 사용자-지원 DACON 포메이션 ( User - assisted DACON Formation ; UDF )
1. UDF 의 개관
DACON 은 그 구성상, 참여자가 가장 기본이 되는 호스트들을 직접 네트워크에 기여를 하여 구성되는 것을 기본 가정이자 목표로 한다. 임의의 호스트가 새로 설치되면, 이 호스트는 새로운 DACON 을 구성하거나 기존의 다른 DACON 의 일부로 참여할 수 있어야 한다. 이는 마치 이동통신 단말이 처음 전원을 켰을 때 랜덤 액세스 등의 방법을 통해 기지국을 찾는 것과 유사한 메커니즘이 제공되어야 함을 의미한다.
하지만 호스트들은 기본적으로 이를 알기 어렵다. 지금까지의 다른 네트워크의 예를 생각해 보면, 자신의 무선 통신 메커니즘이나 플러딩 (flooding) 등을 통해 주변의 다른 호스트들과 통신을 하고 이를 통해 다른 네트워크를 파악하거나, 다른 네트워크 셋업을 위한 정보를 알고 있는 어떤 다른 서버에 접속해 정보를 얻 는 방법을 고려할 수는 있다.
그러나, 기본적으로 각 호스트들은 그들의 위치나 노드의 역량을 알기 어렵기 때문에 어떤 일관된 공유 매체 통신이 가능하다는 보장을 하기 어렵다. 임의의 호스트 A 와 B 는 각각의 무선 통신 메커니즘으로는 서로 전파 범위 밖에 위치하기 때문에 숨겨진 관계일 수 있지만, 인터넷 접속으로는 직접 통신할 수 있을 수도 있다. 그러나, A, B 가 지역적으로 인접하더라도 서로 다른 ISP 를 통해 인터넷 서비스를 제공받고 있을 수도 있으며 이 경우 플러딩은 현실적으로 비효율적인 방법이 된다.
또한, DACON 은 참여자의 자발적 참여를 전제로 하고 있기 때문에 어떤 중앙집중적인 서비스 제공자나 관리권한을 가진 권한있는 관리자를 상정하기 어렵다. 따라서, 네트워크 셋업을 위한 다른 서버의 존재를 가정하기 어렵다. 또한, 이런 서버에 어떻게 접속해야 하는지를 알 방법도 없다 (DSN 서버의 경우 관리자에게 물어보면 되지만, DACON 에는 물어볼 수 있는 네트워크 관리자가 존재하지 않는다).
따라서, DACON 은 각 호스트들이 자치적인 권한을 가지면서 스스로의 판단으로 네트워크를 구성할 수 있는 메커니즘이 제공되어야 하는데, 이를 사용자-지원 DACON 포메이션 (User-assisted DACON Formation; UDF) 프로세스라고 정의한다.
UDF 에서는 호스트가 기존 DACON 에 대한 지식을 습득하기 위한 방법으로 DACON 사용자들의 이동성 (mobility) 그 자체를 활용한다. 모든 사용자는 자신이 마지막으로 서비스를 받은 호스트의 네트워크 어드레스를 기억하고 있으며 이를 새로운 호스트와의 연관을 맺을 때 알려주게 된다. 다시 말해, 임의의 호스트는 자신을 통해 서비스를 받으려고 접속한 사용자를 통해 다른 네트워크의 토폴로지에 대한 정보를 얻게 된다. 사용자가 이전에 다른 호스트를 통해 DACON 서비스를 받다가 다시 가까운 일정 기간 내에 다른 호스트에 접속했다면 해당 사용자는 비교적 인접한 호스트에서 기존 서비스를 받았다는 것을 의미하며, 이를 통해 DACON 셋업 한다면 네트워크의 구성을 보다 더 지역성에 밀접하게 하는데 기여하게 된다.
2. UDF 에 대한 데이터구조
DACON 의 오버레이 구조를 구성하기 위하여 각 호스트는 다음의 데이터구조를 가진다.
먼저, NHP (Next-hop to Portal) 는 각 호스트의 주변에 위치한 호스트들의 어드레스 정보를 저장한다. 각 호스트는 하나의 포털을 자신의 지정 포털로 설정하는데, 이 지정 포털에게 메시지를 보내기 위하여 오버레이 상에서 메시지를 보내야 하는 넥스트 홉 (next-hop) 피어 호스트의 네트워크 어드레스를 NHP (Next-hop to Portal) 에 저장한다. 이는 기존 인터넷 라우팅에서 디폴트 라우팅과 유사한 역할을 한다.
PL (Peer List) 은 각 호스트의 피어로 설정된 호스트들의 네트워크 어드레스를 저장한다. 구체적으로, 각각의 호스트들은 다른 호스트들을 자신의 피어로 설정할 수 있으며 PL 에 이 피어들의 네트워크 어드레스들을 저장할 수 있다. PL 은 각 호스트별로 각자의 능력에 따라 유한한 개수를 가지게 되는데, PL 이 가득 찬 경우에 새로운 피어를 어떻게 처리할 것인지는 각 호스트의 정책에 따른다. 하지만 자신이 NHP 에 해당하는 피어는 PL 에서 삭제되면 안 된다. 각 PL 의 첫 번째 인덱스에는 자기 자신을 기록하게 된다.
각 호스트의 피어는 컨텍스트 관리 과정에서 사용되는데 이는 후술하기로 한다.
MNP (Maximum Number of Peers) 는 임의의 호스트가 최대로 설정할 수 있는 피어의 개수로서, 각 호스트별로 독자적으로 설정할 수 있는 값이다.
LPL (Local Portal List) 은 호스트들 중에서 포털들에만 존재하는 데이터구조이다. 임의의 포털이 알고 있는 같은 DACON 내의 모든 다른 포털들의 네트워크 어드레스들이 LPL 에 저장된다. 이는, 하나의 DACON 내의 모든 포털들 사이의 풀-메쉬 접속을 위한 것으로서, 후술할 컨텍스트 검색 알고리즘과 관계가 있다. 각 LPL 의 첫 번째 인덱스에는 항상 자기 자신을 기록한다.
EBPL (External Border Portal List) 는 보더 포털만이 관리하는 데이터구조로서, 임의의 보더 포털이 알고 있는 다른 외부 DACON 의 보더 포털들의 리스트를 관리하기 위해 존재하는 데이터구조이다.
PIF (Portal Inclination Factor) 는 각 호스트들의 일종의 성향을 나타내는 값이다. PIF 는 DON'T CARE (0), FAVOR (1), INSIST (2) 의 3 가지 중 하나의 값을 갖는다. 모든 호스트들은 처음에는 기본적으로 0 의 값을 가지고 시작하는 것으로 가정한다. 다만, 이 값은 호스트를 기여한 참여자가 자유롭게 설정할 수도 있다. PIF 값은 후에 UDF 의 동작을 결정하는 요소로 사용된다.
ND (Number of Decendants) 는 자신을 NHP 로 설정하고 있는 다른 호스트들의 수를 나타낸다. Joining_Accept, Leave 시에 계산되어 갱신된다.
ND 임계치는 후술할 UDF 알고리즘에서 사용할 값으로서, ND 값이 ND 임계치 이상으로 증가할 경우 PIF 값을 변경시키는데 사용된다.
3. 사용자의 지원에 의한 토폴로지 습득
임의의 사용자가 DACON 에 액세스해서 서비스를 받으려면, 어떤 호스트에 연관해야 한다. 이 연관을 맺는 방법은 다양할 수 있다. 예를 들어, L2 이하가 802.11b/g 이던, Bluetooth 이던, L3 가 IP 네트워크이던 아니면 다른 방식이던 간에 서로의 애플리케이션의 층으로 메시지를 전달할 수 있으면 된다.
연관 (association) 은 사용자가 연관 메시지를 전달함으로써 이루어지는데 이를 통해 임의의 호스트가 다른 호스트를 알 수 있게 된다. 도 2 는 이러한 연관 과정을 나타내고 있다.
도 2 에 개시된 바와 같이 종래의 호스트와 접속하던 사용자가, 그 후 이동하여 다른 호스트와 접속하게 되는 경우, 새로운 호스트에 연관 메시지를 보내게 된다. 이때, 새로운 호스트는 사용자가 종래 접속했던 호스트에 대한 정보들을 습득할 수 있게 된다.
연관 (Associate) 메시지는 다음과 같은 인자를 가진다.
인자 설명
idEndUser 사용자와 연관하는 호스트가 구별할 수 있는 고유값으로서, 다양한 가능성 (사용자 디바이스의 MAC 어드레스 등을 사용 가능) 이 존재할 수 있다.
addrPrevHost 사용자가 이전에 서비스를 받은 호스트의 네트워크 어드레스이다.
valPrevPIF 사용자가 이전에 서비스를 받은 호스트의 PIF 값이다.
idPrevNetwork 사용자가 이전에 서비스를 받은 호스트의 네트워크 층의 타입이다.
현재 호스트의 네트워크 층과 상이한 타입이라면 (heterogeneous 네트워크라면) 공유관계를 맺기 위해 사용한다.
4. UDF 오버롤 알로리즘 ( UDF Overall Algorithm )
어떤 호스트 S 가 다른 호스트 R 의 네트워크 어드레스를 알게 되었을 때, 호스트 S 는 다음과 같은 알고리즘을 통해 이후의 동작을 결정한다.
if (! External_Test()) // RTT, GPS좌표, network type등으로 결정
switch (S.PIF)
case DON'T_CARE:
if (S.NHP == null ) //자기 자신이 portal(초기상태)
Joining_Request(R);
else
Peering_Query(R);
break;
case FAVOR:
if (S.PIF < R.PIF)
Joining_Request(R);
S.PIF <- DON'T_CARE;
else
Joining_Suggest(R);
break;
case INSIST:
Uniting_Request(R);
break;
end of switch
else // Allying
if (S.NHP == null) // S가 portal인 경우
Allying_Request(R);
else
Peer_Report(S.NHP) // S의 portal에게 R에 대해 알린다.
PIF 값은 모든 호스트가 처음에는 DON'T_CARE 로 가정하지만 각 호스트를 기 증한 참여자가 자유롭게 설정할 수도 있다. 또는, 참여자는 ND 임계치 값만 조정할 수도 있다.
일반적으로, PIF 값은 다음과 같이 변화한다.
먼저, 다른 호스트의 가입을 받은 경우, 이전 상태가 DON'T_CARE 였다면 FAVOR 로 변경한다. 다른 호스트 아래로 가입을 한 경우 DON'T_CARE 로 변경한다. 상태가 FAVOR 일 경우 ND 값이 미리 설정한 ND 임계치 이상이 되면 INSIST 로 변경한다.
5. 피어링 절차 ( Peering Procedure )
이하에서는, 도 3 을 참고하여 피어링 (Peering) 절차를 설명한다.
피어링은 한 호스트와 다른 호스트가 동등하게 상대방을 "콘텐츠 질문 (content query) 을 할 수 있는 대상" 으로 설정하는 과정이다. 피어링 과정은 요청-승인의 과정이 아니라, 상대방에 대한 정보를 일단 물어보고 상대방으로부터 받은 상대의 정보에 따라 상대를 피어로 설정할지 말지를 결정하는 과정이다. 피어링 과정에서 상대방으로부터 얻어내는 데이터는 상대방의 128 바이트 Min-Wise 독립 순열 벡터 (Independent Permutation Vector) 이다.
도 3 의 1) Peering_Query 단계에서는 호스트 A 가 호스트 B 에게 피어의 설정 여부를 질문한다.
Peering_Query 메시지 인자는 다음과 같다.
인자 설명
addrQuerist 질문자(호스트 A) 의 네트워크 어드레스이다.
addrReplier 응답자 (호스트 B) 의 네트워크 어드레스이다.
valQueristPIF 질문자 (호스트 A) 의 PIF 값이다.
호스트 B 는 호스트 A 의 존재를 모르고 있었을 수도 있기 때문에 호스트 B 의 UDF 판단을 돕기 위한 값이다.
이에 대하여 호스트 B 는 도 3 의 2) Peering_Reply 단계에서 호스트 A 의 질문에 대하여 호스트 A 와의 피어링 설정 여부에 대한 답을 전송한다.
Peering_Reply 메시지의 인자는 다음과 같다.
인자 설명
addrReplier 응답자 (호스트 B) 의 네트워크 어드레스이다.
addrQuerist 질문자 (호스트 A) 의 네트워크 어드레스이다.
valReplierPIF 응답자 (호스트 B) 의 PIF 최신 값이다.
vecMIP 응답자 (호스트 B) 의 MIP 벡터이다.
128 바이트 (2 바이트*64) 의 크기를 가진다.
Peering_Reply 을 받은 후, 호스트 A 는 현재 PL 의 피어 수가 MNP 보다 작으면 새로운 피어를 PL 에 등록하고, MNP 가 이미 찼다면 여러가지 요소를 고려하여 가장 효율이 떨어지는 피어를 삭제한다.
피어링 과정 자체는 두 호스트 사이에서 이루어지지만, 피어링의 중요한 기능 중 하나는 서로의 포털이 상대방 포털의 존재를 알게 하는 것에 있다. 이는 도 3 의 3) Peer_Report 단계를 통해 수행된다. 어떤 상대 호스트를 피어로 설정한 호스트 (호스트 A; 도 3) 는 새로 알게 된 피어의 정보를 자신의 포털 (포털 A) 에게 Peer_Report 메시지를 통해 알려야 한다. Peer_Report 메시지는 호스트 A 로부터 각 호스트의 NHP 를 통해 전달되게 된다. 즉, Peer_Report 메시지를 받은 호스트 (호스트 A2) 는 자신이 포털이 아니라면 계속해서 해당 메시지를 자신의 NHP 로 포워딩해야 한다.
Peer_Report 메시지의 인자는 다음과 같다.
인자 설명
addrReporter 보고자 (호스트 A) 의 네트워크 어드레스이다.
addrPeer 새로운 피어 (호스트 B) 의 네트워크 어드레스이다.
valPeerPIF 새로운 피어 (호스트 B) 의 PIF 값이다.
idPeerNetwork 피어 호스트의 네트워크 층의 타입이다.
현재 호스트의 네트워크 층과 다른 타입이라면 (heterogeneous 네트워크라면) 공유 관계를 맺기 위해 사용한다.
Peer_Report 메시지를 받은 포털은 도 3 의 단계 4) Portal_Report 와 같이 해당 피어 (호스트 B) 에게 Portal_Report 메시지를 전송하여 자신의 존재를 알려주게 된다. Portal_Report 메시지를 받은 피어 (호스트 B) 는 이 메시지를 다시 NHP 를 통해 자신의 포털 (포털 B) 에 전송하게 된다 (도 3 의 단계 5) Portal_Report). Portal_Report 메시지를 받은 포털 (포털 B) 은 새로운 다른 포털 (포털 A) (혹은 자기 자신이거나, 이미 알고 있는 포털일 수도 있다) 의 네트워크 어드레스를 알게 될 수 있다.
Portal_Report 메시지 인자는 다음과 같다.
인자 설명
addrPortal 메시지를 보내는 포털 (포털 A) 의 네트워크 어드레스이다.
addrPeer 메시지를 처음 받는 피어 (호스트 B) 의 네트워크 어드레스이다.
valPortalPIF 메시지를 보내는 포털 (포털 A) 의 PIF 값이다.
한편 도 3 의 단계 2) 에서 Peering_Reply 를 받은 후, 호스트 A 는 RTT 나 물리적 거리, MIP 등의 메트릭을 통해 호스트 B 가 피어로서 적합하지 않다고 판단할 수도 있다. 이때, 그 이유가 공유 (alliance) 와 관계된 이유라면 자신의 PL 은 갱신하지 않고 (피어링을 하지 않은 채) 단순히 포털에 Peer_Report 메시지를 보낼 수 있다. 이는 후에 공유 관계를 맺을 수도 있는 포털의 정보를 얻기 위해 자신의 포털에 Portal_Report 메시지를 전달하는 것이다. 이를 통해, 공유 관계를 맺을 수 있는 외부 포털의 어드레스도 알 수 있게 된다.
6. 합류 절차 ( Joining Procedure )
이하에서는, 도 4 를 참고하여 합류 절차를 설명한다.
합류는 어떤 한 호스트가 다른 호스트에 종속적인 관계로 들어가는 과정을 의미한다. 이때, 합류를 맺는 것은 기본적으로 상대방을 서로의 피어로 인정하는 것을 암묵적으로 포함한다. 합류는 원칙적으로 종속을 수용하는 쪽의 포털의 승인을 통해 이루어지게 된다.
먼저, 도 3 에서 호스트 A 가 호스트 B 에 합류하기를 원하는 경우, 1) Joining_Request 단계에서 호스트 A 는 호스트 B 에게 Joining_Request 메시지를 보낸다.
한편, 어떤 호스트는 상대방에게 합류하는 것보다 상대방으로 하여금 자신에게 합류하게 하는 것이 더 바람직하다고 판단할 수도 있는데, 이 경우에는 Joining_Suggest 메시지를 보내게 된다. 해당 Joining_Suggest 메시지를 받은 호스트가 합류할지의 여부는 그 호스트의 자치적인 판단에 맡긴다. 예를 들어, ND 값이 일정값 이상이면 더 이상 합류를 받지 않을 수도 있다.
Joining_Suggest 메시지의 인자는 다음과 같다.
인자 설명
addrSuggester 권유자의 네트워크 어드레스이다.
addrSuggestee 권유를 받는 호스트의 네트워크 어드레스이다.
valSuggesterPIF 권유자의 PIF 값이다.
Joining_Request 를 받은 호스트 B 는 해당 호스트 A 를 자기의 피어로 인정하는데 문제가 없다면 자신의 NHP 를 통해 자신의 포털 (포털 B) 에 Joining_Request 메시지를 전달한다 (도 3 의 2) Joining_Request 단계). 이때, 매 홉 (hop) 마다 자신의 어드레스를 메시지에 추가시켜야 한다. 특히, 가장 최근에 메시지를 보내는 호스트가 가장 앞에 오도록 한다.
Joining_Request 메시지의 인자는 다음과 같다.
인자 설명
addrRequester 요청자 (호스트 A) 의 네트워크 어드레스이다.
listAddresses 요청을 받은 호스트 (호스트 B) 부터 메시지가 전달되어 오는 동안 거친 호스트들 (호스트 B2,…) 들의 어드레스들의 리스트이다.
가장 최근에 메시지를 보내는 호스트가 가장 앞에 기술된다. 예를 들어, 도 3 에서 메시지가 포탈 B 에 도착했을 때는 [address Bn-1,…, address B2, address B] 순으로 기술된다.
valRequesterPIF 요청자 (호스트 A) 의 PIF 값이다.
valRequesterND 요청자 (호스트 A) 의 ND 값이다.
Joining_Request 를 받은 포털 (포털 B) 은 승인 여부를 결정하고 승인을 결정하면 Joining_Accept 메시지를 기록된 역경로로 전달한다 (도 4 의 3), 4) Joining_Accept 단계). 이 과정에서 중간에 거치는 모든 호스트들의 ND 값을 메시지의 valRequesterND 값 만큼 더한다.
Joining_Accept 메시지의 인자는 다음과 같다.
인자 설명
addrRequester 요청자 (호스트 A) 의 네트워크 어드레스이다.
listAddresses 처음에는 Joining_Request 메시지가 거쳐 온 호스트들의 리스트로 시작하여 (포털 B 에 Joining_Request 메시지가 도착했을 때의 listAddresses 인자 값을 그대로 처음에는 쓰면 된다) 다시 역으로 호스트 B 로 돌아가기 위한 주소값이 적힌다.
한 호스트를 지날 때마다 자기 어드레스를 앞에서 삭제해 나간다.
addrPortal 승인을 한 포털 (포털 B) 의 어드레스이다.
추후 새로 합류한 호스트 A 의 이전 포털 (포털 A) 은 leave 메시지를 받으면 해당 호스트 A 의 정보를 삭제해야 하는데, 포털 B 와 포털 A 가 사실은 동일한 포털일 수도 있고, 이 경우에는 정보를 삭제하면 안된다. 따라서, 이를 확인하기 위해 이 값이 필요하다.
valRequesterND 요청자 (호스트 A) 의 ND 값이다.
포털 B 로부터 호스트 B 까지 Joining_Confirm 메시지가 전달되는 모든 호스트들은 해당 값을 자신의 ND 값에 더해야 한다.
합류를 요청했던 호스트 (호스트 A) 가 Joining_Accept 메시지를 받으면, 현재 자신의 NHP (호스트 A2) 에게 leave 메시지를 보낸다 (도 4 의 5) leave 단계). 만일, 이때 현재 NHP 값이 null 이라면 자신이 포털인 상황이고, 그렇다면 leave 메시지를 LPL 에 있는 모든 다른 포털들에게 보낸다. 이후, NHP 값을 호스트 B 의 어드레스로 바꾼다.
leave 메시지는 각 호스트들을 거쳐 원래의 포털 (포털 A) 에 도착한다. 이때, 중간에 거치는 모든 호스트들의 ND 값을 메시지의 valRequesterND 만큼 빼 주어야 한다.
leave 메시지를 받은 포털 (포털 A) 은 다음과 같은 동작을 수행한다.
먼저, addrPortal 값을 확인하고 이것이 자기 자신의 어드레스와 같다면, 자 신의 ND 값을 valRequesterND 값만큼 감소시키고 (승인시에 이미 증가했기 때문에) 다른 동작은 하지 않는다. addrRequester 가 LPL 에 있는지 확인하고, 만일 있다면 이 메시지는 자신의 DACON 내의 다른 포털이 보낸 메시지이므로 해당 포털을 LPL 에서 삭제하고 끝낸다. 위의 경우들이 아니라면 ND 값을 조정하고 해당 호스트로부터 알려진 모든 메타데이터를 삭제한다 (이때, Metadata_Report 메시지를 이용하여 이전해 가는 호스트에 대해 알고 있던 메타데이터 정보를 새로운 포털에 전달해 줄 수도 있다. 그러나, 이는 엄밀히 말해 UDF 의 과정은 아니다).
합류는 어떤 호스트가 NHP 를 변경하기 위해서도 사용될 수 있다. 만일 어떤 호스트가 어떤 다른 방법 (사용자 이동이나 Joining_Accept 메시지의 전달 도중에) 으로 자신의 포털을 알게 된 경우, 자신의 NHP 를 이 포털의 어드레스로 바로 변경할 수도 있다. 하지만, 이 과정은 첫 listAddresses 를 새 포털의 어드레스로 하는 Joining_Request 를 통해 이루어져야 한다. 즉, 새로운 포털에 직접 Joining_Request 메시지를 보내야만 한다.
이는 합류 과정도 일종의 피어링이기 때문에 새로운 포털의 승인이 필요하기 때문이다. 또한, leave 메시지 등을 통해 ND 값의 조정도 자동적으로 이루어지게 된다.
한 가지 중요한 것은, 합류하고자 하는 호스트가 종전 포털에 leave 메시지를 보내더라도 기존의 피어링 관계는 그대로 유지된다는 것이다. 피어링은 질문을 보낼 대상을 선정하는 기준이 되는 것이고, UDF 상의 토폴로지는 전체 DACON 상에서의 계층적 구조를 구성하는 기준이 되는 것으로서 그 개념이 상이하다.
7. 통합 ( uniting )
통합은 기존에는 서로 다른 DACON 에 있던 두 포털이 통합하여 하나의 DACON 을 구성하는 과정이다. 따라서, 통합 이후에는 서로 다른 두 DACON 에 각각 존재하던 모든 포털들이 하나의 DACON 의 포털이 될 수 있다. 각각의 포털들은 사용자의 이동이나 앞서 피어링 과정에서 설명한 Portal_Report 메시지 등을 통해 다른 포털을 알게 된다.
한편, 통합 과정에서 메시지를 주고 받는 대상은 포털이어야 한다.
이하에서는, 도 5 를 참고하여 통합의 과정을 설명한다.
먼저, 통합을 요청하는 포털 A 는 포털 B 에게 Uniting_Request 메시지를 보낸다 (도 5 의 1) Uniting_Request 단계). 해당 메시지에는 현재 포털 A 의 LPL 이 함께 간다.
Uniting_Request 메시지의 인자는 다음과 같다.
인자 설명
addrRequester 통합 요청자 (포털 A) 의 네트워크 어드레스이다.
addrConfirmer 요청을 받은 포털 (포털 B) 의 네트워크 어드레스이다.
listLPL 요청자 (포털 A) 의 LPL 값들의 리스트이다.
통합 요청을 받은 포털 B 는 LPL 사이즈와 기타 메트릭에 기반하여 수락 여부를 결정한다. 수락을 하면 자신의 현재 LPL 을 포함시켜 Uning_Accept 메시지를 포털 A 에 보낸다 (도 5 의 2) Uniting_Accept 단계).
Uniting_Accept 메시지의 인자는 다음과 같다.
인자 설명
addrConfirmer 요청을 수락한 포털 (포털 B) 의 네트워크 어드레스이다.
addrRequester 요청을 한 포털 (포털 A) 의 네트워크 어드레스이다.
listLPL 요청을 수락한 포털 (포털 B) 의 LPL 값들의 리스트이다.
포털 A 와 포털 B 의 통합이 성립된 후, 각 포털들은 전달받은 상대방의 LPL 을 Add_LPL 메시지에 넣어서 자신의 현재 LPL 의 모든 포털들에게 전달한다 (도 5 의 3) Add_LPL 단계). 이 후, 자신의 LPL 역시 상대방의 LPL 과 통합한다.
LPL 을 전달받은 포털들은 해당 LPL 을 자신의 LPL 에 통합하여 업데이트한다. 현재 LPL 은 최대값이 없다. 다만, 어떤 임계값이 연합 수행 여부를 결정하는 요소가 될 수는 있다.
8. 연합 절차 ( Allying Procedure )
연합은 지역적으로 멀리 떨어져 있거나, 성능상 하나의 DACON 으로 묶기에는 부담이 있는 두 DACON 에 각각 존재하는 포털들이 서로 상대방의 DACON 에 대해 포털들 사이에서만 연합 관계를 맺는 것을 의미한다. 같은 DACON 내의 모든 포털들은 모두 LPL 을 공유하며 다른 모든 포털들을 알고 있는 대신에, 연합 관계에 있는 보더 포털들은 서로 상대방의 보더 포털만을 알고 있다.
연합 관계에 있는 포털들은 질문의 전달만이 아니라 콘텐츠의 전달도 서로의 보더 포털을 통해서만 수행한다. 다시 말해, DACON A 및 DACON B 의 2 개의 DACON 이 있고 이 둘이 서로 연합 관계를 맺은 보더 포털들에 의해 연결되어 있는 연합 DACONs 인 경우, DACON A 의 호스트 A 와 DACON B 의 호스트 B 는 보더 포털을 통해서만 통신을 할 수 있다. 이는 앞서 설명한 바와 같이, DACON 을 지역 성을 고려하여 로컬 DACON 으로 분리함으로써 네트워크의 성능을 높이고 불필요한 정보의 전파를 막음과 동시에 필요시에 보더 포털을 통해 각 DACON 간의 연결을 도모하기 위함이다.
연합 역시 포털들 사이에서만 이루어진다. 한 포털이 다른 포털의 어드레스를 알게 되었을 때 통합 등이 아닌 연합을 선택하는데 근거가 되는 메트릭으로는 RTT (서로 다른 포털 간에 핑 메시지 등을 주고 받아 측정할 수 있는 네트워크 round-trip time), GPS coordinators (서로 다른 포털의 물리적인 GPS 좌표로서, 만일 이런 좌표들을 모든 DACON 호스트들이 관리한다면 DACON 을 통한 location aware service 도 쉽게 구현될 수 있다), 포털의 수 (어떤 포털의 LPL 멤버 수로서, 한 로컬 DACON 내의 모든 포털들은 서로 풀-메쉬 링크를 구성해야 하기 때문에 하나의 로컬 DACON 의 크기는 현재의 네트워크 내의 전체 포털 수에 영향을 받아 결정될 수 있다) 등이 가능하다.
이하에서는 도 6 을 참고하여 연합 절차를 설명한다.
우선, 상대 포털 B 와 연합 관계를 맺고자 하는 포털 A 는 먼저 Query_Alliacne 메시지를 자신의 LPL 에 보낸다 (도 6 의 1) Query_Alliance 단계). 메시지를 보낸 포털 A 는 일정 timeout 시간 동안 Reply_Alliance 메시지를 기다린다. 포털 A 에 속하는 LPL 들은 포털 A 의 Query_Alliance 메시지에 대한 응답으로 Reply_Alliance 메시지를 보낸다 (도 6 의 2) Reply_Alliance 단계). 그 후, 포털 A 는 Reply_Alliance 에 따라 포털 B 에 Allying_Request 메시지를 보내게 된다 (도 6 의 3) allying_Request 단계). 만일 timeout 동안 LPL 로부 터 메시지가 없으면 포털 A 는 바로 Allying_Request 메시지를 포털 B 에 보내고, 만일 timeout 전에 누군가가 bAlliance=1 인 Reply_Alliacne 메시지를 보낸다면 이는 이미 연합 관계가 있는 보더 포털이 자신의 DACON 에 존재하는 것이기 때문에 Allying_Request 를 보내지 않고 종료한다.
Query_Alliance 메시지의 인자는 다음과 같다.
인자 설명
addrQuerist 질의를 하는 포털 (포털 A) 의 어드레스이다.
addrContender 질의의 대상이 되는 연합 관계를 맺고자 하는 상대 포털 (포털 B) 의 어드레스를 나타낸다.
addrSecondary Contender 포털 이외에 확인해 볼 수 있는 다른 포털의 어드레스를 적을 수 있다.
Reply_Alliance 메시지의 인자는 다음과 같다.
인자 설명
addrReplier 답을 하는 포털 (LPL[1]…LPL[N]) 의 어드레스이다.
addrContender 해당 대답의 대상이 되는 포털 (포털 B) 의 어드레스이다.
bAlliance 이미 연합 관계가 있는지를 나타내는 flag 값이다. 1 이면 이미 있는 것이고, 0 이면 없는 것이다.
Allying_Request 메시지의 인자는 다음과 같다.
인자 설명
addrRequester 연합 요청을 하는 포털 (포털 A) 의 어드레스이다.
addrConfirmer 연합 요청을 받은 포털 (포털 B) 의 어드레스이다.
addrSecondary 연합 요청을 하는 requestor 포털의 DACON 의 2 차 보더 포털의 어드레스이다.
Alliance_Request 를 받은 포털 B 는 역시 Query_Alliance 메시지를 자신의 LPL 의 멤버들에게 보낸다 (도 6 의 4) Query_Alliance 단계). 마찬가지로 포털 B 의 LPL 멤버들은 포털 B 의 Query_Alliance 메시지에 대한 응답으로서 Reply_Alliance 메시지를 보낸다 (도 6 의 5) Reply_Alliance 단계). 그 후, 포털 B 는 포털 A 에게 Allying_Accept 메시지를 보내게 된다 (도 6 의 6) Allying_Accept 단계). 기존에 이미 상대 보더 포털 (포털 A) 과 연합 관계를 맺고 있는 포털이 없다면 자신의 EBPL 에 상대 포털 A 의 어드레스와 같이 온 2 차 포털의 어드레스를 기록한다. 이때, 포털 A 와 2 차 포털의 어드레스는 별개의 EBPL 의 아이템이 아니라 포털 A 의 어드레스라는 아이템의 하위 항목으로 기록된다.
한편, Allying_Accept 메시지를 받은 포털 A 역시 자신의 EBPL 에 상대 포털 B 의 어드레스와 같이 전달된 2 차 포털의 어드레스를 기록한다.
Allying_Accept 메시지의 인자는 다음과 같다.
인자 설명
addrConfirmer 연합 요청을 수락하는 포털 (포털 B) 의 어드레스이다.
addrRequester 연합을 요청하는 포털 (포털 A) 의 어드레스이다.
addrSecondary 연합 요청을 수락한 confirmer 포털 (포털 B) 의 DACON 의 2 차 보더 포털의 어드레스이다.
엄밀히 말해 연합 관계는 포털-to-포털의 관계이지 DACON-to-DACON 의 관계가 아니다. 다시 말해, 자신의 DACON 내에는 상대 보더 포털과 연합을 맺고 있는 다른 포털은 존재하지 않지만, 자신의 DACON 내에 상대 DACON 의 다른 보더 포털과 연합을 맺고 있는 다른 포털은 존재할 수 있다는 것이다. 이는 DACON 자체의 식별기 (identifier) 가 존재하지 않기 때문에 DACON 을 고유하게 식별할 수 없기 때문이다.
그러나, 이런 중복적인 포털간의 연결은 DACON 사이에서 제한된 다중 접속을 가능하게 하여 연합간의 이용가능성을 높이는 장점이 있다. 또한, Query_Alliance 과정에서 2 차 포털도 같이 질문할 수 있기 때문에 특정 DACON 에서 선호되는 특정 2 차 포털을 설정하는 방법이 있다면, 즉, 2 차 포털은 한 DACON 내에서 하나의 포털로 설정할 수 있다면 이런 중복 역시 대부분 해결할 수 있다.
9. 장애의 복구 ( Failure Recovery )
DACON 에서는 각 호스트들이 주기적인 HELLO 메시지 등으로 자신의 피어가 동작하고 있는지를 확인할 수 있다. 만일 어떤 피어가 동작하지 않는다면 그 피어가 어떤 역할을 하고 있는가에 따라 다음과 같이 손쉽게 새로운 네트워크를 설정할 수 있다.
먼저, 자신의 NHP (Next-hop to Portal) 에 해당하는 피어에 장애가 생긴 것을 알게 되면, 새로운 NHP 를 설정하게 된다. 이는 합류 과정 (Joining Procedure) 으로 처리할 수 있다. NHP 의 장애는 새로운 피어에 합류를 해야 하는 중요한 이유 중의 하나이다. NHP 에 장애가 발생했음을 파악한 호스트는 자신의 PL 멤버들에 대해 순차적으로 합류를 시도하게 된다. 만일 모든 피어로부터 새로운 NHP 를 설정하지 못했다면, 즉, 모든 다른 피어들로부터 Joinging_Accept 메시지를 받지 못한 경우에는 스스로를 포털로 설정하고 초기 상태로 돌아가게 된다.
만일, 장애가 발생한 피어가 상대 DACON 의 보더 포털이라면 (이 경우 장애를 발견한 호스트는 포털이다), 해당 연합 DACON 에 대해 새로운 보더 포털을 설정해야 한다. 이를 위해 연합 과정 (Alliance Procedure) 에서 전달 받은 2 차 보더 포털에게 새로운 Alliance_Request 를 보내 새로운 연합 과정을 수행한다.
또한, 위의 두 경우가 아닌 일반적인 피어에 장애가 발생한 경우에는 일단 그냥 무시할 수 있다. 왜냐하면, 일시적인 장애일 수도 있기 때문이다. 추후에, 콘텐츠 회수 과정에서 장애가 발생하는 경우에는 해당 피어에 대한 정보를 삭제한다.
Ⅳ. 콘텐츠
1. 콘텐츠의 정의
본 출원에서 콘텐츠란 DACON 을 통해 얻을 수 있는 모든 종류의 파일 데이터 등을 의미한다. 특히, 콘텐츠는 메타데이터와 데이터로 구성된다. 메타데이터는 어떤 콘텐츠의 특성을 표현하는 정보들인 반면에, 데이터는 실제 해당 콘텐츠를 구성하는 부분이다. 모든 콘텐츠들은 각각을 고유하게 구분할 수 있는 128 비트의 콘텐츠 id (content id; cid) 를 발급받는다 (정적 콘텐츠의 경우 전체 데이터를 MD5 hashing 등으로 생성 가능). 메타데이터는 사용자들이 자유롭게 수정/갱신할 수 있으며 콘텐츠의 각 인스턴스마다 서로 다를 수 있다. 콘텐츠는 시간이 지나도 변하지 않는 정적 콘텐츠 (예를 들어, 음악, 영화 파일 등) 와 시간에 따라 변하는 동적 콘텐츠 (예를 들어, real-time 비디오 스트림 등) 이 있을 수 있다.
2. 메타데이터
메타데이터란 임의의 콘텐츠의 특성을 표현하는 정보를 의미한다. 예를 들어, 영화 "Transformers ™" 의 메타데이터에는 'SF Movie' 라는 장르명, '2007' 이라는 제작연도, 영화의 텍스트 제목인 'Transformer' 등이 포함될 수 있다.
메타데이터의 각 항목들은 각각에 해당하는 특성 (Property) 과 값 (Value) 을 가진다. 예를 들어, 영화 "Transformers ™" 의 컨텍스트를 표현할 경우 소스는 이 콘텐츠의 cid (cid 값은 인스턴스에 따라 고유하다) 가 되고, Property:Genre/Value:Action Movie, Property:Director/Value:Michael Bay, 또는 Property:Year/Value:2007 과 같이 표시될 수 있다.
메타데이터의 내용은 각 인스턴스마다 서로 상이할 수도 있다. 따라서, 각 호스트들은 같은 데이터의 콘텐츠에 대해 서로 다른 메타데이터를 가질 수 있다. 예를 들어, 같은 영화에 대해 호스트 A 에 있는 메타데이터의 정보에는 'cool' 이라고 되어 있고, 호스트 B 에 있는 메타데이터의 정보에는 'boring' 이라고 되어 있을 수도 있다.
각 호스트들은 자신이 알고 있는 메타데이터 정보를 기반으로 스스로의 정보공간을 구축하고 자신의 규칙에 따라 이들을 분석하여, 이러한 정보를 바탕으로 새로운 정보를 추론할 수 있다. 이러한 과정은 G. Antoniou and F. van Harmelen, "A Semantic Web Primer,"The MIT Press, 2004 에서 참고할 수 있는 온톨로지 (Ontology) 의 그것과 유사하다. 또한, 분산된 온톨로지 리포지토리 (Ontology repository) 들을 바탕으로 컨텍스트 정보를 제공하는 아키덱쳐는 R.Power et al. A context information service using ontology-based queries, In Proceedings of The First International Workshop on Advanced Context Modelling, Reasoning, Management Held in Conjunction with The 6th International Conference on Ubiquitous Computing(UbiComp'2004), Nottingham, England, 2004 에서 제안되었고, 컨텍스트 정보를 바탕으로 특정 콘텐츠를 P2P 오버레이 네트워크 상에서 찾는 라우팅 기법에 대해서는 C.Tempich et al. "REMINDIN':Semantic Query Routing in Peer-to-Peer NetworkdsBased on Social Metaphor," In Proceedings of the 13th WWW Conference New York. ACM, 2004 와 J.X.parreira et al."p2pDating:Real life inspired semantic overlay networks for Web search,"Information Processing and Management,2007 에서 제안되었다.
본 출원의 DACON 에서는 이러한 구체적인 메커니즘을 별도로 정의하지는 않지만 당업자는 위와 같은 공지의 기술이 적용될 수 있음을 명확히 알 수 있을 것이다. 모든 호스트들은 스스로의 능력과 정책에 의해 이러한 과정을 수행하며, 본 출원의 DACON 에서 주로 다루는 것은 이런 메타데이터 정보를 표현하는 규칙과 이를 이용해 서로 다른 호스트에 있는 콘텐츠를 검색하는 프로토콜이다.
3. 콘텐츠 업로딩 /인출 ( Content Uploading / Fetching )
먼저, DACON 에 새로운 콘텐츠가 업로드되는 경우는 DACON 사용자가 호스트에 콘텐츠를 올리는 경우, 호스트의 관리자 등이 직접 호스트에 올리는 경우, 그리고 호스트가 스스로 외부의 콘텐츠를 찾아 올리는 경우가 있을 수 있다. 이 중, 관리자가 직접 호스트에 올리는 경우는 네트워크 기능이 아닌 호스트의 자체 관리 인터페이스를 통해 이루어지는 것이고, 호스트가 스스로 외부의 인터넷 등에서 자료를 찾는 경우는 호스트의 지적기능에 의한 것이지 DACON 이 제공하는 서비스에 의한 것은 아니므로, 이하에서는 사용자가 호스트에 콘텐츠를 업로드하는 경우를 주로 서술한다.
도 7 에서는 사용자가 호스트 A 에 콘텐츠를 업로딩하는 과정을 나타내고 있다. 새로운 콘텐츠를 업로드하고자 하는 사용자는 Upload_Content 메시지를 통하여 호스트에 새로운 콘텐츠를 업로드한다. 이때, 콘텐츠 소스, 즉, 사용자는 사전에 별도의 인증 작업을 통해 업로드 권한을 획득하였다고 가정한다.
Upload_Content 메시지의 인자는 다음과 같다.
인자 설명
idEndUser 사용자의 네트워크 어드레스이다.
addrReceiver 데이터를 받는 호스트 (호스트 A) 의 어드레스이다.
meta_data 새로 올리는 콘텐츠에 대한 meta_data 값들이다.
cid 가 포함될 수도 있다. 하지만 실제 호스트에 저장되는 cid 는 새로 계산되어야 한다 (소스가 제공하는 cid 를 무조건 신뢰할 수는 없기 때문이다).
사용자가 보내는 cid 는 중복된 콘텐츠의 업로드를 사전에 차단하는데 사용된다.
데이터 사이즈는 포함되어야 한다.
meta_data 에 포함된 다양한 정보들은 해당 콘텐츠에 대한 호스트의 정보공간을 구성한다.
data 콘텐츠의 실제 내용의 파일 데이터이다.
bForceUpdate 해당 cid 의 데이터가 이미 호스트에 존재하더라도 강제로 업데이트하도록 한다.
실제 갱신은 해당 데이터를 모두 수신한 후 새로 계산한 cid 가 정말로 같은 경우에만 수행한다.
bForceUpdate 는 관리 등의 용도로 새로 콘텐츠를 업로드해야 할 경우에 사용된다.
도 8 은 콘텐츠를 인출하는 과정을 나타내는 도면이다.
콘텐츠 인출 (content fetching) 이란 어떤 호스트가 DACON 내의 다른 호스트에게 특정 cid 의 콘텐츠를 요청하여 전송받는 과정을 의미한다. 같은 로컬 DACON 내의 모든 호스트는 상대의 네트워크 어드레스를 알면 바로 콘텐츠 인출이 가능하다. 반면에, 서로 다른 DACON 에 위치한 두 호스트들은 보더 포털을 통 해서만 콘텐츠 인출이 가능한다.
콘텐츠를 전송 받기 원하는 노드는 Get_Content 메시지를 통해 특정 cid 의 콘텐츠를 요청한다 (도 8 의 1) Get_Content 단계). 그 후, 요청을 받은 노드는 Put_Content 메시지를 통해 해당 콘텐츠의 meta-data 와 데이터를 전송한다 (도 8 의 2) Put_Content 단계).
Get_Content 메시지의 인자는 다음과 같다.
인자 설명
addrRequester 전송받을 호스트 (호스트 A) 의 어드레스 값
addProvider 전송할 호스트 (호스트 B) 의 어드레스 값
cid 요청하는 콘텐츠의 cid
Put_Content 메시지의 인자는 다음과 같다.
인자 설명
addrProvider 전송하는 호스트 (호스트 B) 의 어드레스 값
addrReceiver 전송받는 호스트 (호스트 A) 의 어드레스 값
meta_data 전송하는 콘텐츠에 대한 호스트 B 의 메타데이터 값들이다.
cid 와 데이터의 사이즈는 포함되어야 한다.
mumBlocks 콘텐츠의 데이터는 블럭으로 나누어져 전송되는데, 이때 데이터의 전체 블럭 수를 나타낸다.
sizeBlock 한 블럭의 사이즈를 말한다. 보통 64KB~1MB 이다.
startBlock 전송되는 시작 블럭의 번호이다. 0 이 기본값이다.
endBlock 전송되는 마지막 블럭의 번호이다. 0 이 기본값이다.
data 전송되는 데이터이다.
4. 메타데이터 관리
각 호스트는 자신이 가지고 있는 콘텐츠의 메타데이터를 다음과 같은 메타데이터 테이블로 관리하고 있다.
속성 설명
tag 콘텐츠의 cid 와 데이터 사이즈 이외의 메타데이터 정보에서 하나의 값 (property-value 쌍에서) 은 일종의 태그 스트링 정보로 간주된다.
각 태그 값은 테이블에 중복되어 존재할 수 있다.
cid 해당 태그 값의 cid 이다.
property 해당 태그 값의 특성이다.
bitDirty 해당 내용을 포털에 전송한 적이 있는지 판단하는데 쓰인다.
전송한 적이 없으면 1, 있으면 0 이다.
또한, 각 호스트들은 자신이 가지고 있는 콘텐츠의 데이터에 대한 정보를 데이터 테이블로 관리하고, 있다.
속성 설명
cid 콘텐츠의 cid, 일차 키 (primary key) 다.
sizeData 데이터의 크기다. (in bytes)
description 콘텐츠의 내용에 대한 간략한 설명이다.
handleFile 파일 데이터의 포인터, 혹은 핸들 값이다.
해당 메타데이터는 자신의 지정된 포털에 전달되어야 한다. 이는 호스트가 자신의 NHP 에 Metadata_Report 메시지를 보내거나, 자신이 포털이 아닌 호스트인 경우에는 이를 계속 자신의 NHP 로 포워딩함으로써 이루어진다. 해당 메타데이터는 주기적으로 Metadata_Report 메시지를 통해 변경된 부분만 전송된다. 그러나, 역시 일정 주기로는 전체 메타데이터가 전달될 수도 있다.
Metadata_Report 메시지는 다음과 같은 인자를 가진다.
인자 설명
addrReporter 메시지를 보내는 호스트의 네트워크 어드레스이다.
numTuples 전송할 메타데이터의 행 (row) 의 개수이다.
tuplesMetadata 해당하는 메타데이터가 스트링으로 (tag, cid, property, description, …) 값들의 연속으로 전달된다.
호스트의 모든 메타데이터 정보를 해당 호스트의 지정된 포털에 보내는 경우 확장성의 문제가 우려될 수 있다. 그러나, 각 호스트가 기여하는 저장 사이즈의 한계가 있고, 각 포털 역시 자신이 관리하는 ND 값에 한계를 두고 있기 때문에 결국 최대 메타데이터 사이즈는 일정 범위 내에서 한정된다. 예를 들어, 한 호스트가 약 500GB 정도의 저장용량을 기여한다고 할 때, 콘텐츠가 모두 약 10MB 정도의 음악 파일이라고 가정하면, 호스트에는 약 50000 개 정도의 콘텐츠가 존재하게 될 것이다. 이때, 하나의 콘텐츠의 메타데이터의 사이즈를 최대 2KB 정도라고 가정한다면 하나의 호스트의 메타데이터 테이블의 사이즈는 최대 100MB 정도가 될 것이다. 하나의 포털이 약 100 개 정도의 호스트를 담당한다면 한 포털의 전체 메타데이터는 약 10GB 정도가 될 것이며, 이 정도의 데이터는 최근 시스템 성능상 크게 문제가 되지 않는다. 또한 이는 최대 사이즈에 대한 예측이며 추후 각 포털에서 중복된 내용을 필터링하거나, 온톨로지 등을 이용하여 유사한 메타데이터를 하나로 합치는 리졸빙 (resolving) 등을 도입한다면 데이터 사이즈는 크게 문제되지 않을 것이다.
5. 콘텐츠 검색 ( Content Searching )
DACON 의 가장 중요한 기능 중 하나는 어떤 메타데이터 정보를 이용하여 이에 해당하는 콘텐츠를 찾아서 사용자에게 전송해 주는 것이다. 이를 콘텐츠 라우팅이라고 정의한다. 콘텐츠 라우팅의 과정은 크게 사용자가 입력한 질문 (query) 을 이용해 해당하는 콘텐츠를 찾아내는 콘텐츠 검색과 콘텐츠를 전달하는 콘텐츠 회수의 2 단계로 이루어진다. 해당 콘텐츠를 검색하는 가장 명시적인 방법은 그 콘텐츠의 cid 를 이용하는 것이지만, cid 는 일반적으로 인간이 읽거나 쓰기에는 매우 어려운 128 비트의 숫자로 되어 있다. 따라서, 실제 콘텐츠의 요청은 cid 가 아니라 콘텐츠의 제목 등의 메타데이터 정보를 통해 이루어진다.
따라서, DACON 은 호스트 상에 퍼져있는 메타데이터를 검색하여 요청된 질문에 해당하는 검색 결과값을 사용자에게 제공하고, 여기에서 사용자가 특정 콘텐츠를 요청하면 이를 제공하는 방식을 채택한다. 즉, 사용자가 어떤 콘텐츠의 cid 를 요청했다는 것은 이미 사용자와 연관되어 있는 호스트는 해당 cid 의 콘텐츠가 있는 위치를 알고 있다는 것이다.
어떤 두 호스트 사이 (또는, 사용자와 호스트) 에서 콘텐츠를 질문하는 과정은 사용자 혹은 어떤 호스트가 다른 호스트에 Query_Content 메시지를 보내면서 시작된다. 이후, 이 메시지를 받은 호스트는 자신의 메타데이터 테이블을 참조하여 검색 결과를 My_Content 메시지를 통해 전달해 준다. 호스트 A 가 호스트 B 에게 질문을 하고 그 결과를 받는 콘텐츠 질문 과정을 도 9 에서 도시하고 있다.
Query_Content 메시지는 다음과 같은 인자를 가진다.
인자 설명
addrQuerist Query 를 하는 쪽 (호스트 A) 의 네트워크 어드레스이다.
addrReplier Query 에 답하는 쪽 (호스트 B) 의 네트워크 어드레스이다.
query 사용자의 질문이다.
일반 검색문처럼 복수의 컨텍스트 값이나 조건식으로 구성된 서술어도 가능해야 한다.
type 해당 질문의 타입을 표시한다. 후술할 점증적 콘텐츠 검색에서 사용한다.
0, 1, 2, 3, 4 의 값을 가질 수 있다.
handle 어떤 질문의 결과는 한 번의 응답으로는 전송하기에 너무 클 수 있다. 이때, 이전 질문의 이후 결과를 얻기 위해서 사용하는 값이다.
처음 질문을 던질 때에는 handle 값을 NULL 로 하여 보낸다.
My_Content 메시지는 다음과 같은 인자를 가진다.
인자 설명
addrReplier 질문에 답하는 쪽 (호스트 B) 의 네트워크 어드레스이다.
addrQuerist 질문을 하는 쪽 (호스트 A) 의 네트워크 어드레스이다.
numResults 전송할 질문 결과의 행의 개수이다.
tuplesResults 해당하는 메타데이터가 스트링으로 (tag, cid, property, description, …) 값들의 연속으로 전달된다.
handle 어떤 질문의 결과값이 한 번의 My_Content 메시지로 표현하기 어려울 경우에, 추가적인 결과가 있다는 것을 handle 으로 알려준다.
handle 값은 32 비트의 ID 값으로서 해당 질문 세션을 고유하게 식별한다.
질문을 처리하면서 가장 중요한 것 중 하나는 어떤 호스트에 질문을 전달할 것인가를 결정하는 것이다. DACON 에서는 질문을 전달할 대상 호스트를 크게 5 단계의 타입에 의해 점증적으로 수행하게 되며, 이를 점증적 콘텐츠 검색 (Incremental Content Searching; ICS) 라고 한다.
도 10 은 ICS 과정을 나타내는 도면이다. 도 10 에 도시된 바와 같이, 사용자가 연관 호스트에 전달하는 Query_Content 메시지의 'type' 값에 따라서 호스트는 검색의 범위를 설정하게 된다.
각 타입의 값에 따른 질문의 전달 노드는 다음과 같이 정리된다.
먼저, 타입이 0 인 경우에는, 질문이 전달된 하나의 호스트에서만 검색을 실시한다. 실제 사용자의 질문에는 사용되지 않으며 DACON 내의 ICS 구현을 위한 보조 수단으로 이용된다.
타입이 1 인 경우, 질문이 전달된 호스트와 해당 호스트의 피어들에서 검색을 실시한다. 처음 질문을 전달받은 호스트는 자신의 피어들에게 다시 타입 0 질문을 전송하고 이에 대한 답을 받은 후 결과를 종합하여 질문을 요청한 호스트에 전달한다. 질문의 전달은 모든 피어에게 하는 것이 아니라 해당 컨텍스트가 존재할 수 있는 가능성이 높은 피어에게만 할 수도 있다. 이는 각 호스트들의 능력과 정책에 따라 달라질 수 있다. 미네르바 (Minerva) 등에서는 서로 분산된 피어들 사이에서 오버랩과 유용성을 고려하여 질문을 보낼 피어를 선택하는 IQN 라우팅 기법을 사용한다. DACON 호스트들은 각자의 능력과 정책에 따라 알맞은 기법을 사용할 수 있다. 피어의 메타데이터 정보 역시 Query_Content 메시지를 통해 수집할 수도 있다. 일반적으로, 사용자가 콘텐츠 검색을 할 때는 언제나 가장 먼저 타입 1 로 검색을 실시한다.
타입이 2 인 경우, 질문이 전달된 호스트의 지정된 포털에서 검색을 실시한다. 포털은 자신이 담당하는 모든 호스트들의 메타데이터 정보를 알고 있기 때문에 검색은 포털에서만 이루어져도 된다. 질문은 처음 전달된 호스트에서 NPH 로 계속 포워딩되어 포털에 이르게 된다. 이때, 중간의 호스트들은 타입 2 의 질문을 받았을 때, 자신이 포탈이 아니면 계속 NHP 로 포워딩한다. 포털에서의 검색 결과는 처음 질문을 보낸 호스트에 바로 전달되어 필요시 다시 사용자에게로 전해진다.
타입이 3 인 경우, 질문이 전달된 호스트가 속한 DACON 의 모든 포털에 질문을 보낸다. 질문은 타입 2 인 경우와 마찬가지로 포털에 전달된다. 전달된 메시지가 타입 3 인 경우, 질문을 받은 포털은 자신의 LPL 에 있는 모든 포털들에게 해당 질문을 타입 0 으로 보낸다. 질문을 받은 포털은 결과를 수합하여 바 로 질문을 보낸 호스트에게 결과를 보낸다.
타입이 4 인 경우, 질문을 외부 DACON 에 전달한다. 타입 3 질문과 같이 질문을 전달받은 포털은 자신의 LPL 에 있는 모든 포털들에게 질문을 타입 4 로 보낸다. 타입 4 질문을 다른 포털로부터 전달받은 포털들은 자신의 EBPL 에 있는 포털들에게 질문을 타입 4 로 전달한다. 타입 4 질문을 외부 보더 포털로부터 받은 포털은 자신의 LPL 에 있는 포털들에게 타입 0 질문을 전달하고, 그 결과를 수합하여 질문을 보낸 외부 보더 포털에게 전달한다. 처음 타입 4 질문을 받은 포털은 모든 결과를 수합하여 질문을 요청한 호스트에 전달해 준다.
6. 콘텐츠 캐싱 ( Content Caching )
어떤 사용자가 요청한 콘텐츠는 해당 사용자와 연관되어 있는 호스트를 통해 사용자에게 전송되게 된다. 이때, 콘텐츠를 서비스한 호스트는 스스로의 결정 방법에 의해 해당 콘텐츠를 자신의 저장공간에 캐싱할 수 있다. 위의 과정이 반복되면서 콘텐츠는 DACON 내에서 서로 다른 호스트들로 전파되게 된다. 따라서, 많은 사용자로부터의 요청이 있는 콘텐츠는 더 많은 호스트에 분포하게 되어 콘텐츠에 대한 접근성 및 이용가능성을 높여주게 된다.
어떤 콘텐츠를 검색할 경우 이를 가지고 있는 호스트가 DACON 내에서 여러 개가 존재할 수도 있다. 이 경우, 이를 이용해 여러 소스로부터 분산하여 데이터를 전송받는 기법도 활용할 수 있다.
Ⅴ. BM 모델
DACON 은 사용자가 직접 네트워크의 인프라를 기여하는 자발적인 네트워크이 다. 이런 네트워크를 위해서는 참여하는 사용자에게 인프라의 기여에 대한 어떤 인센티브가 있어야 할 것이다. 특히, 참여자에 대한 인센티브는 미래에 어떤 이익을 얻을 수 있을지에 대한 기대적인 요소 (예를 들어, 미래에 발생하는 수익의 배분) 와 함께 네트워크 참여 자체에 대해서도 어떤 인센티브가 있어야 한다. 따라서, 네트워크에 참여하는 참여자에 대한 이익을 실현할 수 있는 영업방법을 생각해 볼 수 있다.
본 발명의 일 실시형태에서는 호스트가 사용자가 요구하는 데이터를 검색하여 제공함과 동시에 호스트의 설치자가 원하는 홍보물이나 서비스를 같이 제공할 수 있는 시스템을 제공한다. 예를 들어, 음식점, 카페, 영화관 등 주문을 받아 서비스를 제공하는 영업장소에 있어서, 영업장은 호스트를 제공하여 그 근처 지역의 사용자들이 네트워크를 이용할 수 있게 한다. 동시에 영업장에서는 영업장에서 서비스를 받고자 하는 수요자의 주문을 호스트를 통한 네트워크 시스템으로 받을 수 있도록 한다. 따라서, 수요자는 다양한 네트워크 접속 수단을 이용하여 주문을 할 수 있고 이에 따라 영업장은 주문의 접수를 네트워크를 통해 간편하게 실행할 수 있다.
또한, 호스트를 제공하는 영업장은 자신의 호스트를 거쳐 전송되는 데이터에 자신의 영업장에 대한 홍보 문구 등을 같이 전달할 수 있다. 이에 따라, 호스트를 제공하는 영업장은 그 호스트를 이용하는 DACON 사용자들에게 자신의 영업장을 유용하게 홍보할 수 있다.
상기 실시형태를 통하여 호스트의 기증자는 호스트의 기증 자체를 통해서도 자신의 영업장의 수익에 직접적인 효과를 거둘 수 있다.
도 11 에서는 본 발명의 또 다른 일 실시형태인 콘텐츠 결제 시스템을 개시하고 있다.
먼저, 사용자 (U) 는 콘텐츠 검색을 통해 원하는 콘텐츠를 검색하게 된다 (1, 2 단계). 이후, 해당 콘텐츠에 대해 사용자가 라이센스를 보유하고 있지 않다면 자신의 연관된 호스트 (H1) 가 제공하는 보안 채널을 통해 콘텐츠 제공자 (P) 에 접속하여 과금을 한다 (3 단계). 이때, 호스트 (H1) 는 이 과정이 자신을 통해 이루어졌음을 콘텐츠 제공자 (P) 에게 알려주게 된다 (4 단계). 콘텐츠 제공자 (P) 는 라이센스 서버 (L) 에게 해당 사용자 (U) 가 과금을 했음을 알린다 (5 단계). 사용자는 이후 언제든 라이센스 서버 (L) 을 통해 라이센스를 다운로드 받을 수 있다. 이때도 자신의 연관된 호스트 (H1) 가 제공하는 보안 채널을 통해 라이센스 서버 (L) 와 통신한다 (7, 8 단계). 이후, 사용자는 언제든 DACON 을 통하여 콘텐츠를 다운받아 사용할 수 있다 (9, 10 단계).
도 1 은 DACON 을 이루는 구성들을 개략적으로 나타내는 도면.
도 2 는 이동하는 단말 사용자를 통하여 다른 호스트의 네트워크 식별자를 입수하는 프로세스를 개략적으로 나타내는 도면.
도 3 은 호스트간의 피어링 프로세스를 개략적으로 나타내는 도면.
도 4 는 임의의 호스트가 다른 포털로 합류하는 프로세스를 개략적으로 나타내는 도면.
도 5 는 포털간의 통합 프로세스를 개략적으로 나타내는 도면.
도 6 은 포털간의 연합 프로세서를 개략적으로 나타내는 도면.
도 7 은 콘텐츠를 업로드하는 프로세서를 개략적으로 나타내는 도면.
도 8 은 콘텐츠를 인출하는 프로세서를 개략적으로 나타내는 도면.
도 9 는 콘텐츠를 질문하는 프로세서를 개략적으로 나타내는 도면.
도 10 은 DACON 에서의 점증적 콘텐츠 검색의 프로세서를 개략적으로 나타내는 도면.
도 11 은 DACON 에서의 콘텐츠에 대한 인증 프로세서를 개략적으로 나타내는 도면.

Claims (33)

  1. 이동성 있는 단말과 접속가능한 호스트를 하나 이상 구비하는 네트워크에 있어서,
    상기 단말이 제 1 호스트에 접속할 때, 상기 단말이 이전에 접속했던 제 2 호스트의 네트워크 식별자를 상기 제 1 호스트에 전달함으로써, 상기 제 1 호스트를 상기 네트워크에 추가하는, 네트워크 구축 방법.
  2. 제 1 항에 있어서,
    상기 제 1 호스트는 상기 제 2 호스트에게 자신과 피어링 관계를 설정할지 여부를 질문하고 상기 제 2 호스트가 피어링에 대하여 응답하는 경우에는, 상기 제 1 호스트 및 상기 제 2 호스트는 피어링 관계를 형성하는, 네트워크 구축 방법.
  3. 제 2 항에 있어서,
    상기 제 1 호스트 및 상기 제 2 호스트의 피어링 관계의 형성은,
    상기 제 1 호스트가 상기 제 2 호스트에게 자신과 피어링 관계를 설정할지 여부를 질문하는 단계;
    상기 제 2 호스트가 상기 제 1 호스트에게 응답하는 단계;
    상기 제 1 호스트가 자신의 지정된 제 1 포털에게 상기 제 2 호스트의 네트워크 식별자를 전달하는 단계;
    상기 제 1 포털이 상기 제 2 호스트에게 자신의 네트워크 식별자를 전달하는 단계; 및
    상기 제 2 호스트가 자신의 지정된 제 2 포털에게 상기 제 1 포털의 네트워크 식별자를 전달하는 단계를 포함하는, 네트워크 구축 방법.
  4. 제 1 항에 있어서,
    상기 제 1 호스트가 상기 제 2 호스트에게 합류를 요청하고 상기 제 2 호스트가 이를 승인하는 경우에는, 상기 제 1 호스트는 상기 제 2 호스트에 지정된 제 2 포털에 합류하게 되는, 네트워크 구축 방법.
  5. 제 4 항에 있어서,
    상기 제 1 호스트의 합류는,
    상기 제 1 호스트가 상기 제 2 호스트에 합류를 요청하는 단계;
    상기 제 2 호스트가 상기 제 2 포털에 상기 합류의 요청을 전달하는 단계;
    상기 제 2 포털이 상기 합류의 요청을 승인하는 단계;
    상기 제 2 호스트가 상기 제 1 호스트에게 상기 합류의 요청을 승인하는 단계; 및
    상기 제 1 호스트가 자신의 지정된 제 1 포털을 떠나 상기 제 2 포털에 합류하는 단계를 포함하는, 네트워크 구축 방법.
  6. 제 2 항에 있어서,
    상기 제 1 호스트에 지정된 제 1 포털과 상기 제 2 호스트에 지정된 제 2 포털이 통합되어 서로의 하위 호스트들의 네트워크 식별자들을 공유하는, 네트워크 구축 방법.
  7. 제 6 항에 있어서,
    상기 제 1 포털과 상기 제 2 포털의 통합은,
    상기 제 1 포털이 상기 제 2 포털에 통합을 요청하는 단계;
    상기 제 2 포털이 상기 제 1 포털에 통합을 승인하는 단계; 및
    상기 제 1 포털 및 상기 제 2 포털이 서로의 포털에 속하는 호스트들의 네트워크 식별자들을 공유하는 단계를 포함하는, 네트워크 구축 방법.
  8. 제 2 항에 있어서,
    상기 제 1 호스트는 제 1 네트워크에 포함되고, 상기 제 2 호스트는 제 2 네트워크에 포함되며,
    상기 제 1 호스트에 지정된 제 1 포털과 상기 제 2 호스트에 지정된 제 2 포털이 연합되어, 상기 제 1 네트워크와 상기 제 2 네트워크가 연결되는, 네트워크 구축 방법.
  9. 제 8 항에 있어서,
    상기 제 1 네트워크와 상기 제 2 네트워크의 연결은, 상기 제 1 포털과 상기 제 2 포털을 통하여 서로 연결되는, 네트워크 구축 방법.
  10. 제 9 항에 있어서,
    상기 제 1 포털 및 상기 제 2 포털의 연합은,
    상기 제 1 포털이 자신의 하위 포털들에게 연합을 질문하는 단계;
    상기 제 1 포털의 하위 포털들이 상기 제 1 포털에게 응답하는 단계;
    상기 제 1 포털이 상기 제 2 포털에게 연합을 요청하는 단계;
    상기 제 2 포털이 자신의 하위 포털들에게 연합의 승인을 질문하는 단계;
    상기 제 2 포털의 하위 포털들이 상기 제 2 포털에게 응답하는 단계; 및
    상기 제 2 포털이 상기 제 1 포털에게 연합을 승인하는 단계를 포함하는, 네트워크 구축 방법.
  11. 제 2 항에 있어서,
    상기 제 1 호스트는 상기 제 2 호스트에게 주기적인 메시지를 전송하여 상기 제 2 호스트의 동작 여부를 확인하는, 네트워크 구축 방법.
  12. 제 11 항에 있어서,
    상기 제 2 호스트가 동작하지 않는 경우, 상기 제 1 호스트는 상기 제 2 호스트의 역할에 따라 상기 제 2 호스트를 대체할 수 있는 다른 호스트와 연결되는, 네트워크 구축 방법.
  13. 제 1 항 내지 제 12 항 중 어느 한 항에 기재된 네트워크 방법을 이용하여 구축된 네트워크에 있어서 데이터를 검색하는 방법으로서, 상기 단말이 원하는 데이터를 검색하는 경우에 상기 검색의 타입에 따라서,
    상기 단말이 접속한 호스트에서만 검색을 실시;
    상기 단말이 접속한 호스트 및 상기 단말이 접속한 호스트와 피어링 관계인 호스트들에서만 검색을 실시;
    상기 단말이 접속한 호스트가 접속된 포털에서 검색을 실시;
    상기 단말이 속한 네트워크의 모든 포털에서 검색을 실시; 또는
    상기 단말이 속한 네트워크, 및 상기 단말이 속한 네트워크 외부에 존재하는 네트워크에서 검색을 실시하여 데이터를 검색하는 방법.
  14. 제 13 항에 있어서,
    상기 포털은 자신의 하위 호스트들에 저장된 데이터에 관한 정보를 포함하는 메타데이터를 포함하고,
    상기 데이터의 검색은 상기 단말이 입력하는 컨텍스트와 상기 호스트 또는 상기 포털에 저장된 상기 메타데이터를 비교하여 이루어지는, 데이터를 검색하는 방법.
  15. 제 13 항에 있어서,
    상기 검색에 의해 상기 단말이 원하는 데이터를 저장하고 있는 호스트의 네트워크 식별자를 확인하는 단계;
    상기 네트워크 식별자를 이용하여 상기 단말이 원하는 데이터를 저장하고 있는 호스트와 통신하는 단계; 및
    상기 단말이 원하는 데이터를 저장하고 있는 호스트로부터 상기 단말이 접속한 호스트로 상기 원하는 데이터를 전송받는 단계를 더 포함하는, 데이터를 검색하는 방법.
  16. 제 14 항에 있어서,
    상기 메타데이터는, 동일한 데이터에 대하여 상이하게 나타내는 복수의 메타데이터를 포함하는, 데이터를 검색하는 방법.
  17. 제 15 항에 있어서,
    상기 단말이 접속한 호스트는 상기 단말에게 전송한 데이터를 캐싱하는 단계를 더 포함하는, 데이터를 검색하는 방법.
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 제 1 항 내지 제 12 항 중 어느 한 항의 네트워크 구축 방법을 수행하도록 하는 프로그램을 기록한 컴퓨터 판독가능 매체.
  25. 제 13 항의 데이터 검색 방법을 수행하도록 하는 프로그램을 기록한 컴퓨터 판독가능 매체.
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
  31. 삭제
  32. 삭제
  33. 삭제
KR1020080055721A 2008-06-13 2008-06-13 Ｄａｃｏｎ 을 이용한 네트워크 시스템 및 네트워크 연결방법 KR101224827B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020080055721A KR101224827B1 (ko) 2008-06-13 2008-06-13 Ｄａｃｏｎ 을 이용한 네트워크 시스템 및 네트워크 연결방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020080055721A KR101224827B1 (ko) 2008-06-13 2008-06-13 Ｄａｃｏｎ 을 이용한 네트워크 시스템 및 네트워크 연결방법

Publications (2)

Publication Number Publication Date
KR20090129678A KR20090129678A (ko) 2009-12-17
KR101224827B1 true KR101224827B1 (ko) 2013-01-22

Family

ID=41689580

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020080055721A KR101224827B1 (ko) 2008-06-13 2008-06-13 Ｄａｃｏｎ 을 이용한 네트워크 시스템 및 네트워크 연결방법

Country Status (1)

Country Link
KR (1) KR101224827B1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130016594A (ko) 2011-08-08 2013-02-18 삼성전자주식회사 컨텐츠 중심 네트워크에서 컨텐츠 전송 장치의 순차적 컨텐츠 전송 방법, 컨텐츠 수신 장치의 순차적 컨텐츠 수신 방법, 컨텐츠 전송 장치 및 컨텐츠 수신 장치

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040085758A (ko) * 2003-04-01 2004-10-08 주식회사 아이캔텍 네트워크를 통해 서로 연결된 복수개의 단말들 간의 분산정보 공유 방법 및 시스템
KR20060023092A (ko) * 2004-09-08 2006-03-13 (주)클라우드나인 콘텐츠 포털에 특화된 온톨로지 관리시스템
KR20060057503A (ko) * 2004-11-23 2006-05-26 마이크로소프트 코포레이션 Ｐ2ｐ 네트워크용 분산 서버에 대한 시스템 및 방법
KR20060065746A (ko) * 2004-12-10 2006-06-14 에스케이 텔레콤주식회사 웹과 ｐ2ｐ 네트워크 간의 연동 시스템 및 방법

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040085758A (ko) * 2003-04-01 2004-10-08 주식회사 아이캔텍 네트워크를 통해 서로 연결된 복수개의 단말들 간의 분산정보 공유 방법 및 시스템
KR20060023092A (ko) * 2004-09-08 2006-03-13 (주)클라우드나인 콘텐츠 포털에 특화된 온톨로지 관리시스템
KR20060057503A (ko) * 2004-11-23 2006-05-26 마이크로소프트 코포레이션 Ｐ2ｐ 네트워크용 분산 서버에 대한 시스템 및 방법
KR20060065746A (ko) * 2004-12-10 2006-06-14 에스케이 텔레콤주식회사 웹과 ｐ2ｐ 네트워크 간의 연동 시스템 및 방법

Also Published As

Publication number Publication date
KR20090129678A (ko) 2009-12-17

Similar Documents

Publication Publication Date Title
Jafari Navimipour et al. A comprehensive study of the resource discovery techniques in Peer-to-Peer networks
KR100953594B1 (ko) 피어 투 피어 기반의 소셜 네트워킹 서비스 방법 및 시스템
Conti et al. A cross-layer optimization of gnutella for mobile ad hoc networks
Huang et al. Network-aware P2P file sharing over the wireless mobile networks
Zöls et al. On hierarchical DHT systems–An analytical approach for optimal designs
KR20120086417A (ko) 피어―투―피어 라이브 스트리밍을 위한 콘텐츠 분산 네트워크
Zulhasnine et al. Towards an effective integration of cellular users to the structured peer-to-peer network
Yu et al. Location-aware private service discovery in pervasive computing environment
Shen et al. A proximity-aware interest-clustered P2P file sharing system
Cai et al. Foreseer: a novel, locality-aware peer-to-peer system architecture for keyword searches
Saravanan et al. An effective model for QoS assessment in data caching in MANET environments
Aktas et al. Managing dynamic metadata as context
Harbird et al. Adaptive resource discovery for ubiquitous computing
Duan et al. Two-layer hybrid peer-to-peer networks
Cherbal et al. A survey of DHT solutions in fixed and mobile networks
Galluccio et al. Georoy: A location-aware enhancement to Viceroy peer-to-peer algorithm
Larbi et al. Improving cache effectiveness based on cooperative cache management in MANETs
KR101224827B1 (ko) Ｄａｃｏｎ 을 이용한 네트워크 시스템 및 네트워크 연결방법
Ijaz et al. A survey and comparison on overlay‐underlay mapping techniques in peer‐to‐peer overlay networks
Sözer et al. A peer-to-peer file search and download protocol for wireless ad-hoc networks
Singh et al. Resource-Cardinality Based Scheme to Reduce Resource Lookup Cost in Structured P2P Networks
JP2005252986A (ja) 動的なネットワークにおけるサービス選択方法およびサービス選択システム
Singh et al. Finger forwarding scheme to reduce lookup cost in structured P2P networks
CN102104518B (zh) 一种用于VoIP服务的混合型Pastry网络
Niazi Self-organized customized content delivery architecture for ambient assisted environments

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
AMND Amendment
E902 Notification of reason for refusal
AMND Amendment
E601 Decision to refuse application
J201 Request for trial against refusal decision
AMND Amendment
E902 Notification of reason for refusal
B601 Maintenance of original decision after re-examination before a trial
S901 Examination by remand of revocation
GRNO Decision to grant (after opposition)
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20151224

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20161227

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20171221

Year of fee payment: 6

LAPS Lapse due to unpaid annual fee