KR20060100273A - 피어-투-피어 애플리케이션을 형성하기 위한 애플리케이션프로그래밍 인터페이스 - Google Patents

피어-투-피어 애플리케이션을 형성하기 위한 애플리케이션프로그래밍 인터페이스 Download PDF

Info

Publication number
KR20060100273A
KR20060100273A KR1020060024022A KR20060024022A KR20060100273A KR 20060100273 A KR20060100273 A KR 20060100273A KR 1020060024022 A KR1020060024022 A KR 1020060024022A KR 20060024022 A KR20060024022 A KR 20060024022A KR 20060100273 A KR20060100273 A KR 20060100273A
Authority
KR
South Korea
Prior art keywords
message
peer
network
computing device
node
Prior art date
Application number
KR1020060024022A
Other languages
English (en)
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 마이크로소프트 코포레이션
Publication of KR20060100273A publication Critical patent/KR20060100273A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • 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/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/54—Indexing scheme relating to G06F9/54
    • G06F2209/546—Xcast
    • 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/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Computer Hardware Design (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Telephonic Communication Services (AREA)
  • Stored Programmes (AREA)

Abstract

본 발명 방법 및 시스템은 서비스 지향 프레임워크, 구체적으로는 서비스 지향 메시징 시스템 상부에 구현하기 위한 멀티캐스트 프로그래밍 모델을 지원하는 API 세트(set)이다.
애플리케이션, API, 멀티캐스트

Description

피어-투-피어 애플리케이션을 형성하기 위한 애플리케이션 프로그래밍 인터페이스{APIS TO BUILD PEER TO PEER MESSAGING APPLICATIONS}
도 1은 본 발명에 따라 동작할 수 있는 컴퓨팅 시스템의 블록도.
도 2는 OSI(Open Systems Interconnection) 모델을 예시.
도 3은 본 발명 시스템이 형성될 수 있는 가능한 서비스 지향 메시징 시스템을 예시.
도 4는 도 3의 메시징 시스템을 사용하는 메시지 통신을 예시.
도 5는 멀티캐스팅 메쉬 접속 형태(topology)를 예시.
도 6은 본 발명 시스템에 대한 논리적인 메쉬의 실시예를 예시.
도 7은 본 발명의 실시예에서 메쉬를 구현하는데 사용되는 일반적인 객체 모델을 예시.
도 8은 본 발명의 실시예에서 메쉬를 생성하는 일반적인 흐름도.
도 9는 본 발명의 실시예에서 이웃 접속 프로세스를 예시.
도 10은 본 발명의 실시예에서 동기화기 프로세스를 예시.
도 11은 개시자가 새로운 노드(new node)인 경우, 한 쌍의 이웃들 간에 다양한 동기화 관련 메시지의 교환을 예시.
도 12는 메쉬에서 한 쌍의 기존 노드 간에서의 동기화 프로세스를 예시.
도 13은 기존 노드가 개시자인 경우, 기존 노드와 새로운 노드 사이의 동기화 프로세스를 예시.
도 14는 본 발명의 실시예에서 일반적인 플러딩 프로세스를 예시.
도 15는 본 발명의 실시예에서 메시지 처리 프로세스를 예시.
도 16은 본 발명의 실시예에서 메쉬 관리 프로세스를 예시.
도 17은 본 발명에 따른 방법의 흐름도.
<도면의 주요 부분에 대한 부호의 설명>
201: 물리적 계층
202: 데이터 링크 계층
203: 네트워크 계층
204: 트랜스포트 계층
205: 세션 계층
206: 프리젠테이션 계층
207: 애플리케이션 계층
인터넷상에서의 그룹 통신 기술은 공통 관심사를 가진 사용자가 멀티-플레이어(multi-player) 게임에 참가하고, 프리젠테이션과 그룹 미팅을 위해 멀티캐스트 오디오 및 비디오로 서로 대화하고, 파일을 공유하고, 협력하도록 해준다. 사실, 애드 혹(ad hoc) 기반의 그룹 구성 기능(ability)은 공통 관심사를 가진 사용자들이 가상 영역에서 또는 일반적인 인터넷 대중으로부터 분리될 수 있는 그룹으로 모이도록 하여 같은 의견을 가진 개개인들 사이에 공동으로 가치있는 토론을 용이하게 하도록 해주는 주목할 만한 장점을 제공한다. 그러나 현재 대부분의 그룹 통신과 그룹 구성은 서버 중심의 환경에서 발생하여서, 모든 통신은 대용량 중앙 서버로 흘러들어 가거나, 이 서버를 통해 이루어져 개개인은 그룹에 가입 및 참가하려고 이 서버에 접속할 수 있다.
피어-투-피어 기술은 사용자가 서버 기반의 인터넷 통신의 제약으로부터 자유로운 서버리스(serverless) 환경에서 서로 접촉하도록 해준다. 피어-투-피어 기반의 시스템에서는, 통신이 네트워크 내의 피어들 사이에 직접적으로 발생하기 때문에 사용자 익명성 및 사적 자유가 유지될 수 있다. 그러나, 개개인 간의 통신 및 파일 공유가 피어-투-피어 네트워크에서 상대적으로 잘 확립될 수 있지만, 그룹 피어-투-피어 환경에서 정보를 형성하고, 발견하고, 참가하고, 유지하고, 공유하는 것은 잘 확립되지 않는다. 그러나, 개개인들이 서버 중심의 환경에서 이런 그룹화 기술이 제공하는 이점에는 점점 더 익숙해져 왔다.
본 발명의 방법 및 시스템은 서비스 지향 프레임워크, 구체적으로는 서비스 지향 메시징 시스템의 상부에 구현되는 멀티캐스트 프로그래밍 모델을 지원하는 API 세트이다. 이는 IP 멀티캐스트 기반구조(infrastructure)를 요구함 없이 애플리케이션-계층 멀티캐스트 기능을 제공한다. 본 발명의 시스템은 서비스 지향 애 플리케이션이 멀티캐스팅 통신을 쉽고 효율적으로 구현할 수 있도록 해준다. 또한, 본 발명의 멀티캐스트 방법 및 시스템은 멀티캐스트 프로세스를 향상할 수 있는 피어-투-피어 애플리케이션을 위한 메쉬 토폴로지(topologies)를 생성 및 유지하는 관리 프로세스를 제공한다. 이들 프로세스의 일부는 채널 감시 및 전송 서비스; 플러딩(flooding) 및 필터링 서비스; 광고(advertising) 서비스; 접속 유지 서비스; 상호(cross) 도메인 인터넷 광역 메쉬 기능; 및 서버리스 피어 결정 서비스(serverless peer resolution service)를 포함할 수 있다.
이하의 본문은 수많은 다른 실시예에 대해 상세한 설명을 기술하고 있지만, 상세한 설명의 합법적 범위는 본 명세서의 후반부에 기술된 청구항의 문장에 의해 정의됨을 이해해야 한다. 상세한 설명은 단지 예시로서 구성되어 있고, 모든 가능한 실시예를 기술하기란 불가능하므로 모든 가능한 실시예를 기술하고 있지는 않는다. 수많은 다른 실시예가 현재의 기술 또는 본 명세서의 출원일 이후 개발된 기술을 사용하여 구현될 수 있으며, 이들도 여전히 청구항의 범위 내에 속할 것이다.
또한, 용어가 본 명세서에서, "본원에서 사용된 바와 같이, 용어 "_____"는 이것에 의하여 ...를 의미하도록 정의된다"라는 문장을 사용하여 또는 유사한 문장을 사용하여 명백히 정의되지 않는 한, 그 문자 그대로 또는 평소의 의미 이상으로, 그 용어의 의미를 명백히 또는 명시적으로 제한하려는 의도는 없으며, 이런 용어는 본 명세서의 어느 한 섹션에 행해진 어느 한 문장(청구항의 언어를 제외함)에 근거하여 범위를 제한받는 것으로 해석되어서는 안 된다. 본 명세서의 후반부의 청구항에 인용된 임의 용어는 본 명세서에서 단일 의미와 상통하는 방식으로 지칭되는 정도까지, 이는 독자를 혼란하게 하지 않을 정도로 명료하게 행해지고, 이런 청구항 용어는 명시적으로 또는 다른 경우에, 그 단일 의미로 제한되도록 의도되지는 않는다. 마지막으로, 청구항의 구성요소가 임의 구조를 상술함 없이 "수단(means)" 및 기능(function)이란 용어를 인용함으로써 정의되지 않는 한, 임의 청구항 구성요소의 범위는 35 U.S.C
Figure 112006018190559-PAT00001
112, 6 단락 적용에 근거하여 해석된다고 의도하지는 않는다.
도 1은 본 발명 방법 및 장치 블록 계통이 구현될 수 있는 적합한 컴퓨팅 시스템 환경(100)의 일례를 예시한다. 컴퓨팅 시스템 환경(100)은 단지 적합한 컴퓨팅 환경의 예일 뿐이며, 본 발명의 방법 및 장치의 기능 또는 사용의 범위에 대해 제한하려는 것으로 의도되지 않는다. 컴퓨팅 환경(100)은 예시적인 동작 환경에 예시된 어느 한 컴포넌트 또는 컴포넌트들의 결합에 관련하여 임의 종속성 또는 요건을 가지는 것으로 해석되어서는 안 된다.
본 발명의 방법 및 장치 블록은 수많은 다른 범용 또는 전용 컴퓨팅 시스템 환경 또는 구성에서 동작한다. 본 발명의 방법 또는 장치에 사용되기 적합한 공지된 컴퓨팅 시스템, 환경, 및/또는 구성의 예로서 퍼스널 컴퓨터, 서버 컴퓨터, 휴대형 또는 랩톱 장치, 마이크로프로세서 시스템, 마이크로프로세서 기반의 시스템, 셋톱 박스, 프로그램가능한 가전 제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템 또는 장치 등의 임의 것을 포함하는 분산 컴퓨팅 환경을 포함하나 이에만 한정되지 않는다.
본 발명의 방법 및 장치 블록은 컴퓨터에 의해 실행되는 프로그램 모듈 등의 컴퓨터-실행가능 명령어들의 일반적인 관점에서 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 작업을 수행하거나 특정 추상화 데이터형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명의 방법 및 장치는 또한 통신 네트워크를 통해 링크된 원격 프로세싱 장치가 태스크를 수행하는 분산 컴퓨팅 환경에서 실시될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및 원격 컴퓨터 저장 매체들에 위치할 수 있다.
도 1을 참조하여, 본 발명의 방법 및 장치 블록을 구현하기 위한 예시적인 시스템은 컴퓨터(110) 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들은 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함해서 다양한 시스템 컴포넌트들을 프로세싱 유닛(120)에 결합시키는 시스템 버스(121)를 포함할 수 있으나, 이에만 한정되지 않는다. 시스템 버스(121)는 메모리 버스 또는 메모리 제어기, 주변 장치 버스, 다양한 버스 아키텍처 중 임의의 것을 사용하는 로컬 버스를 포함하여 여러 형태의 버스 구조들 중 임의의 것일 수 있다. 예로서, 이런 아키텍처는 업계 표준 구조(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, Enhanced ISA(EISA) 버스, 비디오 전자 공학 표준 협회(VESA) 로컬 버스, 및 메자닌 버스라고 알려진 주변 장치 상호 연결(PCI) 버스를 또한 포함하나, 이에만 한정되지 않는다.
컴퓨터(110)는 전형적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨 터 판독가능 매체는 컴퓨터(110)에 의해 액세스 될 수 있는, 휘발성 혹은 비휘발성 매체, 분리형 혹은 비분리형 매체 모두를 포함하는 임의 이용가능한 매체일 수 있다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체와 통신 매체를 포함하며, 이에만 한정되지 않는다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어들, 데이터 구조, 프로그램 모듈, 또는 기타 데이터 등의 정보를 저장하기 위한 임의의 방법 또는 기술로 구현된 휘발성 혹은 비휘발성, 분리형 혹은 비분리형 매체 모두를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD, 또는 기타 광디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치, 또는 기타 자기 저장 장치, 또는 컴퓨터(110)에 의해 액세스 될 수 있는 원하는 정보를 저장하는데 사용될 수 있는 기타 다른 매체들을 포함하고, 이에만 한정되지 않는다. 통신 매체는 전형적으로 컴퓨터 판독가능 명령어들, 데이터 구조, 프로그램 모듈, 또는 기타 데이터를 반송파 또는 기타 트랜스포트 메커니즘 등의 변조된 데이터 신호에 구현한 것이며, 임의의 정보 전달 매체를 포함한다. 용어 "변조된 데이터 신호"는 그 신호의 하나 이상의 특징을 신호에 있는 정보를 부호화하는 방식으로 설정 또는 변경시킨 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크, 또는 유선에 의한 직접 연결 등의 유선 매체와, 음파, RF, 적외선 등의 무선 매체, 및 기타 무선 매체를 포함하고, 이에만 한정되지 않는다. 상기의 것들을 임의로 결합한 것도 컴퓨터 판독가능 매체의 범위 내에 또한 포함되어야 한다.
시스템 메모리(130)는 판독 전용 메모리(ROM:131) 및 임의 접근 메모리 (RAM:132)와 같은 휘발성 및/또는 비휘발성 형태의 컴퓨터 저장 매체를 포함한다. 시작할 때 등에 컴퓨터(110) 내의 구성 요소들 사이의 정보 전달을 돕는 기본적인 루틴들을 포함하는 기본 입력/출력 시스템(BIOS:133)은 전형적으로 ROM(131)에 저장된다. RAM(132)은 전형적으로 프로세싱 유닛(120)에 의해 현재 동작되거나/되는 즉시 액세스 가능한 프로그램 모듈 및/또는 데이터를 포함한다. 예로서, 도 1은 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 예시하나, 이에만 한정되지 않는다.
컴퓨터(110)는 또한 기타 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1은 비분리형 비휘발성 자기 매체로부터 판독하거나 이에 기입하는 하드 디스크 드라이브(141), 분리형 비휘발성 자기 디스크(152)로부터 판독하거나 이에 기입하는 자기 디스크 드라이브(151), 및 CD-ROM 디스크 또는 기타 광매체와 같은 분리형 비휘발성 광디스크(156)로부터 판독하거나 이에 기입하는 광디스크 드라이브(155)를 예시한다. 예시적인 동작 환경에서 사용될 수 있는 기타 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테입 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테입, 고체 상태 RAM, 고체 상태 ROM 등이 될 수 있으나, 이에만 한정되지 않는다. 하드 디스크 드라이브(141)는 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 전형적으로 연결되고, 자기 디스크 드라이브(151) 및 광디스크 드라이브(155)는 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 전형적으로 연결된다.
도 1에서 예시되고 상기 논의된 드라이브들 및 그 관련 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈, 및 기타 데이터의 저장을 컴퓨터(110)에 제공한다. 도 1에서, 예를 들면 하드 디스크 드라이브(141)는 운영 체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)를 저장하는 것으로서 도시된다. 이런 컴포넌트들은 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)와 동일하거나 다를 수 있음에 유의해야 한다. 운영 체제(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 그것들이 다른 복제본이라는 것을 예시하기 위해 본원에서는 다른 숫자를 병기하였다. 사용자는 키보드(162), 및 주로 마우스나 트랙볼 또는 터치 패드로 지칭되는 포인팅 장치(161) 등의 입력 장치를 통해 명령어와 정보를 컴퓨터(110)에 입력할 수 있다. 기타 입력 장치(도시 생략)는 마이크로폰, 조이스틱, 게임 패드, 위성 접시형 안테나, 스캐너 등을 포함할 수 있다. 상기 장치들과 기타 입력 장치들은 자주 시스템 버스(121)에 결합된 사용자 입력 인터페이스(160)를 통해 프로세싱 유닛(120)에 연결되지만, 예를 들면, 병렬 포트, 게임 포트, 또는 범용 직렬 버스(USB)와 같은 버스 구조 및 기타 인터페이스에 의해 연결될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이스(190)와 같은 인터페이스를 통해 시스템 버스(121)에 연결될 수 있다. 모니터 이외에, 컴퓨터는 출력 주변 인터페이스(190)를 통해 연결될 수 있는 스피커(197)와 프린터(196) 등의 기타 출력 주변 장치들도 포함할 수 있다.
컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터들로의 논리적 연결을 사용하는 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치, 또는 기타 공동 네트워크 노드일 수 있으며, 메모리 저장 장치(181)만이 도 1에 예시되었을지라도 컴퓨터(110)에 관련되어 상기에 기술된 구성요소들 중 다수 혹은 모두를 전형적으로 포함한다. 도 1에 도시된 논리적 연결들은 근거리 통신망(LAN:171)과 광역 통신망(173:WAN)을 포함하나, 기타 네트워크들도 포함할 수 있다. 그러한 네트워킹 환경들은 사무실, 기업 규모 컴퓨터 네트워크, 인트라넷 및 인터넷에서 흔한 것이다.
LAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 네트워크 인터페이스(170)나 어댑터를 통해 LAN(171)으로 연결된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 전형적으로 인터넷과 같은 WAN(173)을 거쳐 통신을 설정하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장 또는 외장될 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메커니즘을 통해 시스템 버스(121)로 연결될 수 있다. 네트워크 환경에서, 컴퓨터(110)에 관련되어 도시된 프로그램 모듈이나 그 일부는 원격 메모리 저장 장치에 저장될 수 있다. 예로서, 도 1은 메모리 장치(181)에 상주하는 원격 애플리케이션 프로그램(185)을 예시하나, 이에만 한정되지 않는다. 도시된 네트워크 연결들은 예시적이며, 컴퓨터들 사이에 통신 링크를 설정하기 위한 기타 수단들이 사용될 수 있다는 것을 인식해야 한다.
도 2는 본 발명의 방법 및 시스템의 양상을 기술하는데 사용될 수 있는 국제 표준화 기구("ISO")에 의해 개발된 개방형 시스템 간 상호접속("OSI")을 예시한다. OSI는 메시지가 원격통신(telecommunication) 네트워크의 두 지점 사이에 어떻게 전송될 수 있는가에 대한 표준화된 설명이다.
OSI 모델에 따르면, 원격통신 네트워크의 2개 종단 사이의 통신 프로세스는 각각이 그 자신의 특수한, 관련 기능 세트를 부가하는 계층들로 구분될 수 있다. 통신 기능의 컴퓨터는 7 계층의 기능을 구비할 수 있다. 사용자 사이에 정해진 메시지를 통신함에 있어, 한 종단에서의 각 계층을 통해 해당 컴퓨터의 계층들을 통한 데이터의 하향 흐름이 존재할 수 있고, 다른 종단에서는 그 메시지들이 도달할 때, 수신 컴퓨터의 계층들을 통한, 결국 최종 사용자 또는 프로그램에 이르는 데이터의 상향의 또 다른 흐름이 존재할 수 있다. 7 계층의 기능을 제공하는 실제 프로그래밍 및 하드웨어는 통상적으로 컴퓨터 운영 체제, 애플리케이션, 전송 제어 프로토콜("TCP")/인터넷 프로토콜("IP") 또는 대체 트랜스포트 프로토콜 및 네트워크 프로토콜, 및 신호가 컴퓨터에 부착된 라인 중 하나에 실리도록 해주는 소프트웨어와 하드웨어가 결합된 것일 수 있다.
OSI는 통신을 7 계층으로 구분한다. 계층은 2그룹으로 분류된다. 상위 계층(209)은 메시지가 사용자로부터 또는 사용자에게 전달될 때마다 사용되고, 하위 계층(208)은 임의 메시지가 호스트 컴퓨터를 통해 전달될 때 사용된다. 이 컴퓨터로 의도된 메시지들은 상위 계층(209)으로 전달된다. 일부 다른 호스트로 예정된 메시지들은 상위 계층으로 전달되지 않고, 또 다른 호스트로 포워딩된다. 7계층은 간략히 다음과 같이 기술된다.
물리적 계층(201)은 기계적인 컴포넌트 및 커넥터 등의 인터페이스의 물리적 특징, 2진 값을 나타내는 전압 레벨 등의 전기적 양상, 및 물리적 링크의 셋업, 유지, 및 해제 등의 기능적인 양상을 정의한다. 데이터 통신을 위한 공지된 물리적 계층 인터페이스는 직렬 인터페이스, 병렬 인터페이스, 및 이더넷 및 토큰 링 등의 LAN 시스템의 물리적 규격(specification)을 포함한다.
데이터 링크 계층(202)은 2개 시스템 사이의 물리적 연결에 걸쳐 정보를 송신 및 수신하는 규칙을 정의한다. 데이터 링크는 전형적으로 네트워크 세그먼트(인터-네트워크가 아님)이고 점-대-점(point-to-point) 링크이다. 데이터는 기본적인 물리적 네트워크에 걸쳐 전송되는 프레임으로 패키지화된다. 수신된 데이터의 수신확인 등의 일부 신뢰성 기능이 사용될 수 있다.
네트워크 계층(203)은 복수의 네트워크에 걸쳐 데이터를 전송하는 인터-네트워킹 서비스를 제공한다. 인터네트워크 주소지정 방법(scheme)은 각 네트워크와 각 노드에 고유한 주소를 지정하는 것이다. 네트워크 계층은 복수의 데이터 링크 연결을 지원한다. 인터넷 프로토콜 스위트(suite)에서, IP는 네트워크 계층 인터네트워킹 프로토콜이다.
트랜스포트 계층(204)은 종단-대-종단 통신 서비스를 제공하고, 데이터가 이들 종단 시스템 사이에 신뢰성 있게 전송되도록 보장한다. 두 종단 시스템들은 연결을 설정하고, 네트워크에 걸쳐 패킷의 전달을 추적하도록 다이얼로그에 관여한다. 이 프로토콜은 또한 저속의 수신기에 순응하도록 패킷의 흐름을 조정하고, 링크의 단절이 발생할 경우 전송이 완벽히 중단되지 않도록 보장한다. 전송 제어 프로토콜("TCP")은 트랜스포트 계층 프로토콜일 수 있다.
세션 계층(205)은 대화 기술 또는 다이얼로그를 사용함으로써, 시스템 사이의 정보 교환을 조정한다. 다이얼로그가 항상 요구되는 것은 아니지만, 일부 애플리케이션은 연결이 임시적으로 유실될 경우 데이터의 전송을 어디서 재시작할지 알아낼 방법을 요구할 수 있거나, 한 데이터 세트의 마지막 및 새로운 데이터 세트의 시작을 지시하기 위해 주기적인 다이얼로그를 요구할 수 있다.
프리젠테이션 계층(206)은 사용자가 워크스테이션에서 실행하는 운영 체제와 애플리케이션의 일부분인 프로토콜을 포함한다. 이 계층에서는 정보를 디스플레이 또는 프린트를 위해 포맷한다. 데이터 내의 코드를 번역하고, 데이터 암호화와 변환 또한 이 계층에서 처리된다.
애플리케이션 계층(207)은 기본적인 네트워크 서비스를 액세스하는 정의된 프로시저를 제공한다. 애플리케이션 계층은 사용자 애플리케이션의 범위를 정의하는데 사용된다.
멀티캐스팅 기술은 OSI 모델의 하위 레벨(208), 즉 트랜스포트/네트워킹 계층에 대해 개발되고 있으나, 본 발명의 시스템은 멀티캐스팅을 OSI 모델의 상위 레벨(209)에서 구현하는 애플리케이션-레벨 프로그래밍 모델을 제공하는데 초점을 맞추고 있다. 그러므로, 본 발명의 방법 및 시스템을 사용하는 개발자는 IP 멀티캐스트 기반구조를 요구함 없이 멀티캐스팅 기능을 구현할 수 있다. 또한, 본 발명의 시스템은 서비스 지향 프로그래밍 모델을 개선할 수 있으며, 이는 이하에 기술된다.
서비스 지향 프레임워크와 프로그래밍 모델
( Service Oriented Frameworks and Programming Models )
서비스-지향은 서비스 지향 프레임워크가 "애플리케이션"을 어떻게 정의하는가에 있어 일차적으로 객체-지향과 다를 수 있다. 객체-지향 개발은 상호 의존적인 클래스 라이브러리로부터 형성된 애플리케이션에 초점을 맞출 수 있는, 반면에 서비스-지향 개발은 독자적인 서비스 세트로부터 형성된 시스템에 초점을 맞출 수 있다. 서비스는 단순히 사람이 메시지 교환을 통해 대화하는 프로그램일 수 있다. 그러나, 기존의 분산 객체 기술과는 달리, 서비스들은 잘 정의된 XML 인터페이스를 통해서만 그들 클라이언트와 대화할 수 있다. 서비스 경계를 넘어선 완전한 클래스, 메소드, 및 호출을 전달하기 등의 거동은 허용될 수 없다. 그러므로, 애플리케이션 개발자 및 시스템 통합자는 통합되는 소프트웨어의 기본적인 객체 모델, 시스템 유형, 및 프로토콜에 대한 특정한 지식을 필요치 않을 수 있다.
분산 객체 시스템에서와 같은 직접 객체 구동(activations)을 통해 이질적인 애플리케이션을 통합하는 대신에, 애플리케이션은 다른 애플리케이션이 이용할 수 있는 "서비스" 세트를 노출시킬 수 있다. 서비스 프레임워크를 이용하는 애플리케이션은 표준 기반의 프로토콜과 동적으로 획득될 수 있는 정책 정의를 사용하여 그들의 서비스를 노출시킬 수 있다. 이런 연결된 시스템을 구성하는 애플리케이션의 분리는 보다 단순한 통합을 가능케 하고, 시간에 따른 변화에 시스템을 적응시키는데 있어서 보다 유연성있게 할 수 있으며, 또한 보다 신뢰성 있는 동작을 가능케 할 수 있다.
기존의 서비스 지향 프로그래밍 모델은 "SOAP(Simple Object Access Protocol)" 등의 기존의 상위 OSI 레벨 메시징 서비스를 구현할 수 있다. SOAP는 메시지에 대한 스키마를 제공하는 상위 레벨 OSI 서비스로서 동작할 수 있다. SOAP 프로토콜을 사용하는 메시징 시스템의 한 가지 가능한 실시예가 도 3에 예시되어 있다. 예시된 메시징 시스템 아키텍처(이하에, "메시지 버스(Message Bus)")는 SOAP 노드의 개발 및 유지를 단순화하기 위한 애플리케이션 프로그래밍 인터페이스("API")로서 보여질 수 있다. 본 발명의 시스템 및 방법은 기본 상위-레벨 메시지 처리를 제공하는 임의의 서비스 지향 모델에 대해 구현될 수 있지만, 증명하기 위해 본 발명의 방법 및 시스템은 도 3에 예시된 메시지 버스를 사용하여 기술될 것이다.
도 3에 예시된 바와 같이, 메시지 버스 네트워킹 계층(301) 및 트랜스포트 계층(302)은 현존하는 전형적인 트랜스포트 계층/네트워킹 계층 프로토콜 중 하나로 구성될 수 있다. TCP/IP는 보편적인 트랜스포트 계층/네트워크 계층 프로토콜이고, IP 멀티캐스트가 작동될 필요가 없을 수 있고, 이는 본 발명의 애플리케이션-레벨 멀티캐스트 시스템을 사용하는 것에 대한 이점이다. 트랜스포트 계층은 IP 소켓, 명명된 파이프(named pipe), 또는 데이터를 전달할 수 있는 임의 메커니즘 등의 네트워킹 메커니즘을 캡슐화시킬 수 있다. 메시지 버스 트랜스포트(303)는 메시지들을 데이터-링크와 물리적 계층을 통해 와이어 상으로 전달될 실제 바이트 로 변환할 수 있다.
프리젠테이션/세션 계층(304)으로 이동하여, 포트 객체(305)는 메시지를 위한 구성가능한, 논리적인 관로(conduit)를 나타낼 수 있다. 각 포트 객체(305)는 그 포트가 논리적인 메시지들을 실제 네트워크 통신으로 변환하는데 사용하는 트랜스포트(303)의 집합(collection)을 가진다. 포트는 내부적으로 한 쌍의 파이프라인 객체, 즉 송신 파이프라인(306)과 수신 파이프라인(307)으로 구현된다. 각 파이프라인은 포트 확장을 구성하는 플러그가능한 메시지 핸들러(도시 생략)를 지원할 수 있어, 파이프라인을 따라 이동하는 메시지들을 검사하고 조작할 수 있다. 메시지 버스를 사용하는 애플리케이션의 전형적인 노드는 단지 하나의 포트 객체만을 인스턴스화할 수 있지만, 하나 이상을 생성하는 것도 가능하다. 이런 설명의 나머지 부분에서는 사용자가 이런 설명을 개념화하도록 지원하려는 노력에서 포트를 지칭할 것이지만, 포트의 사용이 현대의 메시지 버스 아키텍처에서는 불필요할 수 있다.
애플리케이션 계층(309)에서, 애플리케이션 코드(310)는 메시지들을 채널 객체(308)를 통해 포트 객체에 송신할 수 있다. 채널 객체는 다양한 실시예로 도입되고, 이는 2개 세트, 즉 송신 채널 및 수신 채널로서 세분화될 수 있다. 단일 채널 클래스가 또한 송신 및 수신 채널 둘 다 구현할 수 있다.
메시지 버스는 다양한 메시지 교환 패턴을 고려하는 다양한 채널 구현예를 지원할 수 있다. 예를 들어, 단방향 데이터그램-스타일 메시지를 위한 단순 채널은 단지 최종 수신자를 나타낼 수 있다. 반면에, 보다 복잡한 채널은 상관된 쌍방향 메시징, 신뢰성있는 메시징, 또는 애플리케이션의 실행에 걸쳐 메시지 지속성을 지원할 수 있다. 채널은 애플리케이션 코드에 의해 생성된 메시지 객체가 기반구조 코드(예컨대, IP)에 전달될 수 있는 제1 지점이고, 애플리케이션 코드의 관점에 서 채널은 메시지 버스 아키텍처에 있어서 확장될 수 있는 제1 지점이다.
메시지를 메시지 버스 프레임워크를 사용하여 송신 및 수신하는 일반적인 프로세스는 다음과 같을 수 있다.
1. 메시지 객체가 개시 송신자에 의해 생성된다.
2. 메시지 객체로의 참조를 채널에 전달함으로써, 메시지를 전송한다.
3. 채널은 메시지를 그 채널과 연관된 포트 객체에 전달한다.
4. 포트는 메시지를 포트의 송신 파이프라인 내로 도입하고, 여기서 메시지는 그 파이프라인에 등록된 각 메시지 핸들러에 의해 연속으로 처리된다.
5. 메시지가 송신 파이프라인의 종단에 도달하면, 포트는 메시지 참조를 그 포트에 등록된 트랜스포트 객체에 전달한다. 트랜스포트 객체는 메시지의 다음 홉(next hop)의 주소에 근거하여 선택된다.
6. 트랜스포트 계층은 메시지를 바이트의 스트림으로 포맷하고, 바이트들을 네트워크로 내보낸다(push).
이 시점에서, 메시지들은 SOAP 노드를 떠나 네트워크 클라우드(cloud)로 진입한다. 메시지들이 전달에 있어 다음 SOAP 노드에 도달할 때까지, 메시지는 더 이상 메시지 버스 또는 SOAP에 영향받지 않는다. 대신에, 메시지는 TCP/IP 또는 HTTP 등의 네트워킹 프로토콜을 통해 전달되는 바이트들의 스트림일 수 있다.
일부 시점에서, 메시지의 바이트들이 SOAP 노드인 네트워크상의 리스닝 노드에 도달한다. 이하 것들은 리스닝 노드에서 발생할 수 있다.
1. 트랜스포트-파생 객체는 바이트들의 스트림을 수신하고, 그 바이트 스트 림으로부터 메모리에 메시지 객체를 생성한다. 메시지 헤더는 메모리 내에 완전히 판독되지만, 메시지 내용은 트랜스포트에 남겨져, 이것이 필요할 때까지 가능한 와이어 상에 유지된다.
2. 그런 다음 트랜스포트는 메시지 참조를 트랜스포트 객체가 등록된 포트의 수신 파이프라인 내에 전달한다.
3. 메시지는 수신 파이프라인에 등록된 각 메시지 핸들러에 의해 연속으로 처리된다. 메시지 핸들러가 메시지를 처리하기로 결정하면, 이것은 수신 파이프라인으로부터 메시지를 받아들일(pull) 수 있고, 그 메시지를 메시지 핸들러에 연관된 채널에 전달한다.
4. 메시지가 포트의 수신 파이프라인의 종단에 이르면, 포트는 그 메시지를 포트의 메인 수신 채널에 등록된 애플리케이션-정의된 메시지 핸들러에 전달한다.
5. 애플리케이션 코드는 메시지 객체에 대한 참조를 가지며, 이것으로 애플리케이션 코드는 원하는 것을 행할 수 있다. 전형적으로, 메시지의 액션-헤더를 체크하고, 메시지의 내용을 처리한다.
6. 일단 애플리케이션 코드가 메시지와 함께 종결되면, 메시지 버스는 트랜스포트를 클리어(clear)하기 위해 메시지 내용에 남겨진 아직 판독되지 않은 바이트를 판독해 버리고, 메시지 객체는 쓰레기 집합(garbage collection)으로 남겨진다.
7. 메시지가 개시 송신자에서 최종 수신자에 이르는 도상에 SOAP 중개자를 통해 전달되면, 중개자는 또한 이전에 간략히 말한 바와 같은 송신 단계뿐만 아니 라 수신 단계를 사용하여 메시지를 처리한다. 중개자는 단일 메시지의 송신자이며 수신자인 노드이다. SOAP 라우터는 중개자의 일반적인 예이다.
도 4는 메시지가 개시 송신자(401)로부터 2개의 중개자(403 및 404)를 통해 최종 수신자(402)에 이를 수 있는 경로를 예시한다. 도 4는 송신 파이프라인(405) 만이 개시 송신자(401)에 의해 이용될 수 있고, 수신 파이프라인(406) 만이 최종 수신자에 의해 이용되는 경우를 예시한다. 한편, 중개자(403 및 404)에서의 전송(409 및 408) 및 수신 파이프라인(407 및 410)은 메시지를 처리하는데 이용된다. 개시 송신자 및 최종 수신자의 역할이 응답 메시지의 경로에서는 뒤바뀔 수 있다는 것에 유의한다.
메시지 버스 프레임워크는 서비스 지향 프레임워크를 사용하여 서비스를 구현하는 기본 메커니즘을 제공하지만, 멀티캐스트 기능을 가능케 하기 위한 설비(provision)는 없다. 본 발명의 방법 및 시스템은 이런 서비스 지향의 메시지 버스 아키텍처 상에 형성되어 개발자에게 서비스 지향의 모델 상부에 그들 애플리케이션에 멀티캐스팅 기능을 추가하는 형성 기능을 제공한다.
멀티캐스트 메쉬 시스템( Multicast Mesh Systems )
본 발명의 시스템 및 방법은 메쉬(mesh)라고 알려진 특정 멀티캐스트 접속 형태를 구현할 수 있다. 도 5는 가능한 메쉬 접속 형태를 예시한다. 일반적으로, 멀티캐스트 그룹의 멤버는 노드(501)라고 불릴 수 있고, 그룹은 메쉬(500)로 여겨질 수 있으며, 통신 채널(예를 들어, 참조번호(509))을 사용하여 서로 상호접속되는 노드들(501-508)의 세트에 의해 표현된다. 메쉬의 각 노드(501-508)는 전달 프 로세스를 통해 메쉬의 모든 다른 노드 각각에 메시지를 전달할 수 있고, 여기서 한 노드(예를 들어, 참조번호(501))에 의해 전송된 각 메시지가 이웃 노드들(502-505)에 전달되도록 하고, 각 노드가 그 메시지를 수신할 때까지 계속하여 자신의 이웃 노드들에 전달한다. 노드가 여러 접속을 가지는 경우, 노드는 메시지를 수신하여 자신에게 접속된 각 채널을 따라 송신하기 위하여 메시지를 복사할 수 있다. 전달의 방향이 일반적으로 메시지 송신자로부터이고 물리적 플러딩과 유사하기 때문에, 멀티캐스팅을 사용하는 메시지의 전달은 일반적으로 "플러딩(flooding)"이라고 불린다. 멀티캐스트 메쉬의 각 노드는 네트워크상에 플러딩된 임의의 메시지를 수신하여 알 수 있으며, 즉, 한 노드가 플러딩된 메시지를 통해 아는 것을 메쉬의 모든 노드가 알게 된다. 따라서, 합당한 크기의 메쉬, 또는 메시지가 계속하여 플러딩되어야 하는 경우에 대한 규칙을 가지는 것이 유용할 수 있다.
서비스 지향 메시징 시스템을 사용하는 멀티캐스트 메쉬 실시예
( Multicast Mesh Embodiment Using a Service Oriented Messaging System )
도 6은 본 발명의 멀티캐스트 메쉬 시스템의 일반적인 실시예를 도시한다. 본 실시예에서, 피어 노드(601)는 메쉬(602)에 접속된 노드이다. 메쉬는 메시지 또는 점-대-점 데이터 스트림의 형태로 데이터를 전달하기 위하여 이웃 채널들(607-611)에 의해 다중으로 접속되어 노드들의 접속 네트워크를 형성하는 피어 노드들(601-605)의 명명된 세트일 수 있다. 이 메쉬는 이웃 노드들에의 접속에 기초하여 형성되고, 여기서 메쉬의 이웃 노드는 하나의 통신 링크 만큼 떨어져 있는(통신 채널을 통해 직접 접속됨) 피어 노드이다.
피어 노드는 메쉬(602)에 접속된 애플리케이션(612)의 인스턴스와 관련될 수 있다. 피어 채널(613, 614)은 피어 노드에게 애플리케이션(612) 또는 서비스(서비스 지향 언어의)와 메쉬(602) 사이에서 메쉬의 피어 노드(601)를 통해 통신하기 위한 특정 채널이라고 여겨질 수 있다. 애플리케이션이 노드를 생성할 수 있지만 노드는 애플리케이션을 생성할 수 없다. 애플리케이션은 여러 노드를 생성할 수 있고, 각 노드는 여러 서비스를 호스팅할 수 있다. 예를 들어, 채팅 애플리케이션을 고려해 본다. 채팅 애플리케이션은 ChatMesh라고 불리는 메쉬에 노드를 생성할 수 있다. 채팅 애플리케이션은 VideoService 및 TextService라는 두 개의 상이한 서비스를 생성할 수 있다. 전송된 임의의 텍스트 메시지가 TextService에 전달될 수 있고, 전송된 임의의 비디오 메시지가 VideoService에 전달될 수 있다.
처음에 메쉬에 접속할 때, 피어 노드(601)는 이미 메쉬에 접속된 또 다른 피어 노드(예를 들어, 참조번호(603))에 접속할 수 있다. 접속하려는 피어 노드(601)는 메쉬에 접속된 이웃 노드(603)의 주소를 결정하고, 이웃 노드에게 메쉬에 합류하라는 간청(solicitation)을 송신할 수 있다. 메쉬에 접속한 후에, 새로운 피어 노드(601)는 메쉬 내의 부가적인 이웃 노드(예를 들어, 참조번호(604, 605))에의 접속(608, 610)을 생성할 수 있다.
메쉬의 목적은 모든 메쉬 노드에 메시지를 플러딩하기 위한 논리적 접속 형태를 생성하는 것일 수 있다. 플러딩을 위한 최적 접속 형태를 자동으로 달성하기 위하여, 메쉬는 서명, 접촉 노드(contact node)들의 세트를 유지할 수 있고, 중복하여 플러딩된 메시지를 평가하여 어떤 이웃이 더욱 효율적인지를 판정한다. 시간 이 흐름에 따라, 메쉬가 플러딩에 최적인 접속 형태에 수렴하도록 접속들이 생성 및 삭제될 수 있다.
노드가 메쉬로부터 접속이 단절되면, 노드는 잠재적으로 메쉬 분할(mesh partition)이라 불리는 메쉬의 브레이크(break)를 생성할 수 있다. 피어 노드는 그래프 분할을 검출 및 복구하기 위해 메쉬 접촉 정보 및 메쉬 서명(하기에 기술됨)을 사용한다.
피어 채널(613, 614)은 애플리케이션(612)과 피어 노드(601) 사이에서 송신 및 수신하는 통신 채널일 수 있다. 그들은 IP 구동(enabled) 멀티캐스팅 기반구조를 요구함 없이 애플리케이션에게 멀티캐스트 채널로서 보일 수 있다. 각 피어 채널(613, 614)은 피어 노드(601)와 관련될 수 있다. 피어 노드(601)는 메쉬 알고리즘(예를 들어, 최적화, 분할 검출 및 복구)을 구현하고 메시지를 메쉬 곳곳에 플러딩할 책임이 있을 수 있다. 각 피어 노드는 노드 서비스라 불리는 자신의 서비스를 제공할 수 있고, 그 서비스는 신뢰할 수 있는 메시지 버스 채널을 사용하여 이웃 노드 서비스들의 세트와 상호작용한다. 이 노드 서비스는 서비스 프레임워크의 상부에 구현될 수 있으며, 예를 들어, TCP 및 HTTP 트랜스포트를 통해 신뢰할 수 있는 채널을 사용한다.
피어 채널상에 전송된 메시지는 메쉬의 또 다른 노드에 의해 제공된 특정 서비스로 정해질 수 있다. 메쉬의 모든 노드는 메쉬상에 전송된 각 메시지의 사본을 수신할 수 있다. 노드가 메시지를 수신하면, 노드는 메시지의 의도된 서비스(message's intended service)를 구현하는 임의 관련된 피어 채널에 메시지를 전달 할 수 있다. 메시지를 메쉬의 각 노드에 전달하기 위하여, 발신 노드(originating node)는 메시지를 자신의 이웃 노드 각각에 송신할 수 있다. 이들 이웃 노드들은 메시지를 자신의 이웃 노드들에 전달하기 등을 할 수 있다. 실제 플러딩 알고리즘이 하기에 기술된다.
예를 들어, 애플리케이션 메시지는 하나의 이웃 피어 노드(601)로부터 또 다른 노드(602)에 애플리케이션 메시지 또는 내부 메시지를 노드의 이웃으로 향하는 또 다른 외부 메시지에 캡슐화함으로써 터널링될 수 있다. 새로운 외부 메시지는 이웃 노드별로 생성될 수 있다. 이러한 방식으로, 자신의 목적지 서비스(destination service) 주소를 포함하는 원시 메시지는 노드마다 변경되지 않고 유지될 수 있다. 모든 노드들은 모든 다른 노드들로부터의 세력 범위 내에 있을 수 있다. 이것이 사실이 아닌 경우(예를 들어, 횡단할 수 없는 방화벽 뒤에 있는 노드의 경우)에 한하여, 메쉬의 복원력(resilience)이 감소한다.
객체 모델 실시예( Object Model Embodiment )
도 7은 본 발명의 시스템의 실시예를 구현할 수 있는 객체들을 예시한다. 본 발명의 멀티캐스트 시스템의 객체들은 PeerChannel Factory(701), PeerChannel(702), PeerListenerFactory(703), PeerListener(704), PeerNode(705), Synchronizer(706), Maintainer(707), Connector(708), Flooder(709), NeighborManager(710) 및 Neighbor(711)로 구성될 수 있다. 논리적으로, 상기에 기술된 논리적 피어 노드는 PeerNode(705), Synchronizer(706), Connector(708), Maintainer(707), Flooder(709) 및 NeighborManager(710)로 구성되는 객체들의 세 트로서 구현될 수 있다.
PeerChannelFactory(701)는 PeerChannel(702)를 만들어낼 책임이 있을 수 있다. PeerChannelFactory(701)는 또한 자신이 생성하는 활성 채널들의 집합을 유지할 수 있다. PeerChannelFactory(701)는 PeerNode(705)와 직접적으로 관련이 없을 수도 있지만, 필요할 때 그것들을 참조하거나 생성한다.
PeerListenerFactory(703) 객체는 PeerListener(704)를 만들어낼 책임이 있을 수 있다. PeerListenerFactory(703)는 활성 리스너를 관리하고, 리스너들이 만들어낸 활성 채널들의 집합을 유지한다. PeerListenerFactory(703)는 정확히 하나의 PeerNode(705)와 관련될 수 있다.
PeerNode(705)는 메쉬의 노드를 표현할 수 있고, 관련 구성을 포함한다. PeerNode(705)는 노드를 구현하는 내부 컴포넌트들 모두의 소유자일 수 있다. 이 클래스는 또한 기존의 노드들을 참조하기 위한 정적 메소드를 포함할 수 있다.
Neighbor(711)는 기본적인 이웃 채널을 포함할 수 있고, 채널의 상태를 추적한다. Neighbor는 이웃 노드와 통신하기 위한 메소드를 노출할 수 있다.
NeighborManager(710)는 Neighbor(711)들의 집합을 포함할 수 있다. NeighborManager(710)는 모든 Neighbor(711)들의 집합체(aggregates)인 이벤트(예를 들어, MessageAvailable)를 노출할 수 있다. 이 객체는 피어 노드 서비스의 구현예를 제공할 수 있다.
Connector(708) 객체는 접속 메시지(CONNECT, WELCOME, REFUSE, DISCONNECT)들의 송신 및 수신을 처리할 수 있다.
Maintainer(707) 객체는 메쉬 유지 알고리즘(mesh maintenance algorithm)을 구현할 수 있다. Maintainer(707)는 메쉬 서명, 알려진 메쉬 노드들의 집합, 및 현재 메쉬 접촉의 집합을 포함할 수 있다.
Flooder(709)는 플러딩 로직(logic)을 구현할 수 있다. Flooder는 최근에 보여진 메시지들의 테이블을 포함할 수 있다.
Synchronizer(706)는 이웃 채널을 통해 경량 접촉/서명 동기화 프로토콜(light-weight contact/signature synchronization protocol)을 조화롭게 할 수 있다.
메쉬 구성( Mesh Construction )
메쉬는 이름 또는 메쉬 ID에 의해 식별될 수 있다. 메쉬 ID는 IP 주소(예를 들어, 123.12.123.12)로 결정될 수 있는 유효한 호스트이름(예를 들어, soccerpals)이다. 메쉬상의 서비스의 주소는 URI(uniform resource identifier)에 의해 지정될 수 있고, 피어 채널 스키마 접두어(net.p2p://), 메쉬 ID, 경로 및 서비스 이름(예를 들어, net.p2p://soccerpals/path/service)을 사용하여 명시된다. EndpointAddress 구조는 메쉬의 서비스들을 참조하기 위해 사용될 수 있고, 부분적으로 적어도 하나의 URI로 구성될 수 있다.
도 8은 본 발명의 객체 모델 실시예를 사용하여 메쉬를 생성하기 위한 프로세스를 예시한다. (후술되는 설명은 본 발명의 시스템의 객체들을 상기에 기술된 바와 같이 예를 들어 PeerNode, PeerChannel 등과 같은 상기에 열거된 이름들을 사용하여 참조할 것이다.)
일반적으로, 서비스 또는 클라이언트가 메쉬와 통신하기를 원할 때마다, 그 서비스 또는 클라이언트는 메쉬의 PeerNode를 통해 통신하도록 요구될 수 있다. 상세히 기술하자면, 서비스는 PeerListenerFactory와 관련될 수 있고, 클라이언트는 PeerChannelFactory와 관련될 수 있다. 이 프로세스는 PeerChannelFactory를 먼저 생성(단계(801))하고 오픈(open)(단계(802))하는 애플리케이션을 수반할 수 있다. PeerChannelFactory는 애플리케이션 내의 객체로서 인스턴스화될 수 있고, 따라서 애플리케이션과 관련될 수 있다. 다음, CreateChannel이라 불릴 수 있는 PeerChannelFactory의 메소드를 호출함으로써 PeerChannel이 생성될 수 있다(단계(803)). 그 후 PeerChannel은 관련 PeerNode가 존재하는지를 알기 위하여 검사될 수 있다(단계(804)). 관련 PeerNode가 존재하는 경우, PeerChannel은 그 PeerNode에 접속하여 PeerChannel을 오픈하고(단계(805)), 메시지를 수신 및 송신하기 시작할 수 있다(단계(806)). 그렇지 않은 경우, 기존의 PeerNode가 존재하지 않으면, PeerChannel은 새로운 PeerNode를 생성하고(단계(807)), PeerChannel을 오픈하며(예를 들어, PeerChannel의 OPEN 함수를 호출하고, EndpointAddress에 전달함으로써)(단계(808)), 새로운 PeerNode를 오픈할 수 있다(단계(809)).
새로운 PeerNode를 오픈할 때, PeerNode는 이름 결정 서비스(name resolution service)를 제공할 책임이 있는 Resolver 객체를 호출할 수 있다. RegisterMeshID, UnregisterMeshID 등을 포함하는 여러 Resolver 메소드가 존재할 수 있다. Resolver 메소드는 커스텀 이름 결정 서비스를 구현할 수 있고, 또는 피어 이름 결정 프로토콜(Peer Name Resolution Protocol, "PNRP")과 같은 메시지 버 스-제공 결정 서비스(Message Bus-provided resolution service)를 사용할 수 있다. 새로 생성된 PeerNode는 Resolver를 호출하여 노드 서비스를 등록할 수 있는데(단계(810)), 이 노드 서비스는 내부 구현을 위해 각 PeerNode에 의해 고유하게 제공되는 서비스이다. 이러한 노드 서비스는 새로운 PeerNode의 생성을 개시했거나, 기존의 PeerNode에의 접속을 개시했던 애플리케이션 서비스와 상이할 수 있다. Resolver에 등록함으로써, 노드 서비스 참조를 통해 다른 노드들은 새로 생성된 PeerNode에의 참조를 획득할 수 있다.
노드 서비스를 등록하는 것 이외에, PeerNode는 메쉬의 다른 노드들에 대해 Resolver에 질의할 수 있다(단계(811)). 리졸버의 ResolveMeshId 메소드를 호출하지 않고서, 노드는 (다른 노드들 중 하나의 노드가 이 노드에의 접속을 개시하지 않는 한) 메쉬에 다른 노드들이 존재하는지를 알 수 없다. 어떤 다른 노드도 존재하지 않는 경우, PeerNode는 PeerChannel에게 지시(indication)를 발생시킬 수 있고, 그것은 Application에게 경보를 발생시킨다. 다른 노드들이 존재하는 경우, PeerNode는 자신의 Maintainer 객체를 호출하여 메쉬 ID를 원격 노드 서비스의 EndpointAddress로 결정할 수 있다. EndpointAddress가 획득되면, NeighborManager가 사용되어 NeighborNode에의 NeighborChannel을 생성할 수 있다(단계(811)). NeighborChannel이 생성되면, CONNECT 메시지를 송신함으로써 접속이 시도될 수 있다(단계(812)). WELCOME 메시지가 수신되는 경우, PeerNode가 오픈되어 온라인일 수 있어, 동기화 프로세스가 시작된다. REFUSE 메시지가 수신되는 경우, PeerNode가 부가적인 접속을 시도할 수 있다. PeerNode가 어떠한 다른 노드도 발견하지 못하거나 어떠한 다른 노드에도 접속하지 못하는 경우, PeerNode는 자신을 오프라인 상태로 설정할 수 있고(단계(813)), 그렇지 않은 경우에, PeerNode는 온라인일 수 있으며(단계(814)), 메시지를 수신 및 송신할 수 있다(단계(815)).
일반적으로, 상기 프로세스는 초기 채널 생성 블럭을 제외하면 PeerListener 프로세스와 유사할 수 있다. 그 서비스에 타겟화된 메시지에 의해 간청된 후에 메쉬와 통신하는 것에만 관심있는 서비스를 처리할 때에, 서비스는 PeerChannelFactory 대신 PeerListenerFactory를 생성 및 오픈할 수 있다. 그 후 PeerChannel이 사용되어 PeerListenerFactory를 생성할 수 있다. 필터링 기준에 일치하는 PeerNode에 의해 첫번째 메시지가 수신되면, PeerListener는 PeerChannel을 만들어낼 수 있다. PeerChannel이 생성되면, 상기에 기술된 프로세스는 양방향 통신과 유사해질 수 있다. 그러나, PeerListener는 필터링 기준에 일치하는 메시지에 대한 애플리케이션에만 통지하도록 메시지 필터를 구성할 수도 있다.
애플리케이션이 메시지를 플러딩하기를 원하는 경우, 애플리케이션은 PeerChannel을 통해 PeerNode와 통신할 수 있다. 피어 채널은 애플리케이션에게 메시지가 이용가능할 때마다 통지할 수 있다. 대안적으로, 구현이 PeerListener를 사용하는 경우에, PeerListener는 PeerChannel을 생성하여 그에 대한 메시지가 수신되었음을 애플리케이션에게 통지할 수 있다. PeerChannel이 생성되면, 애플리케이션은 그것을 수신하여 프로세싱할 수 있다.
각 PeerNode는 단일 관련 NeighborManager를 가질 수 있다. NeighborManager는 전송 및 수신 역할에 있어 제한될 수 있고, 자신에게 향하는 메 시지들을 수집하고, PeerNode에 속하는 PeerChannel들로부터 메시지를 송신하기 위해 자신의 직접적인(immediate) 모든 이웃 노드의 리스트, 즉, 자신에게 직접 접속된 PeerNode들 모두의 리스트를 유지하는 책임이 있을 수 있다.
이웃 노드가 접속 요청을 수신( Neighbor Receives Connection Request )
도 9는 이웃 노드 접속을 처리하는 시나리오를 예시한다. 제1 노드가 제2 노드에의 접속을 개시하는 경우(단계(901)), 제2 노드의 NeighborManager는 통지받을 수 있고, 원격 제1 노드를 추적하기 위해 Neighbor 객체를 생성할 수 있다(단계(902)). NeighborManager는 제2 이웃 노드를 나타내는 PeerNode에게 통지할 수 있고(단계(903)), 차례로 Connector에게 통지한다. 제1 노드의 Connector는 CONNECT 메시지를 송신함으로써 제2 노드와 Connect 프로토콜을 시작한다. 그 후 응답 Connector는 개시 노드에 하기에 따라 응답을 송신할 수 있다.
이웃 노드의 현재 수가 최대값보다 크거나 같으면(하기의 메쉬 유지 섹션에 상술됨), 이웃 노드들 및/또는 기타 알려진 노드들의 짧은 리스트와 함께 REFUSE 메시지를 이웃 노드에 다시 송신할 수 있고(단계(905)), 채널이 클로징(closing)된다(단계(906)). 그렇지 않으면, 이웃 노드들 및/또는 알려진 노드들의 짧은 리스트와 함께 WELCOME 메시지를 송신할 수 있다(단계(907)).
상기 프로세스에 의해 채널이 클로징되지 않은 경우, 노드들은 각 노드에 광고된 서비스들을 포함할 수 있는 ADVERTISE 메시지를 교환할 수 있다(단계(908)).
노드 동기화( Synchronizing A Node )
이웃 노드가 메쉬 상의 또 다른 노드에 접속하는 경우, 메쉬의 현재 상태는 모든 노드들이 메쉬의 동일한 뷰를 공유할 것을 보장하기 위하여 동기화될 것을 필요로 할 수 있다. 이러한 상태는 메쉬 서명(이것은 내부적인 메쉬 유지 기능을 위해 사용되고, 하기에 기술됨)과 함께 메쉬 접촉 노드들의 리스트를 포함한다.
Peer Synchronizer는 한 쌍의 이웃 노드들 사이에 동기화 프로세스를 실행할 책임이 있는 PeerNode의 컴포넌트일 수 있다. 동기화 프로세스는 도 10에 예시된 다음 단계들을 포함할 수 있다. 블럭(1000)에서, 이웃 노드가 Connected 상태로 전환하면, 개시 Synchronizer는 SyncRequest 메시지를 송신함으로써 동기화 프로세스를 시작할 수 있다. SyncRequest 메시지는 Maintainer의 접촉 캐시의 접촉 및 서명의 추상화의 리스트를 포함할 수 있다. 각 접촉 추상화는 접촉 노드의 노드 ID, 및 접촉의 버전 번호를 포함할 수 있다. 새로운 노드에 대해, 이 리스트는 빈 리스트일 수 있다.
블럭(1005)에서, SyncRequest 메시지 수신 시, 응답 Synchronizer는 추상화의 리스트를 Maintainer에게 전달할 수 있다. Maintainer는 메쉬 유지 알고리즘을 구현할 수 있고, 메쉬 서명, 알려진 메쉬 노드들의 집합, 및 현재 메쉬 접촉들의 집합을 포함할 수 있다. 블럭(1010)에서, Maintainer는 추상화 리스트를 자신의 접촉 캐시의 컨텐츠들과 비교할 수 있다. 블럭(1015)에서, Maintainer는 자신의 캐시에 존재하지만 추상화 리스트에는 없는(즉, 개시 노드가 가지고 있지 않은) 접촉들의 리스트를 형성할 수 있고, 추상화 리스트에 있는 것들보다 새로운 접촉들을 추가한다. 블럭(1020)에서, 갱신된 추상화가 생성된다. 응답자의 캐시에 없는 임의의 접촉들이 추가되거나, 응답자가 더 오래된 버전을 가진 경우, Maintainer는 그들을 새로운 갱신된 추상화 리스트에 추가할 수 있다. 블럭(1025)에서, 접촉 리스트, 서명 및 새로운 추상화 리스트를 Synchronizer에게 반환할 수 있다.
블럭(1030)에서, Maintainer에 의해 반환된 추상화 리스트가 비어있지 않은 경우, 제어가 블럭(1035)으로 전달되어 응답 Synchronizer가 이 추상화 리스트 및 서명을 가진 자신의 SyncRequest 메시지를 송신한다. 블럭(1040)에서, Synchronizer는 접촉들과 함께 일련의 SyncData 메시지들을 송신할 수 있다. 최종 접촉 청크(chunk) 및 서명을 SyncEnd 메시지로 송신할 수 있다. 블럭(1030)에서 Maintainer에 의해 반환된 추상화 리스트가 비어있는 경우, Synchronizer는 자신의 SyncRequest를 송신할 수 없고, 제어는 블럭(1040)으로 전달될 수 있다.
블럭(1043)에서, 개시 측에서, 개시 측이 자신의 SyncRequest를 송신했는지에 대한 판정을 행할 수 있다. 개시자가 SyncRequest를 송신하지 않은 경우, 블럭(1045)에서 모든 SyncData 및 SyncEnd 메시지가 송신되면, 동기화 프로세스의 종료를 알릴 수 있다. 개시자가 자신의 SyncRequest를 송신한 경우, 블럭(1050)에서 SyncEnd 메시지가 수신되면, 동기화 프로세스를 종료할 수 있다.
블럭(1055)에서, 응답 측에서, 응답 측이 자신의 SyncRequest를 송신했는지에 대한 판정이 행해질 수 있다. 응답자가 SyncRequest를 송신하지 않은 경우, 블럭(1060)에서 모든 SyncData 및 SyncEnd 메시지가 송신되면, 동기화 프로세스의 종료를 알릴 수 있다. 응답자가 자신의 SyncRequest를 송신한 경우, 블럭(1065)에서 SyncEnd 메시지가 수신되면, 동기화 프로세스를 종료할 수 있다.
도 11은 한 쌍의 이웃 노드들 사이의 다양한 동기화 관련 메시지의 교환을 도시할 수 있으며, 여기서 개시자는 새로운 노드이다. 도 12는 메쉬에 있는 한 쌍의 기존의 노드들 사이의 동기화 프로세스를 예시할 수 있다. 도 13은 기존의 노드와 새로운 노드 사이의 동기화 프로세스를 예시할 수 있으며, 여기서 기존의 노드는 개시자이다.
메시지 송신/플러딩( Sending / Flooding A Message )
도 14는 메시지를 플러딩하는 시나리오를 예시한다. 애플리케이션이 메시지를 송신하기를 원하는 경우(단계(1401)), PeerChannel 메소드의 송신(SEND) 메소드를 호출할 수 있고(단계(1402)), PeerChannel은 PeerNode를 호출할 수 있으며(단계(1403)), PeerNode는 메시지를 송신하기 위하여 Flooder를 호출할 수 있다(단계(1404)). 내부 메시지의 ID가 Flooder의 메시지 테이블에 추가될 수 있고(단계(1405)), Flooder는 내부 메시지를 외부 터널링 메시지에 캡슐화하여(단계(1406)), 터널링 메시지로서 모든 이웃 노드들에게 메시지를 송신할 수 있다(단계(1407)). 외부 터널링 메시지는 내부 애플리케이션을 변경하지 않고서 이웃 채널들 상에서의 통신을 위해서만 사용될 수 있다. 단지 내부 피어 노드 컴포넌트들에 의한 처리 및 전달을 위해 내부 메시지의 무결성을 유지하기 위하여 터널링이 행해질 수 있지만, 이웃 채널들에 의한 처리를 위해서는 캡슐화 헤더 및 전달 메커니즘을 제공한다. 이것은 두 개의 경로 사이의 트랜스포트 메커니즘을 효율적으로 분리할 수 있다.
메시지 수신( Receiving a Message )
도 15는 메시지 수신 시나리오를 예시한다. PeerNode와 관련된 NeighborChannel에 메시지가 수신되면, NeighborManager는 PeerNode에게 알릴 수 있고(단계(1502)), 메시지의 타입에 따라 그 메시지를 프로세싱하도록 Flooder를 호출할 수 있다(단계(1503)).
플러딩된 모든 메시지들에 대해, 외부 터널링 메시지로부터 내부 메시지가 추출될 수 있다(단계(1504)). PeerNode는 Flooder를 호출하여 내부 메시지가 이전에 보여진 적이 있는지를 판정할 수 있다(단계(1505)). 이전에 보여진 적이 있는 경우, 메시지는 클로징될 수 있고, 프로세싱이 완료된다(단계(1506)). 내부 메시지가 메쉬를 통한 전달을 완료하지 못한 경우(즉, 메시지가 더 플러딩되어야 하는 경우), 프로세싱이 더 발생할 수 있다.
내부 메시지가 메쉬 기능을 프로세싱하기 위한 내부 메시지인 경우(단계(1507)), PeerNode는 메시지를 그것의 적합한 내부 노드 객체(예를 들어, Maintainer)에게 포워딩할 수 있다(단계(1508)). 이러한 컴포넌트들은 하기에 더욱 기술된 바와 같이 메시지를 프로세싱한다. 서명 메시지에 대해, Maintainer는 그 메시지가 더이상 플러딩을 중지해야 한다고 판정할 수 있고(단계(1509)), 그 시점에 메시지가 클로징되고 프로세싱이 완료될 수 있다(단계(1506)). 그렇지 않으면, 내부 메시지의 ID가 Flooder의 메시지 테이블에 추가될 수 있고(단계(1516)), 내부 메시지가 Flooder에 의해 또 다른 외부 터널링 메시지에 재-캡슐화하여(re-encapsulated) 본래의 메시지가 수신되었던 이웃 노드를 제외한 모든 이웃 노드들에 전송될 수 있다(단계(1517)).
내부 메시지가 애플리케이션 메시지인 경우(단계(1510)), PeerNode는 메시지 의 목적지 서비스에 관련된 채널 객체(예를 들어, PeerChannel 또는 PeerListener)를 검색할 수 있다(단계(1511)). 매칭하는 PeerChannel이 발견되는 경우, PeerChannel에 관련된 애플리케이션/서비스에 메시지를 송신할 수 있다(단계(1512)). 그렇지 않으면, 매칭하는 PeerListener가 발견되는 경우, AcceptChannel 또는 BeginAcceptChannel을 호출함으로써 애플리케이션/서비스에의 새로운 PeerChannel이 생성될 수 있고(단계(1513)), 대응하는 애플리케이션에 메시지를 송신할 수 있다.
내부 메시지가 애플리케이션 메시지가 아닌 경우(단계(1510)), 내부 메시지의 ID가 Flooder의 메시지 테이블에 추가될 수 있으며(단계(1516)), 내부 메시지가 Flooder에 의해 또 다른 외부 터널링 메시지에 재-캡슐화되어 본래의 메시지가 수신되었던 이웃 노드를 제외한 모든 이웃 노드들에게 전송될 수 있다(단계(1517)). 단계(1514, 1515)뿐 아니라 부가적인 플러딩 정리 로직(flood pruning logic)이 이 프로세스에 구현될 수 있다. 예를 들어, 메시지가 더 플러딩되어야 하는지를 판정하기 위하여 몇몇 애플리케이션이 Flooder에 관련된 전달 필터 인터페이스 객체(propagation filter interface object)(IPeerMessagePropagationFilter 인터페이스라고 불릴 수 있음)를 구현할 수 있다(단계(1514)). 더이상의 플러딩이 존재하지 않는다고 Flooding 필터 인터페이스가 판정하는 경우, 프로세싱이 완료된다(단계(1515)).
메쉬의 일부를 클로징하기( Closing a Portion of the Mesh )
다음은 메시지의 일부가 분해되거나 클로징될 수 있는 경우에 발생할 수 있 는 이벤트들이다.
Neighbor 개시된 접속단절(Neighbor Initiated Disconnect): 이웃 노드와의 접속이 완전히 단절되는 경우, 이웃 노드는 DISCONNECT 메시지를 송신할 수 있다. 이 메시지는 Connector에 의해 처리될 수 있으며, Connector는 이웃 채널을 클로징한다. 이웃 채널이 클로징되면(갑자기, 또는 공식적인 접속단절 프로세스를 통함), NeighborManager는 나머지 내부 노드 컴포넌트들에게 통지할 수 있다. Maintainer는 메쉬 유지 알고리즘(하기에 기술됨)을 수행함으로써 이 이벤트를 처리할 수 있다. PeerNode는 애플리케이션에게 원격 노드에 의해 광고된 서비스들이 더이상 이용가능하지 않음을 통지함으로써 이 이벤트를 처리할 수 있다. 이것이 유일한 이웃 노드 접속이었던 경우에, 노드는 이제 오프라인일 수 있다.
PeerNode 개시된 접속단절(PeerNode Initiated Disconnect): 피어 노드가 클로징되기 때문에 또는 Maintainer가 접속을 끊기로 결정했기 때문에, 이웃 노드가 국부적으로(예를 들어, PeerNode에 의해) 접속이 단절될 수 있다. 이웃 노드가 클로징되는 경우, 로컬 컴포넌트들이 통지받을 수 있다. Connector는 DISCONNECT 메시지를 이웃 노드에게 송신함으로써 이 이벤트를 처리할 수 있다. Neighbor가 클로징되면, 광고된 원격 노드의 서비스들이 더이상 이용가능하지 않음을 애플리케이션이 통지받을 수 있다.
PeerChannel 클로징하기(Closing a PeerChannel): 채널이 클로징되면, 채널은 소유하고 있는 팩토리의 채널 집합으로부터 삭제될 수 있고, 관련 PeerNode에의 참조가 해제된다.
서비스를 광고하기( Advertising a Service )
본 발명의 메쉬 시스템의 한 가지 장점은 애플리케이션이 메쉬를 사용하여 서비스를 찾아내도록 할 수 있고, 그 후 애플리케이션이 이것을 이용할 수 있다는 점이다. 메쉬 상의 다양한 노드들에 의해 제공된 서비스들에 액세스할 수 있게 하기 위하여, 애플리케이션은 먼저 자신의 이웃 노드에 관한 정보를 검색할 필요가 있을 수 있다. 특히, 애플리케이션은 이웃 노드들에게 광고된 서비스들을 열거할 필요가 있을 수 있다.
로컬 서비스를 이웃 노드들에게 광고하기 위하여, 애플리케이션은 로컬 애플리케이션 서비스의 EndpointAddress를 명시하는, PeerNode의 AddAdvertisedAddress 함수를 호출할 수 있다. 이것은 Maintainer가 이 서비스를 자신의 현재 광고된 리스트에 추가하고, 갱신된 광고된 리스트를 포함하는 ADVERTISE 메시지를 이웃 노드들에게 송신하도록 할 수 있다. 유사하게, 애플리케이션은 PeerNode의 RemoveAdvertisedAddresses 함수를 호출함으로써 서비스를 광고로부터 해제(un-advertise)할 수 있다.
애플리케이션이 자신의 서비스 주소를 광고하는 경우, 이러한 정보는 노드에 의해 캐싱되고 이웃 노드들에게 전송된다. 이러한 정보를 수신하면, 이벤트가 발생할 수 있다. 이 이벤트는 애플리케이션에게 이웃 노드의 노드 ID, 및 그 노드상에 광고된 모든 EndpointAddress들을 제공할 수 있다.
애플리케이션의 서비스의 주소를 광고함으로써, 애플리케이션은 이웃 노드의 애플리케이션 서비스에게 직접 채널을 오픈할 수 있고, 이에 의해 사적인 통신 채 널이 가능해진다. 메시지를 이웃 노드에 송신하기 위해 (메시지를 전체 메쉬에 송신하는 게 아니라), 애플리케이션은 이웃 노드상에 광고된 서비스들의 리스트를 검색하여, 그 메시지를 어떤 서비스에게 송신할지를 판정하도록 요구될 수 있다. 서비스들 중 이런 리스트를 찾기 위하여, 애플리케이션은 PeerNode의 함수를 호출하여 광고된 서비스들을 검색할 수 있고, 그 함수는 GetNeighborAdvertisedAddresses라고 불릴 수 있으며, 캐싱된 서비스 정보를 수집한다. 메소드는 이웃 노드의 노드 ID와 함께 EndpointAddress의 집합을 이웃 노드들의 광고된 서비스들에게 반환한다.
애플리케이션은 이러한 EndpointAddress들 중 하나를 선택할 수 있고, 기본적인 메시지 버스(예를 들어, http, tcp 등 - PeerChannel이 아님)의 채널을 사용하여 서비스에의 채널을 생성할 수 있다. 애플리케이션은 이 채널을 사용하여 이웃 노드의 서비스와 직접 통신(오프-메쉬:off-mesh)할 수 있다.
메쉬 유지( Mesh Maintenance )
도 16은 본 발명의 발명의 실시예의 메쉬 유지 프로세스를 도시한다. 메쉬 접속은 cIdealNeighbors, cMaxNeighbors, cMinNeighbors라고 불릴 수 있는 3개의 파라미터에 의해 결정될 수 있다. 노드는 접속된 이웃 노드들의 수에 대한 카운트를 유지할 수 있다(단계(1601)). 노드는 임의의 주어진 시각에 다른 노드들에의 cIdealneighbors 접속들을 대략적으로 유지하려고 할 수 있다. 노드는 현재 cMaxNeighbors를 가지는 경우(단계(1602)), 새로운 아웃고잉 접속을 설립하거나 새로운 인커밍 접속을 수락할 수 없을 수 있고, 자신에게 접속하려 시도하는 임의의 노드에게 REFUSE 메시지를 송신할 것이다(단계(1603)). 임의의 시각에 접속의 수가 cMinNeighbors 미만인 경우(단계(1604)), 노드는 더 많은 접속을 확립하려 할 수 있다. 노드는 계류중인 채널 요청을 환영(WELCOME)할 수 있고(단계(1605, 1606), 또는 노드는 자신의 이웃 노드들에 의해 자신에게 전달되었던(WELCOME, REFUSE 및 DISCONNECT 메시지를 통해서임) 알려진 노드들의 리스트를 사용할 수 있다. 이 리스트가 충분하지 않으면, 메쉬 ID를 새로운 노드로 결정을 시도할 수 있다(예를 들어, 하기에 기술된 바와 같이, 새로운 채널을 오픈함으로써).
cIdealNeighbors, cMaxNeighbors 및 cMinneighbors에 대한 값은 메쉬 크기 및 메쉬 트래픽을 포함하는 여러 요소에 의존할 수 있다. cMinNeighbors 값이 1인 경우는 단 하나의 접속이 끊어져도 완전히 분리되게 할 수 있기 때문에, cMinNeighbors의 값은 임의의 메쉬에 대해 적어도 2인 것이 적합할 수 있다. cMaxNeighbors 값이 크면 특정 노드가 다른 노드들을 대신하여 매우 과도한 양의 플러딩을 하고 있음을 의미할 수 있다. cMinNeighbors와 cMaxNeighbors 사이의 cIdealNeighbors 값은 최소의 오버헤드를 갖도록 적절한 중복성(good redundancy)에 기초할 수 있다.
메쉬의 각 노드는 가능하다면 접속들의 가장 유용한 세트를 유지하려 할 수 있고, 접속의 유용성은 (어느 방향으로든지) 자신에게 전송된 보여지지 않은 메시지의 양에 의해 결정될 수 있다. 주기적으로, 노드가 cIdealNeighbors보다 큰 값을 가지는 경우(단계(1608)), 노드는 가장 유용하지 않은 접속을 단절시킬 수 있다(단계(1609)).
각 노드는 64비트 난수(random 64-bit number)인 노드 ID를 가질 수 있다. 메쉬는 메쉬에 존재하는 최저 노드 ID로서 계산될 수 있는 서명을 갖는다. 계산은 최저 ID를 갖는 노드가 자신의 ID를 서명으로서 발행하도록 함으로써 행해질 수 있다. 그러나, 노드는 자신이 최저 ID를 가짐을 직접 알 수 없고, 따라서 모든 노드가 자신의 ID를 발행하려 할 수 있다. 메쉬 서명이 자신의 ID보다 이미 더 작으면 그 노드는 자신의 ID를 발행할 수 없다. 또한, 각 노드는 자신의 ID를 발행하기 전에 자신의 노드 ID에 비례하여 지수적으로 증가할 수 있는 백오프 기간(backoff period)을 가질 수 있는데, 이로써 올바르지 않은 서명 발행의 수를 감소시키게 된다.
메쉬는 접촉 노드들의 세트를 가질 수 있고, 접촉 노드들은 서명을 인식할 때 메쉬의 서명을 주기적으로 발행할 책임이 있을 수 있다. 메쉬 서명의 노드 뷰가 접촉 노드들이 발행하는 뷰와 맞지 않게 될 때마다(단계(1610)), 노드는 메쉬가 분할되었음을 알 수 있고, 임의의(random) 백오프 기간 후에 동기가 맞지 않는 접촉 노드들 중 하나에 재접속을 시도할 수 있다(단계(1611)). 이러한 절차(procedure)에는 분할을 검출할 수 없을 가능성이 조금 존재한다. 이를 경감시키기 위하여, 접촉 노드들은 주기적으로 메쉬 ID를 새로운 (무작위) 노드로 결정하여 접속을 형성하려 시도할 수 있다.
API
도 17은 본 발명에 따른 방법을 예시할 수 있다. 본 방법(1700)은 피어 네트워킹 프로토콜이 구현된, 피어 네트워킹 프로토콜을 통해 상호동작하는 컴퓨팅 장치들의 네트워크의 일부가 되도록 적응된 피어 네트워킹 가능케 된 컴퓨터에서 사용될 수 있다.
피어-투-피어 프로토콜의 성공은 선택된 개체(entities)들 사이에 유효한 접속을 구축하는 프로토콜의 기능(ability)에 의존할 수 있다. 마찬가지로, 그러한 피어-투-피어 네트워크의 그룹들의 형성은 이 기능에 의존한다. 그러나, 본 분야에서 숙련된 기술을 가진 자들은 후술되는 교시로부터 본 발명의 방법은 특정 피어-투-피어 프로토콜에 제한되지 않음을 인지할 것이다.
본 방법(1700)은 장치 서비스 세트를 구현하는 소프트웨어 프로그램에 대한 애플리케이션 프로그래밍 인터페이스에 구체화될 수 있다. 본 방법은 이전에 설명된 바와 같이 피어 리스너를 설정하는 피어 리스닝 팩토리(peer listening factory)의 일부, 및 피어 채널을 설정하는 피어 채널 팩토리(peer channel factory)의 일부일 수 있다. 블럭(1710)에서, 본 방법은 서비스의 최대 수를 피어 네트워크상의 다른 컴퓨팅 장치에 광고하라는 요청을 지원할 수 있다. 디폴트 값은 예를 들어 25일 수 있다. 서비스는 사용자를 위한 컴퓨터 경험 또는 컴퓨터 프로그램으로 여겨질 수 있다. 과도한 광고는 네트워크를 불필요하게 정체시킬 수 있기 때문에 그룹의 멤버들은 모든 컴퓨팅 장치로부터 이용가능한 서비스들 모두에 대해 알 필요가 없을 수 있다. 광고될 서비스들의 수는 임의적일 수 있고, 또는 제한된 네트워크 트래픽을 갖는 더 작은 그룹에서는 더 많은 서비스들이 광고될 수 있지만 더 많은 네트워크 트래픽을 갖는 더 큰 네트워크에서는 더 적은 서비스들이 광고될 수 있는 것과 같은 공식에 기초할 수 있다. 또한, 광고될 수 있는 서비스 들의 수가 설정될 수 있다. 그 수는 네트워크의 또 다른 멤버에 의해, 또는 네트워크의 관리 멤버에 의해 설정될 수 있다. 예시적인 컴퓨터 코드 구현은 다음과 같은 수 있다.
public int MaxAdvertisedAddressesPerNeighbor { get; set; }.
블럭(1720)에서, 메시지가 피어 네트워크상의 추가적인 컴퓨팅 장치에 전달되어야만 하는가 판정하라는 요청을 지원할 수 있다. 그 판정은 또한 어떤 메시지들이 네트워크상의 다른 컴퓨팅 장치들에 전달되어야 하는지에 관한 필터로서 여겨질 수 있다. 필터는 메시지가 이전에 수신되었던 것인지, 메시지가 수신측 컴퓨터가 알고 있는 의도된 수신자를 포함하는지, 네트워크 트래픽이 많은지, 메시지가 최근 메시지인지 오래된 메시지인지 등과 같이 여러 가지 설정을 가질 수 있다. 디폴트값은 모든 메시지들이 포워딩됨을 의미하는 '필터링되지 않음(no filter)'일 수 있다. 또한 필터를 설정할 수 있다. 예를 들어, 수신자에게 알려진 컴퓨터 장치가 오프라인이고, 그 알려진 컴퓨터 장치에 메시지가 수신되는 경우, 필터는 그 메시지를 포워딩하지 않도록 설정될 수 있다. 예시적인 컴퓨터 코드 구현은 다음과 같을 수 있다.
public IPeerMessagePropagationFilter MessagePropagationFilter { get; set; }
블럭(1730)에서, 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 포트 번호에 대한 요청에 서비스할 수 있다. 네트워크에 메시지들을 전달하기 위해 포트가 사용될 수 있고, 네트워크상의 상이한 컴퓨팅 장치들은 상이한 포트를 사용 할 수 있다. 블럭(1740)은 메시지를 송신 및/또는 수신하기 위해 컴퓨팅 장치가 사용하고 있는 포트를 네트워크 상의 다른 멤버들에게 제공할 수 있다. 디폴트는 기본적인 트랜스포트(즉, TCP, HTTP)가 포트를 선택하는 것일 수 있다. 또한, 네트워크와 통신하기 위해 사용된 컴퓨팅 장치의 포트가 설정될 수 있다. 포트는 네트워크의 또 다른 멤버에 의해, 또는 네트워크의 관리 멤버에 의해 설정될 수 있다. 예시적인 컴퓨터 코드 구현은 다음과 같을 수 있다.
public Nullable<int>NeighborServicePort { get; set; }
블럭(1740)에서, 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 트랜스포트 방법에 대한 요청에 서비스할 수 있다. HTTP 또는 TCP와 같은 다양한 트랜스포트 방법들이 이용가능할 수 있다. 또한, 컴퓨팅 장치의 트랜스포트 방법이 설정될 수 있다. 트랜스포트 방법은 네트워크의 또 다른 멤버에 의해, 또는 네트워크의 관리 멤버에 의해 설정될 수 있다. 예시적인 컴퓨터 코드 구현은 다음과 같을 수 있다.
public Transport NeighborServiceTransport { get; set; }
블럭(1750)에서, 어떤 리졸버(resolver)를 사용할지에 관련된 요청에 서비스할 수 있다. 특정 사용자가 상이한 주소들을 갖는 다양한 위치에서 다양한 방식으로 네트워크에 접속할 수 있기 때문에, 사용자 또는 그룹에게 고유 식별자가 할당될 수 있다. 그 후 이 주소는 식별자가 프로토콜을 통해 특정 어드레스 또는 어드레스들에 결합되도록 변환될 필요가 있을 수 있다. 그러한 하나의 피어-투-피어 이름 결정 프로토콜은 PNRP(Peer Name Resolution Protocol)이다. 예를 들어, resolver는 PNRP를 사용하여 네트워크 주소를 메쉬 id로 변환할 수 있다. 그러나, 본 분야에서 숙련된 기술을 가진 자들은 본 발명의 방법이 특정 피어-투-피어 프로토콜에 제한되지 않지만, 동일한 영향력으로 다른 프로토콜들에 적용될 수 있음을 인지할 것이다. 또한, 컴퓨팅 장치에 의해 사용된 resolver가 설정될 수 있다. resolver는 네트워크의 또 다른 멤버에 의해, 또는 네트워크의 관리 멤버에 의해 설정될 수 있다. 예시적인 컴퓨터 코드 구현이 다음과 같을 수 있다.
public IPeerResolver Resolver { get; set; }
상기 설명으로부터, 본 발명의 방법 및 시스템은 서비스 지향 애플리케이션 프레임워크를 사용하는 애플리케이션 개발자가 멀티캐스트 기능을 피어 노드 객체들을 사용하여 쉽고 편리하게 통합하는 것을 가능하게 할 수 있다. 이러한 프레임워크를 사용하면, 피어 노드 객체들은 이용가능한 어떤 프로토콜이든지 사용하여 메시지 전달을 관리하기 때문에, TCP/IP 또는 기타 기본적인 저레벨 통신 프로토콜에 대해 고려하지 않고 멀티캐스트 기능을 갖는 서비스들이 생성될 수 있다. 이 시스템의 장점은 전체 인터넷에 걸치는 메쉬가 생성될 수 있다는 점일 수 있지만, 멀티캐스트 IP가 동작하기 위해서는 인터넷의 특정 멀티캐스트 IP 가능케 된 세그먼트(예를 들어, "Mbone")를 필요로 한다. 본 발명의 시스템은 또한 필터 인터페이스를 사용하여 메시지의 흐름이 지능적으로 제어될 수 있는 애플리케이션 기반 필터링 메커니즘을 제공하며(예를 들어, 메시지 은폐가 메쉬를 더욱 효율적이고 안전하게 하는 데에 유용할 수 있음), IP 멀티캐스트 솔루션은 이것을 제공하지 않는다.
또한, 본 발명의 시스템은 서비스 지향 프레임워크의 상부에 형성되기 때문에, 애플리케이션 개발자들은 멀티캐스트 솔루션을 처음부터 프로그래밍할 걱정을 할 필요가 없으며, 단지 자신의 서비스의 일부로서 구현하고 싶은 멀티캐스트 기능에 대해서만 걱정하면 된다. 피어 노드 객체 모델은 개발자들이 멀티캐스트 가능케 된 서비스 개발에 전념할 수 있도록 기본 기반구조를 제공한다. 설명된 API 역시 프로그래밍을 쉽게 할 것이다.
전술한 설명은 여러 상이한 실시예에 대한 상세한 설명을 언급하지만, 본 발명의 범위는 본 문서의 끝 부분에 언급된 특허청구범위에 의해 정의됨을 이해하여야 한다. 상세한 설명은 단지 예시적인 것으로 해석되어야 하며, 가능한 모든 실시예를 기술하는 것은 불가능하지는 않지만 비실용적이므로, 가능한 모든 실시예를 기술하지는 않는다. 현재의 기술을 사용해서든지 본 발명의 출원일 이후에 개발된 기술을 사용해서든지, 여전히 본 발명의 특허청구범위에 속하는 다양한 대안적인 실시예들이 구현될 수 있다.
그러므로, 본 발명의 취지 및 범위로부터 벗어나지 않고서 본원에 기술되고 예시된 기술 및 구조에 여러 수정 및 변경이 행해질 수 있다. 따라서, 본원에 기술된 방법 및 장치는 단지 예시적인 것이며, 본 발명의 범위에 제한을 가하지 않음을 이해하여야 한다.
본 발명의 방법 및 시스템은 서비스 지향 프레임워크, 구체적으로는 서비스 지향 메시징 시스템 상부에 구현하기 위한 멀티캐스트 프로그래밍 모델을 지원하는 API 세트를 제공하는 효과가 있다.

Claims (20)

  1. 피어 네트워킹 프로토콜이 구현된, 피어 네트워킹 프로토콜을 통해 상호 동작하는 컴퓨팅 장치들의 네트워크의 일부가 되도록 적응된 피어 네트워킹 동작 가능 컴퓨터에서, 장치 서비스 세트를 구현하도록 소프트웨어 프로그램에 애플리케이션 프로그래밍 인터페이스를 제공하며,
    상기 피어 네트워크상의 다른 컴퓨팅 장치에 광고하는 서비스의 최대 수에 대한 요청을 지원하기,
    메시지가 상기 피어 네트워크상의 추가적인 컴퓨팅 장치에 전달되어야만 하는가 판정하라는 요청을 지원하기,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 포트 번호에 대한 요청을 지원하기,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 트랜스포트 방법에 대한 요청을 지원하기, 및
    어떤 리졸버(resolver)를 사용할지에 관련된 요청을 지원하기
    를 포함하는 애플리케이션 프로그래밍 인터페이스.
  2. 제1항에 있어서,
    상기 리졸버는 메쉬 id를 pnrp를 사용하여 네트워크 주소로 변환하는 애플리케이션 프로그래밍 인터페이스.
  3. 제1항에 있어서,
    상기 피어 네트워크상의 다른 컴퓨팅 장치에 광고하는 상기 서비스의 최대 수의 설정을 허용하는 더 포함하는 애플리케이션 프로그래밍 인터페이스.
  4. 제1항에 있어서,
    메시지가 상기 피어 네트워크상의 추가적인 컴퓨팅 장치에 전달되어야만 하는가를 판정하기 위해 필터의 설정을 허용하는 것을 더 포함하는 애플리케이션 프로그래밍 인터페이스.
  5. 제1항에 있어서,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 상기 포트 번호의 설정을 허용하는 것을 더 포함하는 애플리케이션 프로그래밍 인터페이스.
  6. 제1항에 있어서,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 상기 트랜스포트 방법의 설정을 허용하는 것을 더 포함하는 애플리케이션 프로그래밍 인터페이스.
  7. 제1항에 있어서,
    사용할 상기 리졸버의 설정을 허용하는 것을 더 포함하는 애플리케이션 프로그래밍 인터페이스.
  8. 피어 네트워킹 프로토콜이 구현된, 피어 네트워킹 프로토콜을 통해 상호 동작하는 컴퓨팅 장치들의 네트워크의 일부가 되도록 적응된 피어 네트워킹 동작 가능 컴퓨터에서 사용되기 위한 컴퓨터 실행가능 명령어들을 가진 컴퓨터 판독가능 매체로서, 장치 서비스 세트를 구현하도록 소프트웨어 프로그램에 애플리케이션 프로그래밍 인터페이스를 제공하며,
    상기 피어 네트워크상의 다른 컴퓨팅 장치에 광고하는 서비스의 최대 수에 대한 요청을 지원하는 컴퓨터 실행가능 명령어,
    메시지가 상기 피어 네트워크상의 추가적인 컴퓨팅 장치에 전달되어야만 하는가 판정하라는 요청을 지원하는 컴퓨터 실행가능 명령어,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 포트 번호에 대한 요청을 지원하는 컴퓨터 실행가능 명령어,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 트랜스포트 방법에 대한 요청을 지원하는 컴퓨터 실행가능 명령어, 및
    어떤 리졸버를 사용할지에 관련된 요청을 지원하는 컴퓨터 실행가능 명령어
    를 포함하는 컴퓨터 판독가능 매체.
  9. 제8항에 있어서,
    상기 리졸버는 메쉬 id를 pnrp를 사용하여 네트워크 주소로 변환하는 컴퓨터 판독가능 매체.
  10. 제8항에 있어서,
    상기 피어 네트워크상의 다른 컴퓨팅 장치에 광고하는 상기 서비스의 최대 수의 설정을 허용하는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  11. 제8항에 있어서,
    메시지가 상기 피어 네트워크상의 추가적인 컴퓨팅 장치에 전달되어야만 하는가를 판정하기 위해 필터의 설정을 허용하는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  12. 제8항에 있어서,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 상기 포트 번호의 설정을 허용하는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  13. 제8항에 있어서,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 상기 트랜스포트 방법의 설정을 허용하는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가 능 매체.
  14. 제8항에 있어서,
    사용할 상기 리졸버의 설정을 허용하는 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  15. 컴퓨팅 장치(apparatus)로서,
    비디오 이미지를 생성할 수 있는 디스플레이 유닛,
    입력 장치,
    상기 디스플레이 유닛과 상기 입력 장치에 동작가능하게 결합된 프로세싱 장치-상기 프로세싱 장치는 프로세서와 상기 프로세서에 동작가능하게 결합된 메모리를 포함함-,
    네트워크와 상기 프로세싱 장치에 접속된 네트워크 인터페이스를 포함하고,
    상기 프로세싱 장치는 피어 네트워킹 프로토콜이 구현된, 피어 네트워킹 프로토콜을 통해 상호동작하는 컴퓨팅 장치들의 네트워크의 일부가 되도록 적응된 피어 네트워킹 동작 가능 컴퓨터에서, 장치 서비스 세트를 구현하는 소프트웨어 프로그램에 애플리케이션 프로그래밍 인터페이스를 제공하도록 프로그램되어 있으며,
    상기 피어 네트워크상의 다른 컴퓨팅 장치에 광고하는 서비스의 최대 수에 대한 요청을 지원하기,
    메시지가 상기 피어 네트워크상의 추가적인 컴퓨팅 장치에 전달되어야만 하 는가 판정하라는 요청을 지원하기,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 포트 번호에 대한 요청을 지원하기,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 트랜스포트 방법에 대한 요청을 지원하기, 및
    어떤 리졸버를 사용할지에 관련된 요청을 지원하기-상기 리졸버는 메쉬 id를 pnrp를 사용하여 네트워크 주소로 변환함-
    를 포함하는 컴퓨팅 장치.
  16. 제15항에 있어서,
    상기 피어 네트워크상의 다른 컴퓨팅 장치에 광고하는 상기 서비스의 최대 수의 설정을 허용하도록 프로그램되어 있는 프로세싱 장치를 더 포함하는 컴퓨팅 장치.
  17. 제15항에 있어서,
    메시지가 상기 피어 네트워크상의 추가적인 컴퓨팅 장치에 전달되어야만 하는가를 판정하기 위해 필터의 설정을 허용하도록 프로그램되어 있는 프로세싱 장치를 더 포함하는 컴퓨팅 장치.
  18. 제15항에 있어서,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 상기 포트 번호의 설정을 허용하도록 프로그램되어 있는 프로세싱 장치를 더 포함하는 컴퓨팅 장치.
  19. 제15항에 있어서,
    상기 피어 네트워크상의 컴퓨팅 장치에 접촉하는데 사용되는 상기 트랜스포트 방법의 설정을 허용하도록 프로그램되어 있는 프로세싱 장치를 더 포함하는 컴퓨팅 장치.
  20. 제15항에 있어서,
    사용할 상기 리졸버의 설정을 허용하도록 프로그램되어 있는 프로세싱 장치를 더 포함하는 컴퓨팅 장치.
KR1020060024022A 2005-03-15 2006-03-15 피어-투-피어 애플리케이션을 형성하기 위한 애플리케이션프로그래밍 인터페이스 KR20060100273A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/080,897 2005-03-15
US11/080,897 US7493413B2 (en) 2005-03-15 2005-03-15 APIS to build peer to peer messaging applications

Publications (1)

Publication Number Publication Date
KR20060100273A true KR20060100273A (ko) 2006-09-20

Family

ID=36572086

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020060024022A KR20060100273A (ko) 2005-03-15 2006-03-15 피어-투-피어 애플리케이션을 형성하기 위한 애플리케이션프로그래밍 인터페이스

Country Status (7)

Country Link
US (1) US7493413B2 (ko)
EP (1) EP1703701B1 (ko)
JP (1) JP2006294009A (ko)
KR (1) KR20060100273A (ko)
CN (1) CN1893434A (ko)
AT (1) ATE424686T1 (ko)
DE (1) DE602006005408D1 (ko)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101388352B1 (ko) * 2009-05-29 2014-04-25 노키아 코포레이션 애드혹 메쉬 네트워크를 사용하여 서비스 또는 활동을 결합하는 방법 및 장치

Families Citing this family (53)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7562151B2 (en) * 2005-11-30 2009-07-14 Microsoft Corporation Peer tunnels and peer group targets
US20080013502A1 (en) * 2006-02-08 2008-01-17 Clark Alan R Wireless data bus
US20080111977A1 (en) * 2006-11-14 2008-05-15 Asml Holding N.V. Compensation techniques for fluid and magnetic bearings
US8688789B2 (en) 2009-01-30 2014-04-01 Voxer Ip Llc Progressive messaging apparatus and method capable of supporting near real-time communication
US9178916B2 (en) 2007-06-28 2015-11-03 Voxer Ip Llc Real-time messaging method and apparatus
US20110019662A1 (en) 2007-06-28 2011-01-27 Rebelvox Llc Method for downloading and using a communication application through a web browser
US8533611B2 (en) * 2009-08-10 2013-09-10 Voxer Ip Llc Browser enabled communication device for conducting conversations in either a real-time mode, a time-shifted mode, and with the ability to seamlessly shift the conversation between the two modes
US8825772B2 (en) 2007-06-28 2014-09-02 Voxer Ip Llc System and method for operating a server for real-time communication of time-based media
US8180029B2 (en) 2007-06-28 2012-05-15 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8645477B2 (en) 2009-01-30 2014-02-04 Voxer Ip Llc Progressive messaging apparatus and method capable of supporting near real-time communication
US20100198988A1 (en) 2009-01-30 2010-08-05 Rebelvox Llc Methods for using the addressing, protocols and the infrastructure of email to support near real-time communication
US20090277226A1 (en) * 2007-10-16 2009-11-12 Santangelo Salvatore R Modular melter
US8145780B2 (en) 2007-10-19 2012-03-27 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US7751362B2 (en) 2007-10-19 2010-07-06 Rebelvox Llc Graceful degradation for voice communication services over wired and wireless networks
US8699678B2 (en) 2007-10-19 2014-04-15 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8001261B2 (en) 2007-10-19 2011-08-16 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8233598B2 (en) * 2007-10-19 2012-07-31 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8782274B2 (en) 2007-10-19 2014-07-15 Voxer Ip Llc Method and system for progressively transmitting a voice message from sender to recipients across a distributed services communication network
US8391312B2 (en) 2007-10-19 2013-03-05 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8559319B2 (en) 2007-10-19 2013-10-15 Voxer Ip Llc Method and system for real-time synchronization across a distributed services communication network
US8090867B2 (en) 2007-10-19 2012-01-03 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8321581B2 (en) 2007-10-19 2012-11-27 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US7751361B2 (en) * 2007-10-19 2010-07-06 Rebelvox Llc Graceful degradation for voice communication services over wired and wireless networks
US8111713B2 (en) 2007-10-19 2012-02-07 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8682336B2 (en) 2007-10-19 2014-03-25 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8699383B2 (en) 2007-10-19 2014-04-15 Voxer Ip Llc Method and apparatus for real-time synchronization of voice communications
US8380874B2 (en) 2007-10-19 2013-02-19 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8099512B2 (en) 2007-10-19 2012-01-17 Voxer Ip Llc Method and system for real-time synchronization across a distributed services communication network
US8250181B2 (en) 2007-10-19 2012-08-21 Voxer Ip Llc Method and apparatus for near real-time synchronization of voice communications
US8706907B2 (en) 2007-10-19 2014-04-22 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
EP2243254B1 (en) * 2007-12-21 2018-07-18 Intel Corporation Peer-to-peer streaming and api services for plural applications
US8542804B2 (en) 2008-02-08 2013-09-24 Voxer Ip Llc Voice and text mail application for communication devices
US8321582B2 (en) 2008-02-08 2012-11-27 Voxer Ip Llc Communication application for conducting conversations including multiple media types in either a real-time mode or a time-shifted mode
US9054912B2 (en) 2008-02-08 2015-06-09 Voxer Ip Llc Communication application for conducting conversations including multiple media types in either a real-time mode or a time-shifted mode
US8401582B2 (en) 2008-04-11 2013-03-19 Voxer Ip Llc Time-shifting for push to talk voice communication systems
US8325662B2 (en) 2008-09-17 2012-12-04 Voxer Ip Llc Apparatus and method for enabling communication when network connectivity is reduced or lost during a conversation and for resuming the conversation when connectivity improves
US8270950B2 (en) * 2008-12-05 2012-09-18 Voxer Ip Llc Mobile communication device, method, and system for reducing exposure to radio frequency energy during transmissions by transmitting media in/out while the mobile communication device is safe distance away from user
US8849927B2 (en) 2009-01-30 2014-09-30 Voxer Ip Llc Method for implementing real-time voice messaging on a server node
US8498230B2 (en) 2009-03-03 2013-07-30 Nokia Corporation Power management in wireless communication systems
US20100226309A1 (en) 2009-03-03 2010-09-09 Nokia Corporation Beaconing mode for wireless communication
US8694578B2 (en) * 2009-05-29 2014-04-08 Microsoft Corporation Swarm-based synchronization over a network of object stores
US8565139B2 (en) * 2009-10-29 2013-10-22 Symbol Technologies, Inc. Methods and apparatus for WAN/WLAN unicast and multicast communication
US8774021B2 (en) 2009-12-10 2014-07-08 Nokia Corporation Data-related task support in wireless communication systems
US8842605B2 (en) 2009-12-10 2014-09-23 Nokia Corporation Network discovery in wireless communication systems
US20110145837A1 (en) * 2009-12-14 2011-06-16 Bower Kenneth S Filtering Broadcast Recipients In A Multiprocessing Environment
US9306813B2 (en) * 2009-12-23 2016-04-05 Apple Inc. Efficient service advertisement and discovery in a peer-to-peer networking environment with cooperative advertisement
US8804589B2 (en) 2011-10-14 2014-08-12 Nokia Corporation Adaptive awake window
US9042828B2 (en) 2012-11-26 2015-05-26 Nokia Corporation Method, apparatus, and computer program product for optimized discovery between mobile devices
US10033773B2 (en) * 2012-12-10 2018-07-24 Samsung Electronics Co., Ltd. Application execution method and apparatus
US10521280B2 (en) * 2017-12-29 2019-12-31 Futurewei Technologies, Inc. Event-driven serverless function orchestration
US10565034B2 (en) * 2017-12-29 2020-02-18 Futurewei Technologies, Inc. Event-driven serverless function orchestration
CN109510868B (zh) * 2018-11-14 2021-01-22 广州虎牙信息科技有限公司 一种建立p2p网络的方法、装置、终端设备及存储介质
CN114503105A (zh) * 2019-09-25 2022-05-13 联邦科学和工业研究组织 用于浏览器应用的密码服务

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7139838B1 (en) * 1999-10-21 2006-11-21 Nortel Networks Limited Apparatus and method of distributing routing information
US7171475B2 (en) * 2000-12-01 2007-01-30 Microsoft Corporation Peer networking host framework and hosting API
AU2002234258A1 (en) * 2001-01-22 2002-07-30 Sun Microsystems, Inc. Peer-to-peer network computing platform
US7493363B2 (en) * 2001-09-19 2009-02-17 Microsoft Corporation Peer-to-peer group management and method for maintaining peer-to-peer graphs
US7430747B2 (en) * 2002-12-04 2008-09-30 Microsoft Corporation Peer-to peer graphing interfaces and methods
US7533141B2 (en) * 2003-01-24 2009-05-12 Sun Microsystems, Inc. System and method for unique naming of resources in networked environments
US7596625B2 (en) * 2003-01-27 2009-09-29 Microsoft Corporation Peer-to-peer grouping interfaces and methods
US7437440B2 (en) * 2003-01-27 2008-10-14 Microsoft Corporation Peer-to-peer networking framework application programming interfaces
US7774495B2 (en) * 2003-02-13 2010-08-10 Oracle America, Inc, Infrastructure for accessing a peer-to-peer network environment
US7533184B2 (en) * 2003-06-13 2009-05-12 Microsoft Corporation Peer-to-peer name resolution wire protocol and message format data structure for use therein
US20050193106A1 (en) * 2004-03-01 2005-09-01 University Of Florida Service discovery and delivery for ad-hoc networks

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101388352B1 (ko) * 2009-05-29 2014-04-25 노키아 코포레이션 애드혹 메쉬 네트워크를 사용하여 서비스 또는 활동을 결합하는 방법 및 장치

Also Published As

Publication number Publication date
US20060212592A1 (en) 2006-09-21
CN1893434A (zh) 2007-01-10
DE602006005408D1 (de) 2009-04-16
EP1703701A1 (en) 2006-09-20
ATE424686T1 (de) 2009-03-15
US7493413B2 (en) 2009-02-17
JP2006294009A (ja) 2006-10-26
EP1703701B1 (en) 2009-03-04

Similar Documents

Publication Publication Date Title
KR20060100273A (ko) 피어-투-피어 애플리케이션을 형성하기 위한 애플리케이션프로그래밍 인터페이스
US7912959B2 (en) Architecture for building a peer to peer messaging platform
US7543023B2 (en) Service support framework for peer to peer applications
US8732236B2 (en) Managing network communications between network nodes and stream transport protocol
EP1625726B1 (en) Universal plug-and-play (upnp) mirroring device
US7155487B2 (en) Method, system and article of manufacture for data distribution over a network
EP2027687B1 (en) Bridging between ad hoc local networks and internet-based peer-to-peer networks
KR101278861B1 (ko) 다수의 노드들이 대화형 세션에 참여하는 시스템 및 그에관련된 장치-판독 가능 매체
Musolesi et al. Emma: Epidemic messaging middleware for ad hoc networks
US20070133520A1 (en) Dynamically adapting peer groups
EP2232390B1 (fr) Procédé d&#39;acheminement de messages sur un réseau et système de mise en oeuvre du procédé
KR20050004079A (ko) 인스턴트 메시징을 위한 트랜스포트 시스템
KR20080109045A (ko) 리모트 액세스
FR2930100A1 (fr) Procede d&#39;etablissement d&#39;un chemin de communication dans un reseau etendu de communication, tetes de tunnel,produit programme d&#39;ordinateur et moyen de stockage correspondants
CN1917512B (zh) 一种建立对等直连通道的方法
CN104468604A (zh) 局域网中基于对等网络通信模式的数据访问方法及装置
JP2010062677A (ja) メッセージを転送する装置、出力方法および出力プログラム
Moritz et al. Devices profile for web services in wireless sensor networks: Adaptations and enhancements
CN105493465A (zh) 网络环境中的用于云计算的基于XMPP的UPnP设备架构
Chae et al. Fast discovery scheme using DHT-like overlay network for a large-scale DDS
Klauck Seamless integration of smart objects into the internet using XMPP and mDNS/DNS-SD
Sir et al. Discovery and synchronization of thing descriptions in a distributed architecture
CN109379443A (zh) 一种面向物联网的分布式消息队列的实现方法
JP5723011B2 (ja) ＵＰｎＰテレフォニーを用いるメモ共有方法及び装置
Ishikawa et al. Peer-to-peer networking platform and its applications for mobile phones

Legal Events

Date Code Title Description
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid