KR20080005507A - 커뮤니티 중계 노드 발견을 위한 장치 방법 및 컴퓨터판독가능 매체 - Google Patents

커뮤니티 중계 노드 발견을 위한 장치 방법 및 컴퓨터판독가능 매체 Download PDF

Info

Publication number
KR20080005507A
KR20080005507A KR1020077024170A KR20077024170A KR20080005507A KR 20080005507 A KR20080005507 A KR 20080005507A KR 1020077024170 A KR1020077024170 A KR 1020077024170A KR 20077024170 A KR20077024170 A KR 20077024170A KR 20080005507 A KR20080005507 A KR 20080005507A
Authority
KR
South Korea
Prior art keywords
name
community relay
relay node
community
pnrp
Prior art date
Application number
KR1020077024170A
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 KR20080005507A publication Critical patent/KR20080005507A/ko

Links

Images

Classifications

    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4541—Directories for service discovery

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)

Abstract

커뮤니티 중계 노드가 접근 보호된 클라이언트에 동작적으로 연결되고 접근 보호된 클라이언트와 요청 클라이언트 사이의 통신을 돕기에 적합하게 구성되는 네트워크 커뮤니티 내의 커뮤니티 중계 노드를 발견하는 방법은, 요청 클라이언트로부터 커뮤니티 중계 노드를 위한 요청에 관한 요청 메시지를 수신하고, 요청 메시지를 무서버 네임 분석 프로토콜 네임과 연결시키며, 무서버 네임 분석 프로토콜 네임에 기반하여 커뮤니티 중계 노드들의 목록 중에서 커뮤니티 중계 노드를 선택 - 커뮤니티 중계 노드들의 목록은 커뮤니티 중계 노드와 연결된 적어도 하나의 인터넷 프로토콜 주소를 포함함 - 하고, 선택된 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 요청 클라이언트에게 반환하는 단계를 포함한다.
커뮤니티, 중계, 클라이언트, 네임, 분석, 방화벽

Description

커뮤니티 중계 노드 발견을 위한 장치 방법 및 컴퓨터 판독가능 매체{APPARATUS AND METHOD FOR COMMUNITY RELAY NODE DISCOVERY}
본 발명은 커뮤니티 중계 노드 발견을 위한 장치 및 방법에 관한 것이다.
네트워크 통신 기술은 공통의 관심사를 갖는 사용자들이 공동 작업하고, 파일들을 공유하며, 서로 대화하고, 프레젠테이션 및 그룹 미팅을 위한 오디오 및 비디오를 멀티캐스트하며, 멀티플레이어 게임에 참여할 수 있게 한다. 대부분의 네트워크 통신 및 형성은 서버 중심적 환경 또는 피어-투-피어 환경에서 일어난다. 서버 중심적 환경에서는 모든 통신은 개인들이 그룹에 가입하여 참여하도록 연결될 수 있는 거대한 중앙 서버로 흐르거나 또는 그 서버를 통해 흐른다. 피어-투-피어 기술은 사용자들이 무서버 환경(serverless environment)에서 서로 접촉하게 한다. 그러나, 많은 경우에, 클라이언트는 방화벽(예를 들어, 퍼스널, 네트워크 또는 기업) 뒤에서 접근 보호되어 있으며, 그 것은 착신 접속들을 시작할 때 문제를 일으킨다. 단지 한 클라이언트가 접근 보호되어 있으면 방화벽들을 더 쉽게 운행될 수 있을지라도, 두 개의 접근 보호된 클라이언트들 사이의 방화벽 운행(traversal)은 관리자의 제어 하에서도 어렵다. 그러나, 이 문제는 수퍼노드라고도 지칭되는 커뮤니티 중계 노드들을 이용하여 해결될 수 있다.
커뮤니티 중계 노드는 접근 보호되어 있지 않은 컴퓨터 또는 서버일 수 있고, 송신 클라이언트로부터의 착신 통신들을 쉽게 수락할 수 있으며, 수신 클라이언트로의 통신을 경로설정할 수 있다. 그럼으로써, 커뮤니티 중계 노드는 두 개의 접근 보호된 클라이언트들 사이의 통신을 중계할 수 있다. 커뮤니티 중계 노드는 접근 보호된 클라이언트들 사이의 통신을 중계하기에 충분한 자원(예를 들어, 서비스 품질)을 갖는 어떤 컴퓨터 또는 서버일 수 있다. 다른 클라이언트와 통신하기를 원하는 어떤 클라이언트는 커뮤니티 중계 노드에게 그 통신을 도와줄 것을 요청할 수 있다. 그러나, 요청 클라이언트가 어떤 컴퓨터/서버들이 커뮤니티 중계 노드들인지 항상 아는 것은 아니다. 알려진 커뮤니티 중계 노드들이 이용불가능하게 되기도 할 것이고, 요청 클라이언트가 그것을 모를 수도 있다. 그렇듯이, 요청 클라이언트는 커뮤니티 중계 노드를 발견하는 문제에 직면할 수 있다. 또한, 요청 클라이언트에 의해 요구된 커뮤니티 중계 노드가 요청되고 있는 통신 프로토콜 유형(예를 들어, SSL(secure sockets layer), 사용자 데이터그램 프로토콜 등)에 종속할 수도 있고, 그럼으로써 적합한 커뮤니티 중계 노드를 발견함에 있어서의 어려움을 가중시킨다.
네트워크 커뮤니티 내의 커뮤니티 중계 노드를 발견하는 방법이 개시되며, 이 커뮤니티 중계 노드는 접근 보호된 클라이언트에 동작적으로 연결되어 있으며 접근 보호된 클라이언트와 요청 클라이언트 사이의 통신을 돕기에 적합하게 되어 있다. 이 방법은 커뮤니티 중계 노드를 위한 요청에 관하여 요청 클라이언트로부터 요청 메시지를 수신하고, 요청 메시지를 무서버 네임 분석 프로토콜 네임과 연결시키며, 무서버 네임 분석 프로토콜 네임에 기반하여 커뮤니티 중계 노드들의 목록 중에서 커뮤니티 중계 노드를 선택하고-커뮤니티 중계 노드들의 목록은 커뮤니티 중계 노드와 연결된 적어도 하나의 인터넷 프로토콜 주소를 포함함-, 선택된 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 요청 클라이언트에게 반환하는 단계를 포함할 수 있다.
커뮤니티 중계 노드와 요청 클라이언트 사이의 통신을 부트스트랩 하는 방법의 단계들을 처리하기 위한 컴퓨터 실행가능 명령어를 갖는 컴퓨터 판독가능 매체가 개시된다. 컴퓨터 판독가능 매체는 요청 클라이언트로부터 도메인 네임을 수신하고, 도메인 네임을 피어 네임과 연결시키며, 피어 네임을 하나 이상의 인터넷 프로토콜 주소로 분석 - 각각의 인터넷 프로토콜 주소는 커뮤니티 중계기에 관한 것임 - 하고, 하나 이상의 분석된 인터넷 프로토콜 주소들로부터 커뮤니티 중계 노드를 선택하며, 선택된 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 요청 클라이언트에게 반환하기 위한 컴퓨터 실행가능 명령어를 포함할 수 있다.
컴퓨터 시스템이 개시된다. 컴퓨터 시스템은 처리 장치, 처리 장치에 동작적으로 연결된 도메인 네임 시스템 네트워크 인터페이스, 도메인 네임 시스템 네트워크 인터페이스 및 처리 장치에 동작적으로 연결된 피어 네임 분석 프로토콜 네트워크 인터페이스를 포함할 수 있다. 도메인 네임 시스템 네트워크 인터페이스는 네트워크에 동작적으로 연결될 수 있고, 피어 네임 분석 프로토콜 네트워크 인터페이스는 커뮤니티 중계기에 동작적으로 연결될 수 있다. 컴퓨터 시스템은 피어 네임 분석 프로토콜 네트워크 인터페이스에 동작적으로 결합된 제1 및 제2 캐시를 더 포함할 수 있다. 제1 캐시는 제1 피어 네임 분석 프로토콜 네임과 열결될 수 있고 제1의 다수의 커뮤니티 중계 노드들의 인터넷 프로토콜 주소들을 저장하기에 적합하다. 제2 캐시는 제2 피어 네임 분석 프로토콜 네임과 결합될 수 있고 제2의 다수의 커뮤니티 중계 노드들의 인터넷 프로토콜 주소들을 저장하기에 적합하다. 처리 장치는 프로세서 및 프로세서에 동작적으로 연결된 메모리를 포함할 수 있다. 처리 장치는 커뮤니티 중계 노드를 위한 요청에 관하여 클라이언트로부터 요청 메시지를 수신하고, 제1 피어 네임 분석 프로토콜 네임 또는 제2 피어 네임 분석 프로토콜 네임에 대한 요청 메시지를 분석하며, 요청 메시지가 제1 피어 네임 분석 프로토콜 네임으로 분석되면 제1 캐시로부터 커뮤니티 중계 노드를 선택하고, 요청 메시지가 제2 피어 네임 분석 프로토콜 네임으로 분석되면 제2 캐시로부터 커뮤니티 중계 노드를 선택하며, 선택된 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 클라이언트에게 송신하도록 프로그램될 수 있다.
도 1은 청구항들에 따라 동작할 수 있는 컴퓨팅 시스템의 블록 다이어그램.
도 2는 청구항들에 따른 네트워크 시스템의 블록 다이어그램.
도 3은 청구항들에 따른 네트워크 시스템 내에서 클라이언트와 커뮤니티 중계 노드 사이의 통신을 부트스트랩 하기 위한 컴퓨팅 시스템의 블록 다이어그램.
도 4는 청구항들에 따라 클라이언트와 커뮤니티 중계 노드 사이의 통신을 부트스트랩 하는 방법의 플로우차트.
도 5는 청구항들에 따라 커뮤니티 중계 노드를 위한 클라이언트로부터의 요청을 분석하는 방법의 플로우차트.
도 6A-6F는 청구항들에 따른 커뮤니티 중계 노드들의 관리를 예시하는 블록 다이어그램들.
도 7은 청구항들에 따른 커뮤니티 중계 노드들의 목록을 업데이트하고 관리하는 방법의 플로우차트.
아래의 텍스트가 많은 상이한 실시예들에 관해 상세한 설명을 할지라도, 이 설명의 법적 범위는 이 특허의 끝에 설명된 특허청구의 범위의 문언에 의해 정의되는 것임을 이해해야 한다. 이 상세한 설명은 예시적인 것으로만 해석되어야 하며, 모든 가능한 실시예를 설명하는 것은 불가피한 것이 아니라면 실용적이지 못하므로 모든 가능한 실시예를 설명하지는 않는다. 현재의 기술이든 이 특허의 출원일 후에 개발된 기술이든 사용해서, 여전히 특허청구의 범위 내에 드는 많은 대안적 실시예들이 구현될 수 있다.
또한, 어떤 용어가 "여기에서 사용되는 용어 ' '은 이로써 ...을 의미하는 것으로 정의된다"라는 문장 또는 유사한 문장을 사용하여 이 특허에서 명백하게 정의되지 않는 한, 그 평범한 또는 통상적인 의미를 넘어서 그 용어의 의미를 명시적으로든 암시적으로든 제한할 것을 의도하지 않으며, 그러한 용어가 이 특허의 어떤 섹션에서 이루어진 어떤 선언(특허청구의 범위의 문언이 아닌)에 기반한 범위로 제한해서 해석되지 않아야 함을 이해해야 한다. 이 특허의 끝에 있는 특허청구의 범 위에 언급된 어떤 용어가 이 특허에서 독자를 혼동시키지 않도록 명백하게 하기 위한 목적만으로 이루어진 단일의 의미와 일치하는 방식으로 언급되기까지, 그러한 특허청구범위의 용어가 암시적으로는 다른 어떤 것으로든 그 단일의 의미로 제한되어야 함을 의도하지 않는다. 마지막으로, 특허청구범위 구성요소가 어떤 구조를 상술함이 없이 기능 및 “수단”이라는 단어를 언급하여 정의되지 않는 한, 어떤 특허청구범위의 구성요소든 35 U.S.C. § 112, 제6 단락의 적용에 기반하여 해석될 것을 의도하지 않는다.
도 1은 특허청구범위에 기재된 방법 및 장치의 단계들을 위한 시스템이 구현되기에 적합한 컴퓨팅 시스템 환경(100)의 예를 도시하고 있다. 컴퓨팅 시스템 환경(100)은 적합한 컴퓨팅 환경의 단지 한 예일 뿐이며 특허청구범위의 방법 및 장치의 사용 범위 또는 기능에 관해 어떠한 제한을 제안하고자 하는 것이 아니다. 컴퓨팅 환경(100)이 예시적 운영 환경(100)에서 도시된 임의의 하나의 컴포넌트 또는 컴포넌트들의 조합에 관해 임의의 종속성 또는 요구사항을 가지는 것으로 해석되어서는 안 된다.
특허청구범위에 기재된 방법 및 장치의 단계들은 많은 기타 범용 또는 특수 목적의 컴퓨팅 시스템 환경 또는 구성에서 동작할 수 있다. 잘 알려진 컴퓨팅 시스템, 환경 및/또는 특허청구범위의 방법 또는 장치와 함께 이용하기에 적합할 수 있는 구성의 예로는 퍼스널 컴퓨터, 서버 컴퓨터, 핸드-헬드 또는 랩톱 장치, 멀티프로세서 시스템, 마이크로프로세서 기반 시스템, 셋톱 박스, 프로그램 가능한 가전제품, 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기 시스템이나 장치 등의 임의의 것을 포함하는 분산 컴퓨팅 환경 등이 있지만 이에 제한되는 것은 아니다.
특허청구범위에 기재된 방법 및 장치의 단계들은 컴퓨터에 의해 실행되는 프로그램 모듈 등과 같은 컴퓨터 실행가능 명령어의 일반적인 문맥으로 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하고 또는 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 객체, 컴포넌트, 데이터 구조 등을 포함한다. 이 방법 및 장치는 통신 네트워크를 통해 링크된 원격 처리 장치들에 의해 태스크가 수행되는 분산 컴퓨팅 환경에서 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈은 메모리 저장 장치를 포함하는 로컬 및 원격 컴퓨터 저장 매체 둘 다에 위치할 수 있다.
도 1과 관련하여, 특허청구범위에 기재된 방법 및 장치의 단계들을 구현하는 예시적인 시스템은 컴퓨터(110)의 형태인 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트는 처리 장치(120), 시스템 메모리(130) 및 시스템 메모리를 포함하는 각종 시스템 컴포넌트를 처리 장치(120)에 결합하는 시스템 버스(121)를 포함하지만 이에 제한되는 것은 아니다. 시스템 버스(121)는 메모리 버스 또는 메모리 컨트롤러, 주변 버스 및 각종 버스 아키텍처 중 임의의 것을 이용하는 로컬 버스를 포함하는 몇몇 유형의 버스 구조 중 어느 것이라도 될 수 있다. 예로서, 이러한 아키텍처는 ISA(industry standard architecture) 버스, MCA(micro channel architecture) 버스, EISA(Enhanced ISA) 버스, VESA(video electronics standard association) 로컬 버스 그리고 메자닌 버스 (Mezzanine bus)라고도 알려진 PCI(peripheral component interconnect) 버스 등을 포함하지만 이에 제한되는 것 은 아니다.
컴퓨터(110)는 통상적으로 각종 컴퓨터 판독가능 매체를 포함한다. 컴퓨터(110)에 의해 액세스 가능한 매체는 그 어떤 것이든지 컴퓨터가 판독가능 매체가 될 수 있고 이러한 컴퓨터 판독가능 매체는 휘발성 및 비휘발성 매체, 이동식 및 비이동식 매체를 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함하지만 이에 제한되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터와 같은 정보의 저장을 위해 모든 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 이동식 및 비이동식 매체를 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래시 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광 디스크 저장 장치, 자기 카세트, 자기 테이프, 자기 디스크 저장 장치 또는 기타 자기 저장 장치, 또는 컴퓨터(110)에 의해 액세스되고 원하는 정보를 저장할 수 있는 임의의 기타 매체를 포함하지만 이에 제한되는 것은 아니다. 통신 매체는 통상적으로 반송파(carrier wave) 또는 기타 전송 메커니즘(transport mechanism)과 같은 피변조 데이터 신호(modulated data signal)에 컴퓨터 판독가능 명령어, 데이터 구조, 프로그램 모듈 또는 기타 데이터 등을 구현하고 모든 정보 전달 매체를 포함한다. "피변조 데이터 신호"라는 용어는, 신호내에 정보가 인코딩되도록 그 신호의 하나 이상의 특성을 설정 또는 변경시킨 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 배선 접속과 같은 유선 매체, 그리고 음향, RF, 적외선, 기타 무선 매체와 같은 무선 매체를 포함한다. 상술된 매체들의 모든 조합이 또한 컴퓨 터 판독가능 매체의 영역 안에 포함되어야 한다.
시스템 메모리(130)는 판독 전용 메모리(ROM)(131) 및 랜덤 액세스 메모리(RAM)(132)와 같은 휘발성 및/또는 비휘발성 메모리 형태의 컴퓨터 저장 매체를 포함한다. 시동시 컴퓨터(110) 내의 구성요소들 사이의 정보 전송을 돕는 기본 루틴을 포함하는 기본 입/출력 시스템(BIOS)(133)은 통상적으로 ROM(131)에 저장되어 있다. RAM(132)은 통상적으로 처리 장치(120)에 즉시 액세스 가능하고 및/또는 현재 처리 장치(120)에 의해 동작되고 있는 데이터 및/또는 프로그램 모듈을 포함한다. 예로서, 도 1은 운영 체제(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136) 및 프로그램 데이터(137)를 도시하고 있지만 이에 제한되는 것은 아니다.
컴퓨터(110)는 또한 기타 이동식/비이동식, 휘발성/비휘발성 컴퓨터 저장 매체를 포함한다. 단지 예로서, 도 1은 비이동식, 비휘발성 자기 매체로의 기록 또는 그로부터의 판독을 위한 하드 디스크 드라이브(141), 이동식, 비휘발성 자기 디스크(152)로의 기록 또는 그로부터의 판독을 위한 자기 디스크 드라이브(151), CD-ROM 또는 기타 광 매체 등의 이동식, 비휘발성 광 디스크(156)로의 기록 또는 그로부터의 판독을 위한 광 디스크 드라이브(155)를 포함한다. 예시적인 운영 환경에서 사용될 수 있는 기타 이동식/비이동식, 휘발성/비휘발성 컴퓨터 기억 매체로는 자기 테이프 카세트, 플래시 메모리 카드, DVD, 디지털 비디오 테이프, 고상(solid state) 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)에 다른 번호가 주어졌다는 것은 적어도 이들이 서로 다른 사본(copy)이라는 것을 도시한다. 사용자는 키보드(162) 및 마우스, 트랙볼(trackball) 또는 터치패드라고 흔히 지칭되는 포인팅 장치(161) 등의 입력 장치를 통해 명령 및 정보를 컴퓨터(110)에 입력할 수 있다. 다른 입력 장치(도시 생략)로는 마이크, 조이스틱, 게임패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 및 기타 입력 장치는 흔히 시스템 버스에 결합된 사용자 입력 인터페이스(160)를 통해 처리 장치(120)에 접속되지만, 병렬 포트, 게임 포트 또는 USB(universal serial bus) 등의 다른 인터페이스 및 버스 구조에 의해 접속될 수도 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치도 비디오 인터페이 스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속될 수 있다. 모니터 외에, 컴퓨터는 스피커(197) 및 프린터(196) 등의 기타 주변 출력 장치를 포함할 수 있고, 이들은 출력 주변장치 인터페이스(195)를 통해 접속될 수 있다.
컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 사용하여 네트워크화된 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어 장치 또는 다른 보편적인 네트워크 노드일 수 있으며, 도 1에는 메모리 저장 장치(181)만 예시되어 있을지라도, 통상적으로 컴퓨터(110)와 관련하여 상술된 구성요소의 대부분 또는 그 전부를 포함한다. 도 1에 도시된 논리적 연결로는 LAN(171) 및 WAN(173)이 있지만, 다른 네트워크를 포함할 수도 있다. 이러한 네트워킹 환경은 사무실, 전사적 컴퓨터 네트워크, 인트라넷 및 인터넷에서 보편적인 것이다.
LAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워킹 환경에서 사용될 때, 컴퓨터(110)는 통상적으로 인터넷과 같은 WAN(173) 상에서의 통신을 설정하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메커니즘을 통해 시스템 버스(121)에 접속된다. 네트워크화된 환경에서, 컴퓨터(110) 또는 그의 일부와 관련하여 기술된 프로그램 모듈은 원격 메모리 저장 장치에 저장될 수 있다. 그 예로서, 도 1은 메모리 장치(181)에 상주하는 원격 애플리케이션 프로그램(185)을 도시하고 있지만 이에 제한되는 것은 아니다. 도시된 네트워크 접속은 예시적인 것이 며 이 컴퓨터들 사이의 통신 링크를 설정하는 다른 수단이 사용될 수 있다는 것을 이해할 것이다.
도 2는 네트워킹 시스템(200)의 한 예의 도시이다. 도 2를 보면, 네트워킹 시스템(200)은 프로모터(210), 프로모터(210)에 동작적으로 연결된 제1 클라이언트(220) 및 프로모터(210)에 동작적으로 연결되고 수퍼노드라고도 지칭되는 커뮤니티 중계 노드(240)를 포함할 수 있다. 네트워킹 시스템(200)은 커뮤니티 중계 노드(240)에 동작적으로 연결된 제2 클라이언트(230)를 포함하기도 한다. 각각의 클라이언트(220, 230)는 네트워크 방화벽 또는 퍼스널 방화벽 등과 같은 보안 시스템 뒤에서 접근 보호될 수 있다. 커뮤니티 중계 노드(240)는 제1 및 제2 클라이언트(220, 230)들 사이의 통신을 돕고 경로설정하기 위해 사용될 수 있다. 아래에서 더 설명하듯이, 제1 클라이언트(220)는 프로모터(210)의 도움에 의해 커뮤니티 중계 노드(240)에 결국 동작적으로 연결될 수 있다.
제1 및 제2 클라이언트(220, 230), 커뮤니티 중계 노드(240) 및 프로모터(210)는 상이한 지리적 위치에 제공되어 네트워크에 의해 서로 동작적으로 연결될 수 있다. 예를 들어, 제1 클라이언트(220)는 인터넷에 의해 프로모터(210)에 동작적으로 연결될 수 있고, IPv4 또는 IPv6와 같은 인터넷 통신 프로토콜에 의해 프로모터(210)와 통신할 수 있다. 유사한 방식으로, 제2 클라이언트(230)는 인터넷에 의해 커뮤니티 중계 노드(240)와 동작적으로 연결될 수 있고, 인터넷 통신 프로토콜에 의해 통신할 수 있다. 프로모터(210)는 또한 피어-투-피어 네트워크에 의해 커뮤니티 중계기(240)에 동작적으로 연결될 수 있고, 피어 네임 분석 프로토 콜(peer name resolution protocol)(PNRP)과 같은 무서버 분석 프로토콜(serverless resolution protocol)에 의해 통신할 수 있다. 피어 네임 분석 프로토콜의 예들이 2001. 8. 29자 출원된 미국 특허 공보 제2002/0143989호 및 2003. 6. 13자 출원된 미국 특허 공보 제2005/0004916호에 개시되어 있으며, 그 내용들은 여기에 참고로 명백하게 합체되어 있다.
프로모터(210)는 서버 컴퓨터 또는 다중 서버 컴퓨터들일 수 있고, 도메인 네임 요청들을 중계 및/또는 분석하는 도메인 네임 서비스의 부분으로서 사용될 수 있다. 아래에서 더 설명하듯이, 프로모터(210)는 또한 쿼리 커뮤니티 중계 노드(240)들에 대한 피어 네임 분석 및 클라이언트(220)와 커뮤니티 중계 노드(240) 사이의 부트스트랩 통신을 위해 사용될 수 있다. 예를 들어, 프로모터(210)는 다양한 클라이언트들로부터 도메인 네임 서비스 요청들을 계속 수신할 수 있다. 프로모터(210)는 도메인 네임 서비스 요청을 분석하고 요청에 대한 응답으로 인터넷 프로토콜(IP) 주소를 반환할 수 있다.
커뮤니티 중계 노드(240)는 선택적이거나 아니면 자발적일 수 있는 커뮤니티 중계 노드로서의 퍼스널 컴퓨터, 서버 컴퓨터 또는 컴퓨터들의 그룹일 수 있다. 한 예에서는, 커뮤니티 중계 노드(240)가 클라이언트 또는 클라이언트들의 그룹일 수 있다. 일반적으로, 커뮤니티 중계 노드(240)는 충분한 속도, 대역폭 등과 같은 신뢰할 만한 품질의 서비스(QOS)를 제공하고, SSL(secure sockets layer) 프로토콜 또는 사용자 데이터그램 프로토콜(UDP) 등과 같은 특수한 통신 프로토콜을 제공할 수 있다. 커뮤니티 중계 노드(240)는 접근 보호된 클라이언트(예를 들어, 방화벽 을 가진 클라이언트)들이 역시 접근 보호되어 있을 수 있는 다른 클라이언트들과 통신하는 것을 보조하기 위해 사용될 수 있다. 예를 들어, 클라이언트(220, 230)들은 착신 접속들을 방지하는 방화벽에 의해 각각 접근 보호될 수 있다. 커뮤니티 노드(240)는 일반적으로 방화벽에 의해 접근 보호되지 않으며, 그러므로 클라이언트로부터의 착신 접속들을 수신할 수 있다. 커뮤니티 중계 노드(240)는 클라이언트(220, 230)들이 방화벽을 통한 커뮤니티 중계 노드(240)로부터의 착신 접속들을 수락하도록 클라이언트(220, 230)들에 대해서는 인증되어 있을 수 있다. 인증은 제3자 인증에 의해 또는 커뮤니티 중계 노드(240)와 클라이언트 사이의 직접 인증에 의해 이루어질 수 있다. 클라이언트(220)는 커뮤니티 중계 노드(240)에게 다른 한 클라이언트(230)와 통신하는 것을 보조하도록 요청할 수 있다. 두 개의 클라이언트(220, 230)들 사이의 접속을 이루면, 커뮤니티 중계 노드(240)는 이어서 제1 및 제2 클라이언트(220, 230) 사이의 통신을 중계할 수 있다. 커뮤니티 중계 노드가 방화벽에 의해 접근 보호되어 있지 않기 때문에, 커뮤니티 중계 노드(240)는 송신 클라이언트로부터의 착신 통신들을 쉽게 수락할 수 있고, 커뮤니티 중계 노드(240)가 인증되어 있기 때문에, 그 것은 그 통신을 수신 클라이언트로 쉽게 경로설정(route) 할 수 있다. 단지 하나의 커뮤니티 중계 노드가 클라이언트(220, 230)들 사이의 통신들을 경로설정하기 위해 사용될 수 있을지라도, 다중 커뮤니티 중계 노드들 사이의 통신들이 경로설정될 수도 있음을 이해해야 한다. 커뮤니티 중계 노드는 여러 상이한 클라이언트들 사이의 여러 상이한 통신들을 중계할 수 있음을 이해해야 한다.
네트워킹 시스템(200)이 하나의 프로모터(210)와 하나의 커뮤니티 중계 노드(240) 및 두 개의 클라이언트(220, 230)들을 포함하는 것으로 도시되어 있을지라도, 다양한 개수의 프로모터와 커뮤니티 중계 노드 및 클라이언트들이 이용될 수 있음을 이해해야 한다. 예를 들어, 클라이언트(220, 230)들은 각각 더 큰 클라이언트 네트워크 또는 그룹의 부분일 수 있다. 네트워킹 시스템(200)은 또한 프로모터(210)에 동작적으로 연결된 다수의 커뮤니티 중계 노드(240)들을 포함할 수 있으며, 각각의 커뮤니티 중계 노드(240)는 클라이언트들 사이의 통신을 돕고 경로설정하기 위해 많은 상이한 클라이언트들에 동작적으로 연결될 수 있다. 어떤 커뮤니티 중계 노드들은 SSL 또는 UDP와 같은 특수한 통신 프로토콜들에 대해 사용될 수 있다.
도 3은 프로모터(210)의 예의 블록 다이어그램이다. 일반적으로, 프로모터는 하이퍼텍스트 전송 프로토콜(HTTP) 통신 채널들과 같은 인터넷 기반 통신을 위한 도메인 네임 서비스(DNS) 전단(300) 및 피어-투-피어 기반 통신을 위한 무서버 분석 프로토콜(예를 들어, PNRP) 후단(310)을 포함한다. 한 예에서는, 프로모터(210)의 DNS 전단(300)이 커뮤니티 중계 노드를 위한 요청이 아니라 도메인 네임 분석 요청들을 분석하기 위한 표준 DNS 서비스의 부분으로서 작용할 수 있다. DNS 전단은 클라이언트로부터 커뮤니티 중계 노드를 위한 도메인 네임 분석 요청들을 수신하고 요청 클라이언트에 대해 커뮤니티 중계 노드의 인터넷 프로토콜(IP) 주소(그리고, 필요하다면, 포트 번호)를 반환하기 위해 HTTP에 의해 클라이언트들과 통신할 수 있다. PNRP 후단(310)은 커뮤니티 중계 노드들의 PNRP 분석 쿼리들을 처리하고 쿼리에 대한 응답으로 커뮤니티 중계 노드들에 관한 정보를 저장할 수 있다. PNRP 후단(310)은 DNS 전단으로부터의 커뮤니티 중계 노드를 위한 요청들을 더 분석하고 DNS 전단(300)에 대해 커뮤니티 중계 노드의 IP 주소를 반환할 수 있다. 단일 블록으로 도시되어 있을지라도, 프로모터(210)는 위에서 지적한 바와 같이 다중 연결된 컴퓨터들을 포함할 수 있다.
도 3에 도시된 바와 같이, DNS 전단(300)은 DNS 네트워크 인터페이스(320) 및 DNS 인터페이스(320)에 동작적으로 연결된 DNS 플러그인(330)을 포함한다. DNS 인터페이스(320)는 인터넷에 동작적으로 연결될 수 있으며, 커뮤니티 중계 노드를 위한 DNS 네임 분석 요청들을 포함해서 클라이언트(220)와 HTTP 통신을 할 수 있다. DNS 인터페이스(320)는 클라이언트(220)로부터의 도메인 네임 분석 요청을 쿼리 네임과 쿼리 유형으로 파싱(parsing)하기 위한 DNS 디코더를 포함할 수 있다. 쿼리 네임은 프로모터(210)를 식별하기 위해 사용되는 DNS 네임에 관한 것일 수 있으며, 쿼리 유형은 클라이언트(220)(예를 들어, SSL, UDP)에 의해 요청된 통신 프로토콜 유형에 관한 것일 수 있다. DNS 인터페이스(320)는 요청에 대한 응답으로 커뮤니티 중계 노드의 IP 주소를 갖는 클라이언트(220)에게 응답하기 위한 DNS 인코더를 더 포함할 수 있다. DNS 인터페이스는 미리 구성된 맵에 의해 커뮤니티 중계 노드를 위한 요청의 DNS 네임을 관련 PNRP 네임과 매칭함으로써 DNS 네임 분석 요청을 더 분석할 수 있다. 대안적으로, 디코더는 아래에서 더 설명하듯이 DNS 네임 내에 암호화된 PNRP 네임을 분석하기 위해 DNS 네임을 해독하기 위해 이용될 수 있다.
DNS 플러그인(330)은 커뮤니티 중계 노드를 위한 요청을 PNRP 후단(310)으로 전달하고 커뮤니티 중계 노드를 위한 요청이 아닌 요청들과 같은 지원되지 않는 요청 및 지원되지 않는 쿼리 유형을 위한 요청들에 대한 오류를 반환하기 위해 PNRP 후단(310)에 동작적으로 연결될 수 있다. DNS 플러그인(330)은 커뮤니티 중계 노드를 위한 클라이언트의 요청에 응답하기 위해 PNRP 후단에 의해 분석된 커뮤니티 중계 노드들의 IP 주소들을 DNS 인터페이스(320)에 반환할 수 있다. DNS 플러그인(330)은 프로모터(210)의 계층들을 초기화하거나 초기화 취소하기 위해 사용될 수도 있다. 계층들의 초기화를 위한 샘플 컴퓨터 코드 구현은 아래와 같을 수 있다.
DWORD WINAPI DnsPluginInitialize(
PLUGIN_ALLOCATOR_FUNCTION pDnsALLOCATFunction,
PLUGIN_FREE_FUNCTION pDnsFreeFunction)
계층들의 초기화 취소를 위한 샘플 컴퓨터 코드 구현은 아래와 같을 수 있다.
DWORD WINAPI DnsPluginCleanup()
PNRP 후단(310)은 PNRP 매니저(340) 및 PNRP 매니저(340)에 동작적으로 연결된 PNRP 네트워크 인터페이스(350)를 포함할 수 있다. PNRP 매니저(340)는 DNS 전단(300)에 의해 분석된 커뮤니티 중계 노드를 위한 분석 요청에 관한 PNRP 네임을 수신하기 위해 DNS 플러그인(330)에 동작적으로 연결될 수 있다. PNRP 매니저는 DNS 전단(300)으로부터의 PNRP 분석 요청들을 관리하고, 커뮤니티 중계 노드들의 PNRP 네임을 분석하며, 커뮤니티 중계 노드들를 위한 요청에 대한 응답으로 커뮤니티 중계 노드들의 IP 주소를 반환할 수 있다. PNRP 인터페이스(350)는 여러 커뮤니티 중계 노드들에 대해 동작적으로 연결될 수 있고, 커뮤니티 중계 노드들에 대해 PNRP 분석 쿼리를 송신하고 커뮤니티 중계 노드들로부터 응답을 수신하는 것을 포함해서 커뮤니티 중계 노드들과 피어-투-피어 통신을 할 수 있다. PNRP 인터페이스(350)은 PNRP 분석 쿼리 동안에 프로모터(210) 상의 PNRP 서비스에 대한 원격 프로시저 호출(remote procedure calls)(RPC)을 처리하는 PNRP 응용 프로그램 인터페이스로서 제공될 수 있다. 그러나, 다른 한 예에서는, PNRP 인터페이스(350)의 성능이 프로모터(210)로부터의 PNRP 서비스를 제거하여 RPC 프로세스를 배제하기 위한 PNRP 데이터 링크 계층(DLL)을 이용하여 개선될 수 있다.
여러 캐시(360,370,380,390)들이 PNRP 매니저(340)에 동작적으로 연결될 수 있다. 캐시는 다양한 캐시 부분들로 분할된 단일의 메모리 또는 데이터베이스로서 제공되거나 또는 각각 PNRP 매니저에 동작적으로 연결된 다양한 메모리 또는 데이터베이스들로 제공될 수 있다. 캐시는 분석 캐시(360,370), 요청 캐시(380) 및 PNRP 캐시(390)를 포함할 수 있다.
분석 캐시(360,370)는 요청 클라이언트에게 이용가능한 앞서 분석된 커뮤니티 중계 노드 상의 정보를 대기시켜 저장하기 위해 제공될 수 있다. 이용가능한 SSL 커뮤니티 중계 노드들의 목록은 한 캐시(360)에서 관리되고 이용가능한 UDP 커뮤니티 중계 노드들의 목록은 다른 한 캐시(370) 에서 관리되는 방식으로 다양한 통신 프로토콜 유형에 대해 별도의 캐시(360,370)들이 제공될 수 있다. 분석 캐 시(360,370)들은 캐시에 저장된 각각의 커뮤니티 중계 노드의 서비스 품질, 부하, 위치, IP 주소 및 PNRP 네임에 관한 정보를 각각 포함할 수 있다. DNS 플러그인으로부터의 요청를 위한 응답으로, PNRP 매니저(340)는 적절한 분석 캐시(360,370)로부터 하나 이상의 커뮤니티 중계 노드들을 선택하고 요청 클라이언트에 대한 순차적인 응답을 위해 DNS 플러그인(330)에 대해 커뮤니티 중계 노드의 IP 주소를 반환할 수 있다. 아래에서 더 설명하듯이, PNRP 매니저(340)는 커뮤니티 중계 노드를 선택함에 있어서, 서비스 품질, 요청 클라이언트에 대한 근접성 및 부하 균형과 같은 다양한 인자들을 고려할 수 있다.
요청 캐시(380)는 DNS 플러그인(330)으로부터 수신되는 커뮤니티 중계 노드들을 위한 요청을 대기시키기 위해 제공될 수 있다. 요청들은 요청되는 통신 프로토콜 유형에 따라 요청 캐시(380)에 저장될 수 있다. PNRP 매니저(340)는 DNS 플러그인(330)으로부터 수신된 요청들을 요청 캐시(380)에 저장하고 요청들이 대기된 순서대로 요청들에 대해 응답할 수 있다.
PNRP 캐시(390)는 앞서 분석된 커뮤니티 중계 노드들의 PNRP 네임들을 포함해서 알려진 커뮤니티 중계 노드들의 목록을 관리하기 위해 제공될 수 있다. 각각의 PNRP 네임은 하나 이상의 커뮤니티 중계 노드에 대응할 수 있다. 예를 들어, 모든 알려진 SSL 커뮤니티 중계 노드들은 PNRP 네임에 대응할 수 있는 반면에, 모든 알려진 UDP 커뮤니티 중계 노드들은 다른 한 PNRP 네임에 대응할 수 있다. PNRP 캐시(390)는 통신 프로토콜 유형에 따라 알려진 커뮤니티 중계 노드들의 별도의 목록들을 관리할 수 있다. 예를 들어, 알려진 SSL 커뮤니티 중계 노드들은 하 나의 목록으로 제공되어 대응하는 PNRP 네임과 결합될 수 있는 반면에, 알려진 UDP 커뮤니티 중계 노드들은 다른 한 목록으로 제공되어 대응하는 PNRP 네임과 결합될 수 있다. 동일한 PNRP 네임들이 분석 캐시(360,370)들에 저장된 이용가능한 커뮤니티 중계 노드들의 목록들에 대응하도록 사용될 수도 있다. 그럼으로써 PNRP 매니저(340)가 DNS 전단(300)로부터의 요청에 응답할 때 적절한 분석 캐시(360,370)를 식별하기 위해 PNRP 네임들을 사용할 수 있다. 커뮤니티 중계 노드들은 자신들이 알려지도록 자신들을 프로모터(210)에 등록하고 등록해지할 수 있으며, 그 결과들이 PNRP 캐시(390)에서 관리될 수 있다. 커뮤니티 중계 노드들은 대응하는 PNRP 네임(예를 들어, SSL 또는 UDP)에 의해 등록할 수 있으며, 프로모터(210)에게 그 IP 주소, 통신 유형 및 서비스 품질을 알릴 수 있다. PNRP 매니저(340)는 또한 아래에서 더 설명하듯이 분석 캐시(360,370)들을 관리하는 부분으로서 커뮤니티 중계 노드들의 PNRP 쿼리들을 처리하기 위해 PNRP 네임을 이용할 수 있다.
도 4는 클라이언트(220)와 커뮤니티 중계 노드(240) 사이의 통신을 부트스트랩 하는 방법(400)의 한 예의 플로우차트이다. 클라이언트(210)가 접근 보호된 클라이언트(220)와 통신하기를 원하지만, 클라이언트(220, 230)들 사이의 통신을 경로설정하기 위한 커뮤니티 중계 노드(240)를 모를 때, 프로모터(210)는 클라이언트(220)와 커뮤니티 중계 노드(240) 사이의 통신을 부트스트랩 하고 그 자신을 프로세스로부터 제거하는 방법(400)을 이용할 수 있다. 프로모터(210)는 클라이언트(210)로부터 커뮤니티 중계 노드를 위한 요청을 수신하고 클라이언트(220)에게 커뮤니티 중계 노드(240)의 IP 주소를 반환할 수 있다. 커뮤니티 중계 노드(240) 의 IP 주소를 수신할 때, 클라이언트(220)는 HTTP에 의해 커뮤니티 중계 노드와 통신하고, 그에 따라 접근 보호된 클라이언트(230)와 통신할 수 있다.
도 4를 보면, 프로모터(210)의 DNS 인터페이스(320)는 블록 405에서 요청 클라이언트(220)로부터 요청 메시지를 수신하여 판독할 수 있다. 프로모터(210)는 클라이언트(220)의 사용자에게 알려진 공지된 DNS 네임과 연결될 수 있다. 클라이언트(220)는 커뮤니티 중계 노드를 위한 요청과 관련해서 프로모터(210)에 의해 인정될 요청 메시지를 구성할 수 있다. 표준 도메인 네임 서비스에서처럼, 클라이언트 요청은 프로모터(210)에 도달하기 전에 여러 상이한 DNS 서버들을 통해 경로설정될 수 있다. 프로모터(210)의 DNS 네임 및 커뮤니티 중계 노드를 위한 요청은 아래의 포맷에 기반할 수 있다.
xxxxxxxx.tunnel.version.suffix
여기에서,
suffix = 프로모터(210)를 정의하기 위해 구성가능한 파라미터
(예를 들어, promoter.microsoft.com);
version = 클라이언트의 버전을 나타내며 네임의 나머지(예를 들어, v1)를 이해하기 위해 프로모터(210)가 사용하는 상수,
tunnel = 터널 유형 요청(예를 들어, SSL, UDP), 그리고
xxxxxxxx = 표준 도메인 네임 서비스 캐싱(caching)을 방지하기 위한 무작위 문자숫자 접두어.
프로모터(210)를 위한 DNS 네임의 예들은 아래의 것을 포함할 수 있다.
wfnoaycl.udp.v1.promoter.microsoft.com
krgdjfto.ssl.v1.promoter.microsoft.com
위에서 지적했듯이, 프로모터(210)는 표준 도메인 네임 서비스를 위한 네임 서버의 기능을 할 수 있고 캐시된 결과의 데이터베이스를 관리할 수 있다. 그래서, DNS 인터페이스(320)는 표준 DNS 요청들을 수신하고 그 데이터베이스에 캐시된 결과를 반환할 수 있다. 블록 405에서 DNS 네임을 판독할 때, DNS 인터페이스(320)는 DNS 네임을 위한 결과들이 캐시되었는지 여부를 판단하기 위해 표준 도메인 네임 서비스에 따라 블록 410에서 그 데이터베이스를 검사할 수 있다. 그렇다면, DNS 인터페이스는 표준 DNS 분석에 따라 캐시된 결과를 반환할 수 있다. 그러나, 접두어(wfnoaycl 또는 krgdjfto)가 무작위적으로 발생되기 때문에, DNS 네임은 독특하고 DNS 인터페이스(320)의 데이터베이스에서 발견되지 않을 것이며, 그럼으로써 표준 DNS 서비스를 바이패스하여 도메인 네임 서비스가 요청 클라이언트(220)에게 결과를 시기상조로 반환하는 것을 방지한다. 블록(405)에서 판독되는 접미어(promoter.microsoft.com)가 수신자가 프로모터(210)에 있음을 나타내기 때문에, DNS 인터페이스(320)는 DNS 네임을 파싱하고 결과를 DNS 플러그인(330)에 전달한다. 유사한 방식으로, DNS 네임의 구조는 다른 DNS 서버들이 요청 클라이언트(220)에게 시기상조로 응답하는 것을 방지하지만, DNS 네임을 프로모터(210)로 경로설정한다. 또한, DNS 네임의 유지시간(time-to-live)(TTL)은 DNS 네임의 캐싱을 회피하기 위해 제로로 설정될 수 있다.
블록(415)에서, DNS 인터페이스(320)의 디코더는 DNS 네임을 쿼리 네임과 쿼 리 유형으로 파싱할 수 있다. 쿼리 네임은 오리지널 DNS 네임(예를 들어, ssl.v1.promoter.microsoft.com 또는 udp.v1.promoter.microsoft.com)에 관한 것일 수 있고 쿼리 유형은 터널 유형(예를 들어, SSL 또는 UDP)에 관한 것일 수 있다. 접두어는 일반적으로 무시될 수 있다. 쿼리 네임 및 쿼리 유형은 이어서 DNS 플러그인(330)으로 전달될 수 있다.
블록(420)에서, DNS 인터페이스(320)는 요청된 프로토콜 유형을 판독할 수 있다. 프로토콜 유형에 기반하여, DNS 인터페이스(320)는 커뮤니티 중계 노드들의 관련 목록의 PNRP 네임을 검색하기 위해 블록 425에서 관련 PNRP 네임으로 DNS 네임을 분석하거나 아니면 결합할 수 있다. 커뮤니티 중계 노드들의 PNRP 네임은 아래의 포맷에 기반할 수 있다.
0.QOS.tunnel.version.suffix
여기에서,
suffix = 커뮤니티 중계 노드들의 목록(예를 들어, promoter.microsoft.com)을 정의하기 위해 구성가능한 파라미터,
version = 커뮤니티 중계 노드의 버전을 나타내며 클라이언트 버전과 커뮤니티 중계 노드 버전(예를 들어, v1)을 매칭시키기 위해 프로모터(210)가 사용하는 상수
tunnel = 요청된 터널 유형(예를 들어, SSL, UDP), 그리고
QOS = 커뮤니티 중계 노드의 서비스 품질
(예를 들어, 0-높음; 1-중간; 2-낮음).
커뮤니티 중계 노드들의 목록을 위한 PNRP 네임들의 예들은 아래의 것을 포함할 수 있다.
0.udp.v1.promoter.microsoft.com
0.ssl.v1.promoter.microsoft.com
커뮤니티 중계 노드들의 관련 목록에 대한 DNS 네임의 매핑은 PNRP 네임을 DNS 네임의 접미어와 비교함으로써 처리될 수 있다. 예를 들어, DNS 네임의 접미어가 "udp.v1.promoter.microsoft.com"이면, DNS 인터페이스는 DNS 네임을 UDP 캐시(370)에서 관리되는 UDP 커뮤니티 중계 노드들의 목록에 대응하는 "0.udp.v1.promoter.microsoft.com"이라는 PNRP 네임과 연결시킬 것이다. 접미어가 "ssl.v1.promoter.microsoft.com"이면, DNS 네임은 SSL 커뮤니티 중계 노드들의 SSL 캐시(360)에 관리되는 SSL 커뮤니티 중계 노드들의 목록에 대응하는 “0.ssl.v1.promoter.microsoft.com"이라는 PNRP 네임과 연결될 것이다. 한 예에서는, DNS 인터페이스(320)가 DNS 네임들과 PNRP 네임들의 맵들을 관리할 수 있다. DNS 네임이 맵에 있으면, DNS 인터페이스는 DNS 네임의 접미어를 PNRP 네임과 비교함으로써 대응하는 PNRP 네임을 검색할 것이다. 아니면, 요청이 폐기될 것이다. 대안적으로, PNRP 네임은 DNS 네임 내에서 암호화될 수 있으며, 그 것은 해독되어 PNRP 매니저(340)로 전달될 수 있다. DNS 네임의 PNRP 네임들을 암호화하는 예는 대리인 사건 번호 30835/193621로 2005. 4. 22자 출원되었고, 여기에 참고로 명백하게 포함된, 발명의 명칭이 “DNS 호환가능한 PNRP 피어 네임 암호화(DNS Compatible PNRP Peer Name Encoding)”인 미국 특허 출원에 기술되어 있다.
블록(430)에서, DNS 플러그인(330)은 쿼리 네임 및 쿼리 유형에 기반하여 DNS 네임이 유효한지 여부를 판단할 수 있다. 쿼리 유형이 지원되지 않으면(즉, 쿼리 유형이 UDP 또는 SSL에 관한 것이 아니면), DNS 플러그인(330)은 블록(435)에서 요청을 폐기시키면서 DNS 인터페이스(320)에게 오류를 반환할 수 있다. 쿼리 유형이 지원되면, DNS 플러그인(330)은 블록(440)에서 PNRP 네임을 PNRP 매니저(340)에 전달할 수 있다. PNRP 후단(310)은 커뮤니티 중계 노드를 선택하고 커뮤니티 중계 노드의 IP 주소를 DNS 전단(300)에게 반환하기 위해 분석기 루틴(445)을 처리할 수 있다. DNS 인터페이스(320)가 그 자체의 데이터베이스에서 아무런 응답을 갖지 않는 DNS 네임을 수신할 때는 언제나 DNS 플러그인에 의해 호출될 수 있는 샘플 컴퓨터 코드 구현이 아래와 같을 수 있다.
DWORD WINAPI DnsPluginQuery(
PSTR pszQueryName,
WORD wQueryType,
PSTR pszRecordOwnerName,
PDB_RECORD* ppDnsRecordListHead
)
블록(450)에서, DNS 전단(300)은 PNRP 후단(310)으로부터 선택된 커뮤니티 중계 노드의 IP 주소를 수신할 수 있다. 선택된 커뮤니티 중계 노드 및 연결된 IP 주소는 클라이언트(220)에 의해 요청된 통신 프로토콜 유형에 관한 것이다. SSL 요청들을 위해, PNRP 후단(310)은 SSL 커뮤니티 중계 노드의 IPv4 주소를 반환할 수 있다. UDP 요청들을 위해, PNRP 후단(310)은 UDP 커뮤니티 중계 노드의 IPv6 주소를 반환할 수 있다. IPv6 주소는 커뮤니티 중계 노드에 접속하기 위한 포트 번호를 포함할 수 있다. 또 다른 한 예에서는, PNRP 후단(310)이 네트워크 주소 변환기(network address translator)(NAT) 운행을 위한 커뮤니티 중계 노드 IP 주소를 반환할 수 있다. NAT 운행을 위한 IP 주소는 커뮤니티 중계 노드의 외부 IPv4 주소를 밀봉하는 IPv6 주소, UDP 포트 번호, NAT 유형 및 NAT 운행 서버의 공개 IPv4 주소일 수 있다. NAT 운행 IP 주소는 IPv4 클라이언트들이 네트워크 주소 변환기 뒤에 있을 때 IPv6 네트워크를 통해 통신하는 것을 허용하도록 커뮤니티 중계 노드(240)와 요청 클라이언트(220) 사이의 순차적인 통신을 위해 이용될 수 있고, 그 예들은 "IPv4 클라이언트들이 서버 작업부하가 감소된 상태로 네트워크 주소 변환기 뒤에 있을 때 IPv6 네트워크를 통해 통신하도록 허용(Allowing IPv4 Clients to Communicate Over an IPv6 Network When Behind a Network Address Translator With Reduced Server Workload)"이라는 명칭을 갖는 2003. 3. 7자 출원된 미국특허출원 10/401,083호에 개시되어 있으며, 그 내용은 여기에 참고로 명백하게 포함되어 있다.
IP 주소는 초기 요청에 대한 응답으로 블록(455)에서 요청 클라이언트(210)에게 송신될 수 있다. 그 다음에, 클라이언트(210)는 HTTP 통신에 의해 커뮤니티 중계 노드(240)와 접촉하도록 IP 주소를 사용할 수 있고 커뮤니티 중계 노드에 의해 도움을 받는 경로설정 절차에 의해 접근 보호된 클라이언트(220)와 통신할 수 있다. 요청 클라이언트(220)는 커뮤니티 중계 노드(240)의 IP 주소를 더 사용하기 위해 캐시할 수 있고, 그럼으로써 프로모터(210)에 대한 부하를 줄인다. 클라이언트(220)가 그 캐시된 IP 주소에 기반한 응답을 수신하지 않으면, 클라이언트(220)는 다른 한 커뮤니티 중계 노드의 IP 주소를 위한 프로모터(210)에 대한 새로운 요청을 시작할 수 있다. 다른 한 예에서는, 클라이언트(220)에게 하나 이상의 커뮤니티 중계 노드들의 PNRP 주소가 제공될 수 있고, PNRP 쿼리들을 처리하며, 그럼으로써 프로모터(210)에 대한 부하를 더 줄인다. PNRP 쿼리가 아무런 응답도 반환하지 않으면, 클라이언트(220)는 프로모터(210)에게 요청을 제출할 수 있다.
도 5는 DNS 전단(300)으로부터 커뮤니티 중계 노드의 IP 주소로 수신된 PNRP 주소를 분석하는 방법(445)의 한 예의 플로우차트이다. DNS 전단(300)으로부터 PNRP 네임을 수신하는 것에 대한 응답으로, PNRP 후단(310)은 커뮤니티 중계 노드를 선택하고 IP 주소를 DNS 전단(300)에 반환할 수 있다.
도 5를 보면, PNRP 매니저(340)는 블록(500)에서 DNS 플러그인(330)으로부터 PNRP 네임을 수신할 수 있다. 필요하다면, PNRP 네임은 요청 캐시(380)에 대기될 수 있다. PNRP 매니저(340)는 PNRP 네임이 대기되었던 순서대로 요청에 응답할 수 있다. PNRP 매니저(340)는 동시 요청들의 수 및 분석 속도를 위한 예정된 임계치를 설정하고 요청 캐시(380)에 대기된 PNRP 네임들의 수 및 요청들을 분석하기 위한 평균 시간을 모니터할 수 있다. 요청 캐시(380)에서 예정된 유지시간을 초과하는 PNRP 네임들은 자동으로 폐기될 수 있다. 동시 요청들의 수 및 분석 속도가 임계치로부터 후퇴하지 않는 한 부가적 요청들이 거부될 수 있다.
요청에 응답할 준비가 되면, PNRP 매니저(340)는 블록(505)에서 분석되어야 할 PNRP 네임이 프로모터(210)의 관리자에 의해 허용된 PNRP 네임들의 목록에 있는지를 검사할 수 있다. 다시 말해서, PNRP 매니저(340)는 PNRP 네임과 결합된 커뮤니티 중계 노드들의 목록이 프로모터(210)에 의해 관리되는지를 판단할 수 있다. 대응하는 캐시가 비어 있거나 모든 커뮤니티 중계기들이 용량대로 사용되고 있으면 PNRP 네임이 지원되지 않을 수 있다. PNRP 매니저(340)는 각각의 요청에 대해 응답한 후에 지원된 PNRP 네임들의 목록을 관리하고 업데이트할 수 있다. PNRP 네임이 지원된 PNRP 네임들의 목록에서 발견되지 않으면, PNRP 매니저(340)는 블록 510에서 요청을 폐기하고 DNS 전단에 오류를 알릴 수 있다. 요청 캐시(380)의 모니터링에 기반하여 프로모터(210)가 요청들의 수나 분석 속도의 임계치에 도달했으면 PNRP 매니저(340)는 요청들을 지원하는 것을 거부할 수도 있다.
PNRP 네임이 지원되면, 블록(515)에서 PNRP 매니저(340)는 커뮤니티 중계 노드를 선택하기 위한 커뮤니티 중계 노드들의 관련 목록을 판단할 수 있다. 특수한 통신 프로토콜 유형의 커뮤니티 중계 노드들이 관련 분석 캐시(360,370)를 식별하기 위해 사용될 수 있는 단일의 PNRP 네임에 의한 목록으로서 저장될 수 있기 때문에, PNRP 매니저(340)는 요청 클라이언트(210)에 대해 제공될 수 있는 커뮤니티 중계 노드들의 IP 주소들을 포함하는 관련 캐시 또는 목록을 쉽게 판단할 수 있다. 예를 들어, DNS 전단으로부터 수신된 PNRP 네임이 "0.ssl.v1.promoter.microsoft.com"이면, PNRP 매니저(340)는 SSL 캐시(370)에서 관리되는 SSL 커뮤니티 중계 노드들의 목록에 접근할 수 있는 반면에, PNRP 네임이 "0.udp.v1.promoter.microsoft.com"이면, PNRP 매니저(340)는 UDP 캐시(360)에서 관리되는 UDP 커뮤니티 중계 노드들의 목록에 접근할 수 있다.
블록(515)에서의 판단이 SSL 통신 중계 노드와 결합된 PNRP 네임인 것으로 귀결되면, PNRP 매니저(340)는 블록(520)에서 SSL 캐시(360)에 접근할 수 있다. 각각의 클라이언트 요청이 수신됨에 따라 프로모터(210)가 커뮤니티 중계 노드들의 PNRP 쿼리들을 처리할 수 있을지라도, 그러한 프로세스는 느릴 수 있다. 그렇듯이, 프로모터(210)는 이용가능한 커뮤니티 중계 노드들의 IP 주소들을 미리 페치(fetch)하고 그 결과를 캐시(360,370)에 저장할 수 있다. 캐시(360)가 로우(low)이거나 비어 있으면, PNRP 매니저(340)는 요청에 응답하기를 거절하고 DNS 전단(300)에 알리고, 그에 따라 블록(560)에서 클라이언트(210)에게 알릴 수 있다. 캐시는 이용가능한 커뮤니티 중계 노드들의 결핍에 기반하여 로우(low)이거나 비어 있을 수 있으며, 그 것은 최대 부하 용량, 커뮤니티 중계 노드들이 오프라인 됨, 커뮤니티 중계 노드들이 이미 얽메어 있음 등에 기인한다. PNRP 매니저(340)는 아래에서 더 설명하듯이 블록(565)에서 캐시를 업데이트할 수 있다.
블록 525에서 판단된 바로서 SSL 캐시(360)가 이용가능한 커뮤니티 중계 노드들을 가지면, PNRP 매니저(340)는 블록 530에서 커뮤니티 중계 노드를 선택할 수 있다. 앞서 언급했듯이, 커뮤니티 중계 노드의 IP 주소는 서비스 품질, 부하 및 위치 등과 같은 부가적인 상세사항들에 따라 저장될 수 있다. 이러한 상세사항들은 커뮤니티 중계 노드를 선택할 때 PNRP 매니저(340)에 의해 고려될 수 있다. 예를 들어, PNRP 매니저(340)는 사용되거나 사용되지 않은 커뮤니티 중계 노드들의 목록들에 따라 이용가능한 커뮤니티 중계 노드들의 스택을 관리할 수 있다. 이용 가능한 커뮤니티 중계 노드들은 아래에서 더 설명되는 PNRP 분석에 기반하여 판단될 수 있다. 최신 커뮤니티 중계 노드들은 상위에 스택될 수 있으며, 사용에 따라 차례로 스택될 수 있고 더 고품질의 서비스 품질이 위를 향해 스택된다. 사용되고 있지만 부하가 낮은 커뮤니티 중계 노드들은 사용되지 않은 제1 그룹의 커뮤니티 중계 노드들의 하위에 스택될 수 있고 또한 서비스 품질에 따라 배열될 수도 있다. 따라서 순차적인 커뮤니티 중계 노드들이 스택될 수 있다.
커뮤니티 중계 노드들을 선택함에 있어서, PNRP 매니저(340)는 스택의 상위에서 시작하고 목록에서 최신의 사용되지 않은 높은 QOS 커뮤니티 중계 노드를 반환할 수 있다. 하나 이상의 커뮤니티 중계 노드가 선택되면, PNRP 매니저(340)는 요청 클라이언트(220)에게 가장 밀접한 커뮤니티 중계 노드를 선택할 수 있다. 그러나, 사용되지 않은 커뮤니티 중계 노드들이 존재하지 않으면, PNRP 매니저(340)는 최저 부하(즉, 가장 적게 사용된)를 갖는 커뮤니티 중계 노드를 선택할 수 있다. 그렇듯이, PNRP 매니저(340)는 모든 커뮤니티 중계 노드들이 사용되고 있을지라도 이용가능한 커뮤니티 중계 노드들 중에서 부하 균형을 맞출 수 있다. 모든 커뮤니티 중계 노드들 사이의 부하가 비교가능하다면, PNRP 매니저(340)는 최고 서비스 품질을 갖는 커뮤니티 중계 노드를 선택할 수 있다. PNRP 매니저(340)가 스택 전체에 걸쳐 조사하여 아무런 커뮤니티 중계 노드로도 귀결되지 않으면, PNRP 매니저(340)는 단순하게 그 스택의 제1 커뮤니티 중계 노드를 선택할 수 있다. 다른 한편으로는, 하나 이상의 커뮤니티 중계 노드가 선택된다면, PNRP 매니저(340)는 요청 클라이언트(220)에게 가장 밀접한 커뮤니티 중계 노드를 선택할 수 있다. PNRP 매니저가 적합한 커뮤니티 중계 노드를 발견했으면, IP 주소가 SSL 캐시(360)로부터 선택된다. 결과적으로 PNRP 매니저는 어쩌면 최고의 이용가능한 서비스 품질을 갖는 최신의 사용되지 않은 커뮤니티 중계 노드들을 선택할 수도 있다. 사용되지 않은 새로운 커뮤니티 중계 노드들 중 어느 것도 이용가능하지 않으면, PNRP 매니저(340)는 그 다음의 가장 적합한 커뮤니티 중계 노드를 선택할 수 있고, 그럼으로써 요청 클라이언트(220)에게 최선의 이용가능한 커뮤니티 중계 노드를 제공하면서 이용가능한 커뮤니티 중계 노드들 사이의 부하 균형을 맞출 수 있다. 커뮤니티 중계 노드들이 스택되고 선택을 위해 고려되는 순서는 개시된 것과 다를 수 있고 여기에 개시된 기준을 포함해서 다양한 기준에 따라 순서가 정해질 수 있음을 이해해야 한다.
SSL 커뮤니티 중계 노드를 선택할 때, PNRP 매니저(340)는 블록(535)에서 IP 주소를 DNS 전단(300)에 반환할 수 있고, 그에 따라 도 4를 참조하여 기술된 바와 같이 IP 주소를 요청 클라이언트(220)에게 반환할 수 있다. SSL 커뮤니티 중계 노드의 IP 주소는 IPv4 주소(예를 들어, 200.1.2.3)일 수 있다.
블록(515)에서의 판단이 PNRP 네임을 UDP 통신 중계 노드들과 연결시키는 것으로 귀결되면 유사한 프로세스가 처리될 수 있다. 블록(540)에서, PNRP 매니저(340)는 UDP 캐시(370)에 접근할 수 있다. 캐시(370)가 로우이거나 비어 있으면, PNRP 매니저(340)는 요청에 응답하기를 거부하고 DNS 전단(300)에 알릴 수 있으며, 그에 따라 블록(560)에서 클라이언트(210)에게 알릴 수 있으며, 블록(565)에서 캐시를 업데이트한다. UDP 캐시(370)가 이용가능한 커뮤니티 중계 노드들을 가 지면, PNRP 매니저(340)는 블록 560에서 커뮤니티 중계 노드를 선택할 수 있다. UDP 커뮤니티 중계 노드의 선택 프로세스는 위에서 기술된 SSL 커뮤니티 중계 노드를 위한 선택 프로세스와 동일할 수 있다. UDP 커뮤니티 중계 노드를 선택할 때, PNRP 매니저(340)는 블록 555에서 IP 주소를 DNS 전단(300)에 반환할 수 있으며, 그에 따라 도 4를 참조하여 기술된 바와 같이 IP 주소를 요청 클라이언트(220)에게 반환할 수 있다. UDP 커뮤니티 중계 노드의 IP 주소는 UDP 커뮤니티 중계 노드의 통신 포트 번호(예를 들어, 200.1.2.4, 포트 1234)를 갖는 IPv6 주소일 수 있다.
도 6A-6F를 보면, PNRP 매니저(340)는 커뮤니티 중계 노드의 선택을 보조하기 위해 이용가능한 커뮤니티 중계 노드들의 PNRP 스택을 따라 사용되거나 사용되지 않은 커뮤니티 중계 노드들의 목록들을 관리할 수 있다. 각각의 PNRP 네임(예를 들어, SSL의 PNRP 스택 및 UDP를 위한 PNRP 스택)을 위해 별도의 PNRP 스택이 관리될 수 있다. 도 6A에서, 이용가능한 커뮤니티 중계 노드(CNR 1, CNR 2, CNR 3)들은 사용되지 않은 채로 유지되고 사용되지 않은 커뮤니티 중계 노드들의 목록에 포함된다. CNR 3는 최신의 커뮤니티 중계 노드일 수 있고, 그러므로 상위에 스택된다. 그 다음에, 도 6B에 도시된 바와 같이, 커뮤니티 중계 노드(CRN 3)가 사용되고, 사용된 목록으로 이동되며, 남아 있는 사용되지 않은 커뮤니티 중계 노드들의 순위가 상승하며, 스택 포인터에 의해 표시될 수 있다. 도 6C에서는, 새로운 이용가능한 커뮤니티 중계 노드(CNR 4)가 스택에 부가된다. 이제 새로운 커뮤니티 중계 노드(CNR 4)가 최신의 것이기 때문에, 스택 포인터가 그 것이 선택되어야 할 첫번째 것임을 나타낼 수 있고 사용된 목록으로 이동된다. 도 6D에서는, 스택 포 인터들이 남아 있는 두 개의 사용되지 않은 커뮤니티 중계 노드(CNR 1 및 CNR 2)들이 선택되어야 하는 것임을 나타내고, 앞서의 커뮤니티 중계 노드(CNR 3 및 CNR 4)들은 이미 사용되었다. 도 6E에서는, 모든 이용가능한 커뮤니티 중계 노드들이 사용되었음과 함께, PNRP 매니저(340)는 부하 균형을 관리하기 위한 노력으로 최근에 가장 덜 사용된 CNR 3를 선택할 수 있다. 남아 있는 커뮤니티 중계 노드들은 사용된 목록으로부터 제거되고 더 이상의 새로운 또는 사용되지 않은 커뮤니티 중계 노드 없이 사용되지 않은 목록에 관리될 수 있다. 도 6F에서는, 새로운 이용가능한 커뮤니티 중계 노드(CNR 5)가 사용되지 않은 목록의 상위에 부가되고, CNR 3는 사용된 목록에서 가장 많이 사용된 커뮤니티 중계 노드로서 유지된다.
결과적으로, PNRP 매니저(340)는 최신의 가장 적게 사용된 커뮤니티 중계 노드들을 선택함으로써 이용가능한 커뮤니티 중계 노드들을 관리할 수 있고 부하 균형을 맞춘다. 사용되거나 사용되지 않은 목록들은 새로운 커뮤니티 중계 노드들을 부가하고 오래된 것을 제거할 수 있다. PNRP 매니저(340)는 최신의 사용되지 않은 커뮤니티 중계 노드들을 먼저 반환한다. 모든 커뮤니티 중계 노드들이 사용되면, PNRP 매니저(340)가 커뮤니티 중계 노드들을 그들이 앞서 사용된 순서대로 반환한다. PNRP 스택은 그 스택에 새로운 이용가능한 커뮤니티 중계 노드들을 계속 재상주(repopulate)시키기 위해 PNRP 네임들을 미리 페치할 책임이 있다. PNRP 스택은 그 크기를 적절한 수준으로 관리할 수 있다. 아래에서 설명된 PNRP 분석 이후에, 스택이 예정된 크기보다 더 크면, 더 오래되거나 또는 사용된 커뮤니티 중계 노드들이 스택으로부터 제거되고 PNRP 분석으로부터 새로운 이용가능한 커뮤니티 중계 노드들이 부가된다.
PNRP 매니저(340)는 요청이 만료되기 전에 몇 초에 대한 소정의 예정된 스택 크기의 비율로부터 계산되는 초 당 요구된 피분석 요청(resolved requests)들을 더 모니터할 수 있다. 어느 한 시기에서의 요청들의 수는 초 당 요구된 피분석 요청들과 사용된 분석들의 합으로부터 계산될 수 있다. 어느 한 시기 동안(예를 들어, 초 당), PNRP 매니저(340)는 스택 및 분석 캐시(360,370)들의 구성에서 정해진 한계보다 많은 PNRP 요청을 하지 않을 수 있다.
도 7은 분석 캐시(360,370)들을 업데이트하고 관리하는 방법(565)의 플로우차트이다. 도 5의 방법 동안에 구현되는 것으로 도시되었을지라도, 업데이트 방법(565)은 PNRP 매니저(340)의 다른 기능들과 병렬로 계속 처리될 수 있지만, 요청들이 이용가능한 커뮤니티 중계 노드들을 능가하는 경우 또는 앞서 선택된 커뮤니티 중계 노드를 교체 하기 위하여 특별하게 호출될 수도 있다. 효율적으로, PNRP 매니저(340)는 각각의 요청에 대한 응답으로서라기 보다는 요청들에 앞서서 커뮤니티 중계 노드들을 미리 페치할 수도 있다. PNRP 매니저(340)가 각각의 요청을 위한 커뮤니티 중계 노드들의 PNRP 쿼리들을 처리할 수 있지만, 미리 페치하는 것이 더 신속하게 결과를 반환할 수도 있다. 이 방법(565)은 SSL 캐시(360)와 UDP 캐시(370)를 위해 별도로 처리될 수 있다. 일반적으로, 분석 캐시(360,370)들은 크기와 기간(age)에 의해 구성할 수 있다.
도 7을 보면, PNRP 매니저(340)는 블록(600)에서 캐시가 로우인지 또는 비어 있는지를 판단할 수 있다. 캐시가 로우인지 여부는 예정된 임계치에 기반하여 판 단될 수 있다. 물론, 캐시가 비어 있으면, 캐시는 로우인 것으로 간주될 수 있다. 캐시는 사용되지 않은 커뮤니티 중계 노드들이 너무 적지 않은지, 가벼운 노드들을 갖는 사용된 커뮤니티 중계 노드들이 너무 적지 않은지, 높은 서비스 품질을 갖는 커뮤니티 중계 노드들이 너무 적지 않은지 등과 같이 다양한 파라미터들에 기반하여 고려될 수 있다. 캐시가 로우인 것으로 간주되면, 제어는 블록 610으로 넘어갈 수 있다. 캐시가 로우가 아니면, 제어는 블록(605)으로 넘어갈 수 있다.
블록(605)에서, PNRP 매니저(340)는 캐시(360,370)에 목록된 커뮤니티 중계 노드들 중 어느 것이 예정된 유지기간 임계치보다 오래되지 않았는지 판단할 수 있다. 커뮤니티 중계기가 오프라인 되거나 아니면 이용불가하게 될 수 있기 때문에, PNRP 매니저(340)는 목록을 참신(fresh)하게 유지하기 위해 예정된 시간이 지난 후 목록들로부터 커뮤니티 중계 노드들을 제거할 수 있다. 제거된 커뮤니티 중계 노드들은 PNRP 캐시(390)에 저장될 수 있다. 블록(605)에서 유지기간 임계치에 도달하거나 초과하면, 제어는 오래된 커뮤니티 중계 노드들을 새로운 커뮤니티 중계 노드들로 대체하기 위해 블록(610)으로 넘어갈 수 있다. 아니면, 제어는 업데이트 방법(565)을 계속 반복하기 위해 블록(600)으로 되돌아갈 수 있다.
블록 610에서, PNRP 매니저(340)는 PNRP 캐시(390)에서 관리되는 알려진 커뮤니티 중계 노드들의 목록과 결합된 PNRP 네임을 검색할 수 있다. PNRP 네임은 이용가능한 커뮤니티 중계 노드들의 목록(예를 들어, 0.ssl.v1.promoter.microsoft.com 또는 0.udp.v1.promoter.microsoft.com)을 식별하기 위해 사용된 것과 동일할 수 있다. 예를 들어, SSL 캐시(360)를 업데이트함 에 있어서, PNRP 매니저(340)는 알려진 SSL 커뮤니티 중계 노드들의 목록을 식별하기 위해 0.ssl.vl.promoter.microsoft.com의 PNRP 네임을 사용할 수 있다. UDP 캐시(370)를 업데이트함에 있어서, PNRP 매니저(340)는 알려진 UDP 커뮤니티 중계 노드들의 목록을 식별하기 위해 0.udp.v1.promoter.microsoft.com의 PNRP 네임을 사용할 수 있다. PNRP 캐시(390)에 의해 관리된 PNRP 네임들의 목록은 위에서 설명한 매핑 프로세스를 위해 사용된 것들과 동일할 수 있다. 단지 두 개의 PNRP 네임들만 관리하는 것으로 기술되어 있을지라도, PNRP 캐시(390)는, 통신 프로토콜 유형, 버전, 서비스 품질 등에 기반하여, 각각의 PNRP 네임이 하나 이상의 대응하는 커뮤니티 중계 노드들과 연결된 여러 PNRP 네임들을 관리할 수 있다.
블록(615)에서, PNRP 매니저(340)는 PNRP 네임을 이용하여 PNRP 인터페이스(350)에 의한 PNRP 분석을 처리할 수 있다. PNRP 분석은 프로모터(210)와 함께 등록되어 있는 다중 커뮤니티 중계 노드들을 쿼리하는 것을 포함할 수 있다. 결과적으로, 다중 커뮤니티 중계 노드들은 동시에 쿼리될 수 있다. 또한, PNRP 매니저(340)들은 동일한 PNRP 네임에 의한 무작위 IP 주소들을 반환하고 커뮤니티 중계 노드들 사이에서 균형잡힌 부하를 관리하기 위해 커뮤니티 중계 노드들을 무작위적으로 쿼리할 수 있다. PNRP 매니저(340)는 PNRP API들에 대한 무작위 힌트 번호를 사용할 수 있다. 무작위 번호는 커뮤니티 중계 노드들을 등록할 때와 PNRP 분석을 처리할 때 PNRP 네트워크로부터 무작위 결과들을 생성하기 위해 공급될 수 있다. PNRP 분석의 예들은 2001. 8. 29자 출원된 미국 특허 공보 2002/0143989호 및 2003. 6. 13자 출원된 미국 특허 공보 2005/0004916호에 개시되어 있으며, 그 내용 은 위에서 참고로 명백하게 포함되어 있다.
블록(620)에서 PNRP 매니저(340)가 하나 이상의 커뮤니티 중계 노드들로부터 응답을 수신하면, PNRP 매니저(340)는 분석 캐시(360,370)들에서 대응하는 목록에 커뮤니티 중계 노드의 IP 주소를 부가할 수 있다. 마찬가지로, PNRP 매니저(340)는 이용가능한 커뮤니티 중계 노드들의 스택들의 상위에 새로운 사용되지 않은 커뮤니티 중계 노드들을 부가할 수 있다. 한 예에서는, PNRP 매니저(340)가 최신의 사용되지 않은 커뮤니티 중계 노드들을 목록 및 스택들의 상위로 이동시킬 수 있다. 이렇게 분석 캐시(360,370)들을 지속적으로 미리 페치하고 업데이트한 결과로서, 더 새로운 커뮤니티 중계 노드들이 목록의 상위에 부가될 수 있다. PNRP 매니저(340)가 PNRP 쿼리에 대한 응답을 수신하지 않으면, 제어는 블록 610으로 되돌아갈 수 있고 PNRP 매니저(340)는 PNRP 쿼리를 위해 다음의 PNRP 네임을 사용할 수 있다.
앞서의 개시에 기반하여, 접근 보호된 요청 클라이언트는 커뮤니티 중계 노드들을 발견하기 위해 프로모터의 공지된 DNS 네임을 사용할 수 있다. DNS 네임은 통신 프로토콜 유형을 나타내도록 구성되고, 프로모터(210)의 DNS 전단에 의해 수신될 수 있다. DNS 네임의 형식에 기반하여, DNS 전단은 DNS 네임을 PNRP 네임과 결합시키고, PNRP 네임을 프로모터(210)의 PNRP 후단으로 전달한다. PNRP 후단은 커뮤니티 중계 노드를 선택하고 선택된 커뮤니티 중계 노드의 IP 주소를 DNS 전단에 반환하기 위해 커뮤니티 중계 노드들의 미리 페치된 목록들을 관리하고 PNRP 네임을 분석한다. 그리고, DNS 전단은 IP 주소를 요청 클라이언트에게 반환하며, 그 것은 HTTP에 의해 커뮤니티 중계 노드와 접촉한 다음에 통신 중계 노드로 방화벽들을 넘어가서 다른 한 접근 보호된 클라이언트와 통신할 수 있다. 통신 중계 노드는 통신 프로토콜 유형, 서비스 품질, 요청 클라이언트에 대한 근접성, 부하 등에 기반하여 선택될 수 있다. 커뮤니티 중계 노드들은 미리 정의된 PNRP 네임에 의해 IP 주소를 프로모터(210)에 등록할 수 있다. PNRP 후단은 PNRP 분석을 이용하여 이용가능한 커뮤니티 중계 노드들의 목록들을 계속 업데이트할 수 있다.
앞서의 텍스트가 여러 상이한 실시예들을 상세하게 기술하고 있을지라도, 특허의 범위는 이 특허의 끝에 설명된 특허청구의 범위의 문언에 의해 정의되는 것임을 이해해야 한다. 여기에서의 상세한 기술은 예시적인 것으로만 해석되어야 하며 불가피한 것이 아니라면 모든 가능한 실시예를 기술하는 것은 실용적이지 못하므로 모든 가능한 실시예를 기술하지는 않는다. 현재의 기술 또는 이 특허의 출원일 후에 개발된 기술을 이용하여 여전히 특허청구의 범위 내에 드는 여러 대안적 실시예들이 구현될 수 있다.
그래서, 본 특허청구의 범위의 정신 및 범위로부터 벗어남이 없이 여기에 기술되고 예시된 기법 및 구조들에서 많은 변경 및 변화들이 만들어질 수 있다. 따라서, 여기에 기술된 방법 및 장치는 단지 예시적인 것이며 특허청구의 범위에 대한 제한이 아니다는 것을 이해해야 한다.

Claims (20)

  1. 커뮤니티 중계 노드가 접근 보호된 클라이언트에 동작적으로 연결되어 있고 접근 보호된 클라이언트와 요청 클라이언트 사이의 통신을 돕기에 적합하게 구성된 네트워크 커뮤니티 내에서 커뮤니티 중계 노드를 발견하는 방법에 있어서,
    요청 클라이언트로부터 커뮤니티 중계 노드를 위한 요청에 관한 요청 메시지를 수신하는 단계,
    상기 요청 메시지를 무서버 네임 분석 프로토콜 네임과 연결시키는 단계,
    상기 무서버 네임 분석 프로토콜 네임에 기반하여 커뮤니티 중계 노드들의 목록 중에서 커뮤니티 중계 노드를 선택하는 단계-상기 커뮤니티 중계 노드들의 목록은 커뮤니티 중계 노드와 연결된 적어도 하나의 인터넷 프로토콜 주소를 포함함-, 및
    상기 선택된 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 요청 클라이언트에게 반환하는 단계를 포함하는 커뮤니티 중계 노드를 발견하는 방법.
  2. 제1항에 있어서,
    상기 요청 메시지는 요청된 통신 프로토콜 유형을 포함하며,
    상기 요청 메시지를 무서버 네임 분석 프로토콜 네임과 연결시키는 단계는 상기 요청 메시지를 상기 요청된 통신 프로토콜 유형을 위한 무서버 네임 분석 프로토콜 네임과 연결시키는 단계를 포함하고,
    상기 무서버 네임 분석 프로토콜 네임에 기반하여 커뮤니티 중계 노드들의 목록 중에서 커뮤니티 중계 노드를 선택하는 단계는 상기 통신 프로토콜 유형을 지원하는 커뮤니티 중계 노드들의 목록 중에서 커뮤니티 중계 노드를 선택하는 단계를 포함하며,
    상기 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 반환하는 단계는 상기 요청된 통신 프로토콜 유형을 지원하는 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 반환하는 단계를 포함하는 방법.
  3. 제2항에 있어서,
    상기 통신 프로토콜 유형은 SSL(secure sockets layer) 프로토콜 및 사용자 데이터그램 프로토콜로 이루어진 그룹 중에서 하나에 관한 방법.
  4. 제1항에 있어서,
    도메인 네임 시스템 네임을 상기 무서버 네임 분석 프로토콜 네임에 매핑하는 단계를 더 포함하고,
    상기 요청 메시지는 상기 도메인 네임 시스템 네임을 포함하며,
    상기 요청 메시지를 무서버 네임 분석 프로토콜 네임과 연결시키는 단계는 상기 도메인 네임 시스템 네임을 무서버 네임 분석 프로토콜 네임에 매치하는 단계를 포함하는 방법.
  5. 제1항에 있어서,
    상기 요청 유형이 도메인 네임 서비스 네임 및 상기 도메인 네임 서비스 네임에서 인코딩된 무서버 네임 분석 프로토콜 네임을 포함하고,
    상기 방법이,
    상기 도메인 네임 시스템 주소 네임으로부터 상기 무서버 네임 분석 프로토콜 네임을 디코딩하는 단계 및,
    상기 무서버 네임 분석 프로토콜 네임을 커뮤니티 중계 노드의 인터넷 프로토콜 주소로 분석하는 단계를 더 포함하는 방법.
  6. 제1항에 있어서,
    상기 무서버 네임 분석 프로토콜 네임에 기반하여 커뮤니티 중계 노드들의 목록 중에서 커뮤니티 중계 노드를 선택하는 단계는 부하 균형, 서비스 품질 및 상기 요청 클라이언트에 대한 상기 커뮤니티 중계 노드의 근접성으로 이루어진 그룹 중에서 하나 이상에 기반하여 커뮤니티 중계 노드들의 목록 중에서 커뮤니티 중계 노드를 선택하는 단계를 포함하는 방법.
  7. 제1항에 있어서,
    커뮤니티 중계 노드로부터 등록 메시지를 수신하는 단계-상기 등록 메시지는 무서버 네임 분석 프로토콜 네임 및 상기 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 포함함-,
    상기 등록된 커뮤니티 중계 노드의 무서버 네임 분석 프로토콜 쿼리를 처리하는 단계,
    상기 커뮤니티 중계 노드로부터 쿼리 응답을 수신하는 단계, 및
    상기 피어 네임 분석 프로토콜 주소 및 등록된 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 상기 커뮤니티 중계 노드들의 목록에 저장하는 단계를 더 포함하는 방법.
  8. 커뮤니티 중계 노드와 요청 클라이언트 사이의 통신을 부트스트랩 하는 방법의 단계들을 수행하는 컴퓨터 실행가능 명령어를 갖는 컴퓨터 판독가능 매체에 있어서,
    요청 클라이언트로부터 컴퓨터 도메인 네임을 수신하기 위한 컴퓨터 실행가능 명령어,
    상기 도메인 네임을 피어 네임과 연결시키기 위한 컴퓨터 실행가능 명령어,
    상기 피어 네임을 하나 이상의 인터넷 프로토콜 주소들로 분석하기 위한 컴퓨터 실행가능 명령어-각각의 인터넷 프로토콜 주소는 커뮤니티 중계기에 관한 것임-,
    상기 하나 이상의 분석된 인터넷 프로토콜 주소들로부터 커뮤니티 중계 노드를 선택하기 위한 컴퓨터 실행가능 명령어, 및
    상기 선택된 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 상기 요청 클라이언트에게 반환하기 위한 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매 체.
  9. 제8항에 있어서,
    상기 도메인 네임은 쿼리 네임 및 쿼리 유형을 포함하고,
    상기 컴퓨터 판독가능 매체는,
    상기 도메인 네임을 상기 쿼리 네임 및 상기 쿼리 유형으로 파싱하기 위한 컴퓨터 실행가능 명령어,
    상기 쿼리 네임을 상기 쿼리 유형에 따라 피어 네임과 연결시키기 위한 컴퓨터 실행가능 명령어, 및
    상기 쿼리 유형에 따라 커뮤니티 중계 노드를 선택하기 위한 컴퓨터 실행가능 명령어를 더 포함하는 컴퓨터 판독가능 매체.
  10. 제9항에 있어서,
    상기 쿼리 유형은 SSL(secure sockets layer) 프로토콜 및 사용자 데이터그램 프로토콜로 이루어진 그룹 중에서 하나를 포함하는 컴퓨터 판독가능 매체.
  11. 제8항에 있어서,
    상기 도메인 네임을 피어 네임과 연결시키기 위한 컴퓨터 실행가능 명령어는 상기 도메인 네임과 상기 피어 네임들의 예정된 맵에 기반하여 상기 도메인 네임을 상기 피어 네임에 매치시키기 위한 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판 독가능 매체.
  12. 제8항에 있어서,
    상기 도메인 네임을 피어 네임과 연결시키기 위한 컴퓨터 실행가능 명령어는 도메인 네임으로부터 상기 피어 네임을 디코딩하기 위한 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
  13. 제8항에 있어서,
    상기 하나 이상의 분석된 인터넷 프로토콜 주소들로부터 커뮤니티 중계 노드를 선택하기 위한 컴퓨터 실행가능 명령어는 부하 균형, 서비스 품질 및 상기 요청 클라이언트에 대한 상기 커뮤니티 중계 노드의 근접성으로 이루어진 그룹 중에서 하나 이상에 기반하여 커뮤니티 중계 노드를 선택하기 위한 컴퓨터 실행가능 명령어를 포함하는 컴퓨터 판독가능 매체.
  14. 컴퓨팅 장치에 있어서,
    프로세서 및 상기 프로세서에 동작적으로 연결된 메모리를 포함하는 처리 장치,
    네트워크 및 상기 처리 장치에 동작적으로 연결된 도메인 네임 시스템 네트워크 인터페이스,
    적어도 하나의 커뮤니티 중계기와 상기 도메인 네임 시스템 네트워크 인터페 이스 및 상기 처리 장치에 동작적으로 연결된 피어 네임 분석 프로토콜 네트워크 인터페이스,
    제1 피어 네임 분석 프로토콜 네임과 연결되고 제1의 다수의 커뮤니티 중계 노드들의 인터넷 프로토콜 주소들을 저장하기에 적합하게 구성된 제1 캐시-상기 제1 캐시는 상기 피어 네임 분석 프로토콜 네트워크 인터페이스와 동작적으로 연결됨-,
    제2 피어 네임 분석 프로토콜 네임과 연결되고 제2의 다수의 커뮤니티 중계 노드들의 인터넷 프로토콜 주소들을 저장하기에 적합하게 구성된 제2 캐시-상기 제2 캐시는 상기 피어 네임 분석 프로토콜 네트워크 인터페이스와 동작적으로 연결됨-를 포함하고,
    상기 처리장치는 클라이언트로부터 커뮤니티 중계 노드를 위한 요청에 관한 요청 메시지를 수신하도록 프로그래밍되고,
    상기 처리장치는 상기 요청 메시지를 상기 제1 피어 네임 분석 프로토콜 네임 또는 상기 제2 피어 네임 분석 프로토콜 네임으로 분석하도록 프로그래밍 되고,
    상기 처리장치는 상기 요청 메시지가 상기 제1 피어 네임 분석 프로토콜 네임으로 분석되면 상기 제1 캐시로부터 커뮤니티 중계 노드를 선택하도록 프로그래밍되고,
    상기 처리장치는 상기 요청 메시지가 상기 제2 피어 네임 분석 프로토콜 네임으로 분석되면 상기 제2 캐시로부터 커뮤니티 중계 노드를 선택하도록 프로그래밍되고,
    상기 처리장치는 상기 선택된 커뮤니티 중계 노드의 인터넷 프로토콜 주소를 상기 클라이언트로 송신하도록 프로그래밍되는 컴퓨팅 장치.
  15. 제14항에 있어서,
    상기 제1 피어 네임 분석 프로토콜 네임은 제1 통신 프로토콜 유형에 관한 것이고, 상기 제2 피어 네임 분석 프로토콜 유형은 제2 통신 프로토콜 유형에 관한 컴퓨팅 장치.
  16. 제15항에 있어서,
    상기 제1 통신 프로토콜 유형은 SSL(secure sockets layer) 프로토콜을 포함하고, 상기 제2 통신 프로토콜 유형은 사용자 데이터 프로토콜을 포함하는 컴퓨팅 장치.
  17. 제14항에 있어서,
    상기 요청 메시지는 상기 컴퓨팅 장치의 도메인 네임 시스템 네임을 포함하고,
    상기 처리 장치는 상기 도메인 네임 시스템 네임을 상기 제1 피어 네임 분석 프로토콜 네임 또는 상기 제2 피어 네임 분석 프로토콜 네임 중 하나로 분석하도록 프로그래밍되는 것인 컴퓨팅 장치.
  18. 제14항에 있어서,
    상기 처리 장치는 부하 균형, 서비스 품질 및 상기 클라이언트에 대한 상기 커뮤니티 중계 노드의 근접성으로 이루어진 그룹 중에서 하나 이상에 기반하여 상기 제1 캐시 또는 상기 제2 캐시로부터 커뮤니티 중계 노드를 선택하도록 프로그래밍되는 것인 컴퓨팅 장치.
  19. 제14항에 있어서,
    상기 프로그래밍 장치는 다수의 커뮤니티 중계 노드들을 쿼리하도록 프로그래밍되고,
    상기 프로그래밍 장치는 다수의 커뮤니티 중계 노드들 중 하나 이상으로부터 응답에 관한 데이터를 수신하도록 프로그래밍되며,
    상기 프로그래밍 장치는 상기 제1 캐시 또는 상기 제2 캐시를 상기 하나 이상의 응답하는 커뮤니티 중계 노드들에 의해 업데이트하도록 프로그래밍되는 것인 컴퓨팅 장치.
  20. 제19항에 있어서,
    상기 프로그래밍 장치는 상기 다수의 커뮤니티 중계 노드들의 피어 네임 분석을 처리하도록 프로그래밍되는 것인 컴퓨팅 장치.
KR1020077024170A 2005-04-22 2005-08-01 커뮤니티 중계 노드 발견을 위한 장치 방법 및 컴퓨터판독가능 매체 KR20080005507A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/907,985 US7788378B2 (en) 2005-04-22 2005-04-22 Apparatus and method for community relay node discovery
US10/907,985 2005-04-22

Publications (1)

Publication Number Publication Date
KR20080005507A true KR20080005507A (ko) 2008-01-14

Family

ID=37188341

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020077024170A KR20080005507A (ko) 2005-04-22 2005-08-01 커뮤니티 중계 노드 발견을 위한 장치 방법 및 컴퓨터판독가능 매체

Country Status (10)

Country Link
US (1) US7788378B2 (ko)
EP (1) EP1872240A2 (ko)
JP (1) JP2008538630A (ko)
KR (1) KR20080005507A (ko)
CN (1) CN101171579B (ko)
BR (1) BRPI0520188A2 (ko)
MX (1) MX2007013119A (ko)
RU (1) RU2007138965A (ko)
TW (1) TW200638710A (ko)
WO (1) WO2006115526A2 (ko)

Families Citing this family (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1974291A1 (en) * 2005-03-31 2008-10-01 British Telecommunications Public Limited Company Virtual network linking computers whose users share similar interests
US20070160069A1 (en) * 2006-01-12 2007-07-12 George David A Method and apparatus for peer-to-peer connection assistance
EP1814337A1 (en) * 2006-01-27 2007-08-01 Hewlett-Packard Development Company, L.P. Improvements in or relating to group communications
US20080104272A1 (en) * 2006-10-31 2008-05-01 Morris Robert P Method and system for routing a message over a home network
US20080147880A1 (en) * 2006-12-14 2008-06-19 Morris Robert P Methods And Systems For Routing A Message Over A Network
US20080147827A1 (en) * 2006-12-14 2008-06-19 Morris Robert P Method And System For Synchronizing Operating Modes Of Networked Appliances
US8782178B2 (en) * 2007-06-14 2014-07-15 Cisco Technology, Inc. Distributed bootstrapping mechanism for peer-to-peer networks
US7991910B2 (en) 2008-11-17 2011-08-02 Amazon Technologies, Inc. Updating routing information based on client location
US8028090B2 (en) 2008-11-17 2011-09-27 Amazon Technologies, Inc. Request routing utilizing client location information
US20100250737A1 (en) * 2007-10-31 2010-09-30 Interdisciplinary Center Herzliya Detecting and controlling peer-to-peer traffic
EP2071809A1 (en) * 2007-12-13 2009-06-17 Alcatel Lucent Method of establishing a connection in a peer-to-peer network with network address translation (NAT)
US20090161576A1 (en) * 2007-12-21 2009-06-25 Morris Robert P Methods And Systems For Sending Information To A Zone Included In An Internet Network
US8447831B1 (en) 2008-03-31 2013-05-21 Amazon Technologies, Inc. Incentive driven content delivery
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US7962597B2 (en) 2008-03-31 2011-06-14 Amazon Technologies, Inc. Request routing based on class
US7970820B1 (en) 2008-03-31 2011-06-28 Amazon Technologies, Inc. Locality based content distribution
US8321568B2 (en) 2008-03-31 2012-11-27 Amazon Technologies, Inc. Content management
US20090252161A1 (en) * 2008-04-03 2009-10-08 Morris Robert P Method And Systems For Routing A Data Packet Based On Geospatial Information
CN101557388B (zh) * 2008-04-11 2012-05-23 中国科学院声学研究所 一种基于UPnP和STUN技术相结合的NAT穿越方法
US9407681B1 (en) 2010-09-28 2016-08-02 Amazon Technologies, Inc. Latency measurement in resource requests
US20100011048A1 (en) * 2008-07-10 2010-01-14 Morris Robert P Methods And Systems For Resolving A Geospatial Query Region To A Network Identifier
US20100010975A1 (en) * 2008-07-10 2010-01-14 Morris Robert P Methods And Systems For Resolving A Query Region To A Network Identifier
US20100010992A1 (en) * 2008-07-10 2010-01-14 Morris Robert P Methods And Systems For Resolving A Location Information To A Network Identifier
US20100124220A1 (en) * 2008-11-18 2010-05-20 Morris Robert P Method And Systems For Incrementally Resolving A Host Name To A Network Address
WO2010090182A1 (ja) * 2009-02-03 2010-08-12 日本電気株式会社 アプリケーションスイッチシステム、及びアプリケーションスイッチ方法
US8156249B2 (en) * 2009-02-20 2012-04-10 Microsoft Corporation Using server type to obtain network address
US7933272B2 (en) * 2009-03-11 2011-04-26 Deep River Systems, Llc Methods and systems for resolving a first node identifier in a first identifier domain space to a second node identifier in a second identifier domain space
US8135912B2 (en) 2009-05-18 2012-03-13 Hola Networks, Ltd. System and method of increasing cache size
US8782236B1 (en) 2009-06-16 2014-07-15 Amazon Technologies, Inc. Managing resources using resource expiration data
US8935428B2 (en) * 2009-06-24 2015-01-13 Broadcom Corporation Fault tolerance approaches for DNS server failures
US8397073B1 (en) 2009-09-04 2013-03-12 Amazon Technologies, Inc. Managing secure content in a content delivery network
US20110066924A1 (en) * 2009-09-06 2011-03-17 Dorso Gregory Communicating in a computer environment
WO2011029080A2 (en) * 2009-09-06 2011-03-10 Sgiggle Incorporated Communicating in a computer environment
US8560604B2 (en) 2009-10-08 2013-10-15 Hola Networks Ltd. System and method for providing faster and more efficient data communication
US8832281B2 (en) * 2010-01-08 2014-09-09 Tangome, Inc. Utilizing resources of a peer-to-peer computer environment
US9094527B2 (en) * 2010-01-11 2015-07-28 Tangome, Inc. Seamlessly transferring a communication
US8560633B2 (en) * 2010-01-11 2013-10-15 Tangome, Inc. Communicating in a peer-to-peer computer environment
US9495338B1 (en) 2010-01-28 2016-11-15 Amazon Technologies, Inc. Content distribution network
US10958501B1 (en) 2010-09-28 2021-03-23 Amazon Technologies, Inc. Request routing information based on client IP groupings
US9003035B1 (en) 2010-09-28 2015-04-07 Amazon Technologies, Inc. Point of presence management in request routing
US8468247B1 (en) 2010-09-28 2013-06-18 Amazon Technologies, Inc. Point of presence management in request routing
US9712484B1 (en) 2010-09-28 2017-07-18 Amazon Technologies, Inc. Managing request routing information utilizing client identifiers
JP2012078902A (ja) * 2010-09-30 2012-04-19 Brother Ind Ltd 情報処理装置、情報処理方法及び情報処理プログラム
CN102447614B (zh) * 2010-10-14 2016-03-30 中兴通讯股份有限公司 一种中继节点的选择方法、系统及中继控制节点
CN102469015B (zh) * 2010-11-17 2016-04-13 中兴通讯股份有限公司 实现中继选择的方法及装置、系统
US8452874B2 (en) * 2010-11-22 2013-05-28 Amazon Technologies, Inc. Request routing processing
US10467042B1 (en) 2011-04-27 2019-11-05 Amazon Technologies, Inc. Optimized deployment based upon customer locality
US20120317153A1 (en) * 2011-06-07 2012-12-13 Apple Inc. Caching responses for scoped and non-scoped domain name system queries
US9001804B2 (en) * 2011-06-16 2015-04-07 Qualcomm Incorporated Sharing multi description coded content utilizing proximate helpers
US10623408B1 (en) 2012-04-02 2020-04-14 Amazon Technologies, Inc. Context sensitive object management
US9154551B1 (en) 2012-06-11 2015-10-06 Amazon Technologies, Inc. Processing DNS queries to identify pre-processing information
US10205698B1 (en) 2012-12-19 2019-02-12 Amazon Technologies, Inc. Source-dependent address resolution
US9104241B2 (en) 2013-07-17 2015-08-11 Tangome, Inc. Performing multiple functions by a mobile device during a video conference
US9241044B2 (en) 2013-08-28 2016-01-19 Hola Networks, Ltd. System and method for improving internet communication by using intermediate nodes
US20150067033A1 (en) * 2013-09-05 2015-03-05 Cisco Technology, Inc Relay Server Load Balancing and Placement using In-Band Signaling
US10410244B2 (en) 2013-11-13 2019-09-10 Bi Science (2009) Ltd Behavioral content discovery
CN104331484B (zh) * 2014-11-05 2017-10-17 北京航空航天大学 基于影响力最大化的节点查询方法和装置
US10097448B1 (en) 2014-12-18 2018-10-09 Amazon Technologies, Inc. Routing mode and point-of-presence selection service
US10225326B1 (en) 2015-03-23 2019-03-05 Amazon Technologies, Inc. Point of presence based data uploading
US9832141B1 (en) 2015-05-13 2017-11-28 Amazon Technologies, Inc. Routing based request correlation
US11057446B2 (en) 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
US10936674B2 (en) * 2015-08-20 2021-03-02 Airwatch Llc Policy-based trusted peer-to-peer connections
EP3343982B1 (en) 2015-09-25 2019-11-06 Huawei Technologies Co., Ltd. Paging method, synchronization method, and user equipment
US10270878B1 (en) 2015-11-10 2019-04-23 Amazon Technologies, Inc. Routing for origin-facing points of presence
US10075551B1 (en) 2016-06-06 2018-09-11 Amazon Technologies, Inc. Request management for hierarchical cache
US10110694B1 (en) 2016-06-29 2018-10-23 Amazon Technologies, Inc. Adaptive transfer rate for retrieving content from a server
US10469513B2 (en) 2016-10-05 2019-11-05 Amazon Technologies, Inc. Encrypted network addresses
US10831549B1 (en) 2016-12-27 2020-11-10 Amazon Technologies, Inc. Multi-region request-driven code execution system
US10938884B1 (en) 2017-01-30 2021-03-02 Amazon Technologies, Inc. Origin server cloaking using virtual private cloud network environments
US11075987B1 (en) 2017-06-12 2021-07-27 Amazon Technologies, Inc. Load estimating content delivery network
EP4199479A1 (en) 2017-08-28 2023-06-21 Bright Data Ltd. Improving content fetching by selecting tunnel devices grouped according to geographic location
US11190374B2 (en) 2017-08-28 2021-11-30 Bright Data Ltd. System and method for improving content fetching by selecting tunnel devices
US10742593B1 (en) 2017-09-25 2020-08-11 Amazon Technologies, Inc. Hybrid content request routing system
US10592578B1 (en) 2018-03-07 2020-03-17 Amazon Technologies, Inc. Predictive content push-enabled content delivery network
US10862852B1 (en) 2018-11-16 2020-12-08 Amazon Technologies, Inc. Resolution of domain name requests in heterogeneous network environments
US11025747B1 (en) 2018-12-12 2021-06-01 Amazon Technologies, Inc. Content request pattern-based routing system
LT3780547T (lt) 2019-02-25 2023-03-10 Bright Data Ltd. Turinio parsisiuntimo, naudojant url bandymų mechanizmą, sistema ir būdas
US11411922B2 (en) 2019-04-02 2022-08-09 Bright Data Ltd. System and method for managing non-direct URL fetching service
CN110266828A (zh) * 2019-06-11 2019-09-20 华为技术有限公司 一种建立端到端网络连接的方法、装置及网络系统
CN112437106A (zh) * 2020-08-31 2021-03-02 上海哔哩哔哩科技有限公司 一种使用中继节点上传文件的方法及设备
CN113472668B (zh) * 2021-07-26 2023-06-20 支付宝(杭州)信息技术有限公司 多方安全计算中的路由方法和系统

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7454373B2 (en) * 2000-11-06 2008-11-18 Jpmorgan Chase Bank, N.A. System and method for providing automated database assistance to financial service operators
AU2002234258A1 (en) * 2001-01-22 2002-07-30 Sun Microsystems, Inc. Peer-to-peer network computing platform
US7065587B2 (en) 2001-04-02 2006-06-20 Microsoft Corporation Peer-to-peer name resolution protocol (PNRP) and multilevel cache for use therewith
US7613812B2 (en) 2002-12-04 2009-11-03 Microsoft Corporation Peer-to-peer identity management interfaces and methods
US7245622B2 (en) 2003-03-27 2007-07-17 Microsoft Corporation Allowing IPv4 clients to communicate over an IPv6 network when behind a network address translator with reduced server workload
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
US7949996B2 (en) 2003-10-23 2011-05-24 Microsoft Corporation Peer-to-peer identity management managed interfaces and methods
US7496648B2 (en) 2003-10-23 2009-02-24 Microsoft Corporation Managed peer name resolution protocol (PNRP) interfaces for peer to peer networking
US20050177715A1 (en) 2004-02-09 2005-08-11 Microsoft Corporation Method and system for managing identities in a peer-to-peer networking environment
US20060053485A1 (en) * 2004-09-08 2006-03-09 Chia-Hsin Li Network connection through NAT routers and firewall devices
US7640329B2 (en) 2005-02-15 2009-12-29 Microsoft Corporation Scaling and extending UPnP v1.0 device discovery using peer groups

Also Published As

Publication number Publication date
WO2006115526A2 (en) 2006-11-02
BRPI0520188A2 (pt) 2009-04-22
JP2008538630A (ja) 2008-10-30
TW200638710A (en) 2006-11-01
US7788378B2 (en) 2010-08-31
CN101171579A (zh) 2008-04-30
MX2007013119A (es) 2008-01-14
RU2007138965A (ru) 2009-04-27
WO2006115526A3 (en) 2007-01-25
CN101171579B (zh) 2012-08-22
US20060242227A1 (en) 2006-10-26
EP1872240A2 (en) 2008-01-02

Similar Documents

Publication Publication Date Title
KR20080005507A (ko) 커뮤니티 중계 노드 발견을 위한 장치 방법 및 컴퓨터판독가능 매체
US11758013B2 (en) Methods and systems for caching data communications over computer networks
KR101247027B1 (ko) 장치를 위한 웹 서비스를 이용하는 트랜스 네트워크 로밍및 찾기
US20180324282A1 (en) System providing faster and more efficient data communication
EP2112788B1 (en) A method and node for p2p content sharing
US9998533B2 (en) P2P content caching system and method
US7340500B2 (en) Providing peer groups in a peer-to-peer environment
US10044826B2 (en) Method and apparatus for reducing network resource transmission size using delta compression
US20030145093A1 (en) System and method for peer-to-peer file exchange mechanism from multiple sources
US20100169442A1 (en) Apparatus and method for providing peer-to-peer proxy service with temporary storage management and traffic load balancing in peer-to-peer communications
US20090157829A1 (en) Peer-to-peer service system and method using e-mail service
US20090299937A1 (en) Method and system for detecting and managing peer-to-peer traffic over a data network
US20090063507A1 (en) Methods and apparatus for retrieving content
KR20080003347A (ko) 서버리스 피어 투 피어 네트워크에서 종점을 발견하기 위한애플리케이션 프로그래밍 인터페이스
US20060236386A1 (en) Method and apparatus for cooperative file distribution in the presence of firewalls
JP4437956B2 (ja) ファイル共有アプリケーションに対するインデックス・サーバ・サポートを提供する方法
Bieri An overview into the InterPlanetary File System (IPFS): use cases, advantages, and drawbacks
US20120327931A1 (en) Gateways integrating name-based networks with host-based networks
JP4223045B2 (ja) Ｄｎｓサーバ装置、要求電文処理方法および要求電文処理プログラム
White-Swift et al. DDD: Distributed Dataset DNS
KR20040110957A (ko) 피투피(피어 투 피어) 기술을 이용한 웹 컨텐츠를검색하는 방법 및 그 장치
Lehtinen Peer-to-Peer Architectures and Signaling

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