KR101120695B1 - 서버 풀들을 이용할 때의 효율적인 메시지 라우팅 - Google Patents

서버 풀들을 이용할 때의 효율적인 메시지 라우팅 Download PDF

Info

Publication number
KR101120695B1
KR101120695B1 KR1020050042306A KR20050042306A KR101120695B1 KR 101120695 B1 KR101120695 B1 KR 101120695B1 KR 1020050042306 A KR1020050042306 A KR 1020050042306A KR 20050042306 A KR20050042306 A KR 20050042306A KR 101120695 B1 KR101120695 B1 KR 101120695B1
Authority
KR
South Korea
Prior art keywords
server
message
delete delete
routine
pool
Prior art date
Application number
KR1020050042306A
Other languages
English (en)
Other versions
KR20060048035A (ko
Inventor
바딤 에델맨
스리칸스 쇼로프
Original Assignee
마이크로소프트 코포레이션
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 마이크로소프트 코포레이션 filed Critical 마이크로소프트 코포레이션
Publication of KR20060048035A publication Critical patent/KR20060048035A/ko
Application granted granted Critical
Publication of KR101120695B1 publication Critical patent/KR101120695B1/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]
    • 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/16—Implementing security features at a particular protocol layer
    • H04L63/166—Implementing security features at a particular protocol layer at the transport layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1101—Session protocols
    • H04L65/1104—Session initiation protocol [SIP]
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1008—Server selection for load balancing based on parameters of servers, e.g. available memory or workload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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
    • 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/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/101—Server selection for load balancing based on network conditions

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Multimedia (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Computing Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Hardware Redundancy (AREA)

Abstract

서버 풀을 사용해 메시지들을 효율적으로 라우팅하기 위한 접근 방법들이 제공된다. 일 실시예에서, 본 시스템은, 서버 풀이 각각 고유한 이름을 가진 다수 서버들을 포함하는 경우라 하더라도, 클라이언트들이 서버 풀에 대한 도메인 이름을 특정할 수 있게 하는 것에 의해, 서버들의 높은 이용 가능성을 보장하고자 한다. 클라이언트가 서버 풀의 도메인 이름을 사용하여 세션을 개시할 때, 본 시스템은 상이한 이름을 가진 이용 가능한 서버를 선택할 수 있고, 선택된 서버로의 세션 동안 요청 및 후속 메시지들을 라우팅할 것이다. 본 시스템은 풀로부터 최저 부하를 가진 서버를 선택할 수도 있다. 또한, 본 시스템은, 세션의 후속 메시지들이 통과할 서버들을 지시(indicate)할 수도 있다. 그 다음, 후속 메시지들은 지시된 서버들로 라우팅되어, 지시된 서버들상의 애플리케이션 서비스들이 메시지들 및 메시지들의 다이렉션에 기초하여 동작들을 취하게 할 수 있다.
서버 풀, 세션, 메시지 라우팅, 애플리케이션 서비스

Description

서버 풀들을 이용할 때의 효율적인 메시지 라우팅 {EFFICIENT MESSAGE ROUTING WHEN USING SERVER POOLS}
도 1은 서버 풀들을 사용할 때의 효율적인 메시지 라우팅을 위한 시스템의 일 실시예를 도시하는 블록도이다.
도 2는 도 1의 서버 풀에 대한 일 실시예를 도시하는 블록도이다.
도 3은 요청 메시지 헤더를 평가하기 위해 프럭시 서버에 의해 수행되는 루틴의 일 실시예를 도시하는 흐름도이다.
도 4는 요청 메시지 헤더를 프로세싱하기 위해 프럭시 서버에 의해 수행되는 루틴의 일 실시예를 도시하는 흐름도이다.
도 5는 요청 메시지를 프로세싱하기 위해 시스템의 ESC(enterprise services component)에 의해 수행되는 루틴의 일 실시예를 도시하는 흐름도이다.
도 6은 애플리케이션-관련 라우팅을 가능하게 하기 위해 요청 메시지 헤더를 프로세싱하는 루틴의 일 실시예를 도시하는 흐름도이다.
도 7은 응답 메시지를 프로세싱하는 루틴의 일 실시예를 도시하는 흐름도이다.
<도면의 주요 부분에 대한 부호의 설명>
102 : 서버 풀
108 : 네트워크
110: 사용자
204 : 서버
206 : 데이터베이스
208 : 부하 분산 장치
210 : 프럭시
설명된 기술은 일반적으로 데이터 통신에 관한 것으로서, 보다 구체적으로는, 서버 풀들을 이용할 때에 메시지들을 효율적으로 라우팅하기 위한 방법들 및 시스템들에 관한 것이다.
애플리케이션들은 때때로 컴퓨팅 장치들 사이에서 세션을 확립하고 관리해야 한다. 세션은, 일정 시간에 걸쳐 발생하는, 컴퓨팅 장치들간의 한 세트의 상호 작용들이다. 일례로서, MICROSOFT MESSENGER 또는 VoIP(Voice over Internet Protocol)와 같은 실시간 통신 애플리케이션들은 사용자를 위해서 컴퓨팅 장치들 사이에 세션들을 확립한다. 이들 애플리케이션들은, "SIP(Session Initiation Protocol)"과 같은, 다양한 메커니즘들을 사용해 세션들을 확립할 수 있다. SIP은, 장치들이 서로를 찾아내고, 장치들 사이에서 세션들을 확립, 변경, 및 종결하는데 사용할 수 있는 애플리케이션-계층 제어 프로토콜(application-layer control protocol)이다. SIP은 인터넷 제안 표준이다. 그것의 스펙(specification) "RFC 3261"은 <http://www.ietf.org/rfc/rfc3261.txt>에서 입수할 수 있다. 이벤트 통지들에 관한 SIP에 대한 연장 부분들을 위한 스펙 "RFC 3265"는 <http://www.ietf.org/rfc/rfc3265.txt>에서 입수할 수 있다. 이러한 스펙들 모두는 그 전부가 참조로써 여기에 포함되어 있다.
애플리케이션들은 또 다른 프로토콜과 함께 SIP을 사용해 정보를 송수신할 수 있다. 일례로서, 애플리케이션은, 세션 동안 실시간 데이터를 전송하기 위해, RTP(Real-time Transport Protocol)과 함께 SIP을 사용할 수 있다. 다른 프로토콜들과 함께 SIP을 사용하는 것에 의해, 애플리케이션들은 세션을 생성 및 관리할 수 있고 세션 동안 정보를 교환할 수 있다. 정보를 교환하기 위해 SIP과 함께 사용된 프로토콜은 정보를 메시지들로 조각낼 수 있다. 또한, 장치들은 SIP 메시지들을 교환할 수도 있다. 세션 동안의 이러한 메시지 교환을 "다이얼로그"라고 한다. SIP은, 전송- 및 네트워크-계층 프로토콜들에 흔히 이용되는, TCP/IP(Transmission Control Protocol/Internet Protocol)와 같은, 하부-레벨 통신 계층들을 사용해 다이얼로그의 메시지들을 전송할 수 있다.
SIP 네트워크는, 클라이언트, 서버, 또는 양자로서 다이얼로그에 참여할 수 있는 엔티티들을 포함한다. SIP은 4가지 유형의 엔티티들: 사용자 에이전트, 프럭시 서버, 리다이렉트 서버, 및 레지스트라(registrar)를 지원한다. 사용자 에이전트들은 다른 SIP 엔티티들과 메시지들을 교환하는 것에 의해 세션들을 개시하고 종결한다. 사용자 에이전트는, 일반적으로 SIP 요청들을 개시하는 장치인 사용자 에 이전트 클라이언트이거나, 일반적으로 SIP 요청들을 수신하고 이러한 요청들에 응답하는 장치인 사용자 에이전트 서버일 수 있다. 예를 들어, "IP-전화기들", PDA들, 및 다른 유형의 컴퓨팅 장치가 사용자 에이전트들일 수 있다. 장치가 하나의 다이얼로그에서는 사용자 에이전트 클라이언트이고 다른 다이얼로그에서는 사용자 에이전트 서버일 수 있거나, 다이얼로그 동안에 역할들을 변경할 수도 있다. 프럭시 서버는, 클라이언트들에 대한 서버로서 그리고 서버들에 대한 클라이언트로서 동작하는 엔티티이다. 그렇게 동작하면서, 프럭시 서버들은 클라이언트들과 서버들 사이에서 메시지들을 가로채기하거나, 해석하거나, 전송한다. 리다이렉트 서버는 SIP 요청을 수용하고, 다른 네트워크 리소스에 접촉하기 위해 요청을 송신한 클라이언트에 대한 응답을 생성한다. 레지스트라는 SIP 클라이언트들로부터 등록 정보를 수용하고 수신된 등록 정보의 로케이션 서비스를 통지하는 서버이다.
SIP은 2가지 메시지 유형들: 클라이언트로부터 서버로 송신되는 요청들 및, 일반적으로 요청에 응답할 때, 서버로부터 클라이언트로 송신되는 응답들을 지원한다. SIP 메시지는 3개 부분들로 이루어진다. SIP 메시지의 제 1 부분은, 메시지 유형 및 프로토콜 버전을 지시(indicate)하는 필드들을 포함하는 "시작 라인(start line)"이다. SIP 메시지의 제 2 부분은, 그것의 값들이 이름-값 쌍들로 표현되는 헤더 필드들을 포함한다. SIP 메시지의 제 3 부분은, 개시될 세션을 설명하거나 세션에 관련된 데이터를 포함하는데 사용되는 메시지의 바디이다. 메시지 바디들은 요청들 또는 응답들로 나타날 수 있다.
SIP 메시지들은 그들의 헤더 필드들의 컨텐츠에 기초하여 라우팅된다. 유효 하기 위해, SIP 요청은 적어도 다음의 6개 헤더 필드들: To, From, CSeq, Call-ID, Max-Forwards, 및 Via를 포함해야 한다. To 헤더 필드는, 요청의 수신자에 대한 논리적 식별 정보를 지시한다. From 헤더 필드는, 요청의 개시자에 대한 논리적 식별 정보를 지시한다. Max-Forwards 헤더 필드는, 요청이 요청의 목적지에 도달하기 전에 형성할 수 있는 홉들의 수(the number of hops)를 지시한다. 예를 들어, 장치 A로부터의 메시지가 목적지 장치 C에 도달하기 전에 장치 B를 통과한다면, 메시지는 2개의 홉들(예를 들어, 장치들 B 및 C)을 형성했다고 할 수 있다. Via 헤더 필드는 지금까지 요청에 의해 취해진 경로(예를 들어, 요청이 통과한 장치들에 대한 네트워크 어드레스들의 시퀀스)를 지시하고 응답을 라우팅할 때 따라야 할 경로를 지시한다. 또한, 헤더는, 장래의 요청들 및 응답들이 지시된 장치를 통해 라우팅되어야 한다는 것을 지시하는데 사용되는 Recorder 및 Record-Route 필드들을 포함할 수도 있다. 다이얼로그의 후속 메시지들이 장치를 통해 라우팅되게 하려는 의도로 SIP 메시지를 전송할 때, 다양한 네트워크 장치들은 Record-Route 헤더 필드들을 삽입할 수 있다. Record-Route 헤더 필드는 장치에 대한 식별자(예를 들어, 네트워크 어드레스) 및 파라미터들을 포함할 수 있다. 메시지를 핸들링하는 장치들은, 메시지가 메시지의 Route 헤더 필더에 열거된 장치들로 라우팅되게 할 수 있다. Route 헤더 필드 값들은 장치들에 의해 삽입된 Record-Route 헤더 필드 값들에 기초할 수 있다. 상술된 SIP 스펙에, 이들 및 다른 헤더 필드들이 설명되어 있다.
SIP 서버는 실패의 단일 포인트일 수 있고 다수의 동시 세션들을 지원할 수 없을 수도 있다. 클라이언트로부터의 또는 클라이언트로의 모든 SIP 메시지들이 서버를 통과할 수 있으며, 서버가 실패하면, 로케이션 서비스는 클라이언트를 실패한 서버와 관련지을 수 있기 때문에 클라이언트가 SIP 다이얼로그들에 참여할 수 없으므로, 서버는 실패의 단일 포인트일 수 있다. 단일 서버는, 하드웨어(예를 들어, 프로세서 또는 메모리) 및 네트워크 대역폭의 한계들로 인해, 다수의 클라이언트들을 지원할 수 없다. 이러한 경우, 다수의 클라이언트들은 서버 지원이 거부될 수 있고, 이로 인해, 이러한 클라이언트들에서는 애플리케이션들이 수행될 수 없게 된다.
SIP의 이러한 단점들을 극복하기 위한 효과적인 접근 방법은 상당한 유용성을 가질 것이다.
서버들의 풀을 사용해 메시지들을 효율적으로 라우팅하기 위한 접근 방법들이 제공된다. 일 실시예에서, 시스템은, 서버 풀이 각각 고유한 이름을 가진 다수 서버들을 포함하는 경우라 하더라도, 클라이언트들이 서버 풀에 대한 도메인 이름을 특정할 수 있게 하는 것에 의해, 서버들의 높은 이용 가능성을 보장하고자 한다. 클라이언트가 서버 풀의 도메인 이름을 사용하여 세션을 개시할 때, 시스템은 상이한 이름을 가진 이용 가능한 서버를 선택할 수 있고, 선택된 서버로의 세션 동안 요청 및 후속 메시지들을 라우팅할 것이다. 시스템은 풀로부터 최저 부하를 가진 서버를 선택할 수도 있다. 또한, 시스템은, 세션의 후속 메시지들이 통과할 서버들을 지시할 수도 있다. 그 다음, 후속 메시지들은 지시된 서버들로 라우팅되 어, 지시된 서버들상의 애플리케이션 서비스들이 메시지들 및 메시지들의 다이렉션(direction)에 기초하여 동작들을 취하게 할 수 있다.
일 실시예에서는, 서버들의 풀을 사용해 메시지들을 효율적으로 라우팅하는 시스템이 제공된다. 시스템은, 풀이 각각 상이한 FQDN(fully qualified domain name)을 가진 다수 서버들을 포함하는 경우라 하더라도, 클라이언트가 서버 풀에 대해 하나의 FQDN을 특정할 수 있게 하는 것에 의해, 서버의 높은 가용성을 보장하고자 한다. 클라이언트가 풀의 FQDN을 사용해 SIP 세션을 개시할 때, 시스템은 풀로부터 이용 가능한 서버(또는 "전단 서버(front end server)")를 선택할 수 있고 세션 동안의 요청 및 후속 메시지들을 선택된 서버로 라우팅할 것이다. 선택된 서버의 FQDN은 서버 풀의 FQDN과 상이할 수 있다. 시스템은, 서버 풀로부터 최저 부하를 가진 서버를 선택할 수 있다. 후속 메시지들은 선택된 서버를 통과할 것이기 때문에, 시스템은 다른 서버들에 대한 홉들을 최소화하기 위해 메시지들을 선택된 서버로 직접 라우팅하고자 할 수도 있다. 메시지들이 선택된 서버로 직접 라우팅되지 않는 대신 다른 중간 서버들로 라우팅된다면, 서버들은 트래픽을 불필요하게 핸들링하는 중이기 때문에, 서버들의 전반적인 부하가 증가할 수 있다. 또한, 추가적인 홉들로 인해, 전반적인 메시지 지연이 증가할 수도 있다. 메시지들의 직접적인 라우팅을 가능하게 하기 위해, 시스템은, 선택된 서버의 FQDN을 파라미터로서 요청의 헤더 필드에 추가하는 것에 의해, 메시지들의 헤더들을 변경한다. 네트워크상의 장치들은 이러한 파라미터를 사용해 메시지들을 선택된 서버로 직접 라우팅 할 수 있다. 또한, 시스템은 메시지 수신자의 등록 서버(예를 들어, 레지스트라)에 대한 FQDN을 파라미터로서 헤더 필드에 추가할 수도 있다. 네트워크상의 장치들은 이러한 헤더 필드를 사용해, 예를 들어, 수신자에 관한 정보를 찾아내기 위해, 등록 서버와 통신할 수 있다. SIP 스펙에 따라 메시지들을 라우팅하는 장치들은 이러한 헤더 필드들 및 파라미터들을 세션 동안에 교환되는 후속의 SIP 메시지들에 보존할 것이다. 이러한 헤더 필드들 및 파라미터들을 평가하는 것에 의해, 네트워크 장치들은 메시지들을 선택된 서버로 직접 라우팅할 수 있고 수신자와 관련된 등록 서버에 저장되어 있는 정보를 찾아낼 수 있다. 후속 세션에서 또는, (예를 들어, 선택된 서버가 충돌했기 때문에) 선택된 서버가 더 이상 이용 불가능하여 세션이 재확립되어야 한다면, 시스템은 클라이언트를 위해 다른 서버를 선택할 수 있다. 이와 같이, 시스템은 서버들의 높은 가용성을 보장할 수 있고 서버들에 걸쳐 부하의 균형을 맞출 수 있다.
일 실시예에서는, 메시지의 경로를 따라 서버들에서 실행 중인 애플리케이션들이, 통과 중인 메시지들을 정확하게 프로세싱할 수 있다는 것을 보장하기 위해, 서버들이 서버에 대한 역할을 지시하는 플래그를 메시지의 헤더에 부가할 수 있다. 예를 들어, 경로상의 서버는 사용자에 의해 송신되거나 수신된 메시지들에 관한 과금 정보를 기록할 수 있다. 애플리케이션이 모든 메시지 트래픽을 인지하고 그것의 역할에 기초하여 적절한 동작을 취할 수 있다는 것을 보장하기 위해, 시스템은 메시지 헤더 필드에 To/From 플래그를 부가한다. 헤더 필드로부터 서버의 역할이 세션 생성 요청의 원래 송신자로부터의 또는 원래 송신자로의 메시지들을 핸들링하 는 것인지를 판정하는 것에 의해, 애플리케이션은 서버의 역할을 판정하기 위해 값비싼 데이터베이스 룩업들을 수행할 필요없이 적절한 동작을 취할 수 있다. 헤더 필드의 파라미터들을 사용해 서버의 역할을 지시하는 것 또한, 시스템으로 하여금, 서버들이 메시지들을 통해 애플리케이션-관련 동작들을 취하게 할 수 있다. 이러한 정보가 Record-Route 헤더 필드들의 파라미터들로서 나타날 경우, 시스템에 의해 제어되지 않는 SIP-장해 장치들(SIP-complaint devices)은 정보를 리턴할 것이다. 메시지와 함께 이동하는 헤더 필드들 및 파라미터들을 부가한 결과로서, 데이터베이스 또는 다른 룩업들이 방지되고 메시지들은 정확하게 프로세싱된다.
일 실시예에서는, 시스템이 완전히 인증되지 않은 도메인 및 장치 이름들을 사용한다. 예를 들어, 시스템은 상대적인 도메인 이름들 또는 머신 이름들을 사용할 수 있다. 시스템은 이러한 도메인 및 장치 이름들을 리졸브(resolve)하거나 사용해 서버 풀 또는 장치를 고유하게 식별할 수 있다.
이제 도면들을 살펴보면, 도 1은 서버 풀들을 사용할 때의 효율적인 메시지 라우팅을 위한 시스템의 일 실시예를 도시하는 블록도이다. 시스템은 하나 이상의 서버 풀(102)을 포함한다. 시스템은, 하나 이상의 다른 서버 풀들에 접속될 수 있는 추가적인 서버 풀들을 포함할 수 있다. 일 실시예에서, 서버 풀들은 상호 접속되어 있는 상이한 도메인들에 호스팅될 수 있다. 예를 들어, 하나의 서버 풀은 "A.com"에 호스팅될 수 있고 제 2 서버 풀은 "B.org"에 호스팅될 수 있다. "A.com" 및 "B.org"는 제 2 레벨 도메인들로 특징지워지는 한편, ".com" 및 ".org"는 제 1 레벨 도메인들로 특징지워진다. 또한, 서버 풀들은, 각각 제 3 및 제 4 레벨 도메인들인, "X.A.com" 및 "N.Y.B.org"와 같은, 더 낮은-레벨의 도메인들에 의해 식별될 수도 있다.
시스템의 서버 풀들은 네트워크(108)에 결합될 수 있다. 네트워크는 인트라넷, 인터넷, 또는 다른 임의 유형의 네트워크일 수 있다. 또한, 네트워크는 하나 이상의 사용자 장치들(110)에 결합될 수도 있다. 이러한 사용자 장치들은 네트워크를 사용해 서버 풀과 메시지들을 교환할 수 있다.
도 2는 도 1의 서버 풀에 대한 일 실시예를 도시하는 블록도이다. 서버 풀(202)은 "전단 서버들"이라고도 하는 다수 서버들(204)을 포함한다. 서버들은 그들의 서버 풀의 도메인 이름에 관련된 머신 이름으로 식별될 수 있다. 예를 들어, server1이라 명명된 서버가 "X.A.com"이라 명명된 도메인을 가진 서버 풀의 멤버라면, 서버는 서버의 FQDN "server1.X.A.com"에 의해 식별될 수 있다. 서버들은 서로 결합되어 서버들의 네트워크를 형성할 수도 있다.
또한, 서버들은, 데이터베이스 서버(206)와 같은, 다른 네트워크 리소스들에도 결합될 수 있다. 일 실시예에서, 각각의 서버(204)는 자신만의 데이터베이스를 가진다. 다른 방법으로, 서버들은 데이터베이스 서버에 배치되어 있는 데이터베이스를 이용할 수도 있다. 데이터베이스는 서버와는 별개의 컴퓨팅 장치에 상주하거나 서버와 동일한 컴퓨팅 장치에 상주할 수 있다. 데이터베이스는 세션들에 관련된 정보를 저장하는데 사용될 수도 있다. 예를 들어, 데이터베이스는 서버가 핸들링 중인 각각의 세션에 대한 서버의 역할을 저장하는데 사용될 수도 있다.
또한, 서버들(204)은 부하 분산 장치(208;load balancer)에 결합될 수도 있 다. 세션 생성 요청이 부하 분산 장치에 도달할 때, 부하 분산 장치는, 예를 들어, 각 서버상의 부하에 기초하여, 서버 풀로부터 요청을 핸들링할 서버를 선택할 수 있다. 예를 들어, 서버 풀이 3개의 서버들을 가지며 하나의 서버는 유지 보수를 위해 다운되어 있는 상태이고 나머지 2개의 서버들 중 하나는 높은 프로세서 또는 네트워크 이용을 가진다면, 부하 분산 장치는 제 3 서버를 선택할 수 있다.
서버 풀은 프럭시 서버(210)에 결합될 수 있다. 프럭시 서버는, 예를 들어, 헤더들을 해석하거나 변경하는 것, 메시지들을 전송하는 것, 및 네트워크로부터 메시지들을 제거하는 것을 포함하여, 그것이 핸들링하는 메시지들에 대해 다양한 동작들을 취한다. 프럭시 서버는 다수의 네트워크 인터페이스들을 가질 수 있다. 하나의 인터페이스는 인터넷에 결합될 수 있고 또 다른 인터페이스는 서버 풀에 결합될 수 있다. 서버 풀이 프럭시 서버를 이용할 경우, 클라이언트들과 서버 풀간의 모든 트래픽은 프럭시 서버를 통과할 수 있다. 입력되는 요청 메시지들은 먼저, 요청 메시지들의 헤더 필드들에 나타나는 라우팅 정보를 평가하는 프럭시 서버에 의해 핸들링될 수 있다. 그 다음, 메시지들은, 시스템에 존재한다면, (나타내지 않은) ESC로 전송된 다음, (나타내지 않은) 다른 애플리케이션들로 전송될 수 있다. 이러한 컴포넌트들은 서버 풀의 서버에 의해 수행될 수 있다.
입력되는 응답 메시지들 또한 먼저, 라우팅 정보를 평가하기 위한 라우팅 서버에 의해 핸들링될 수 있다. 그 다음, 응답 메시지들은 (요청 메시지의 핸들링과 비교할 때, 역순으로) 애플리케이션들로 전송된 다음, 존재한다면, ESC로 전송될 수 있다. 그 다음, 프럭시 서버는 응답 메시지를 전송하기 전에 라우팅 정보를 업 데이트할 수 있다.
도 3은 요청 메시지의 헤더를 평가하기 위한 루틴의 일 실시예를 도시하는 흐름도이다. 루틴은 프럭시 서버에 의해 수행되며, 메시지를 파라미터로서 수신하는 블록 302에서 시작한다. 블록 304에서, 루틴은 메시지에서 지시된 Request-URI를 프로세싱한다. Request-URI는 요청 메시지의 수신자로서 식별되는 URI(unified resource identifier)이다. 예를 들어, 요청 메시지는 Request-URI에서 사용자 또는 장치를 식별할 수 있다. Request-URI는 "maddr" 파라미터를 가질 수 있다. maddr 파라미터는 URI와 관련되어 URI의 헤더 필드에 의해 지시되는 서버 어드레스가 아닌 서버 어드레스의 사용을 지시할 수 있다. 예를 들어, URI는 사용자 에이전트에 의해 사용되는 서버를 지시할 수 있는 한편, URI를 위한 maddr 파라미터는 사용자와 접촉하는데 사용할 프럭시 서버를 지시할 수 있다. 루틴은, Request-URI의 maddr 파라미터가, 프럭시 서버가 결합되어 있는 서버 풀의 FQDN 또는 프럭시 서버가 접속 요청들을 위해 청취하고 있는 IP 어드레스를 지시하는지의 여부를 체크하는 것에 의해, Request-URI를 프로세싱한다. 그런 경우라면, 루틴은 RFC 3261에 따라 maddr 파라미터를 제거한다. 그 다음, 루틴은, Request-URI가 프럭시 서버가 결합되어 있는 서버 풀의 FQDN을 지시하는지의 여부 및 Route 헤더 필드 또한 FQDN을 포함하는지의 여부를 체크한다. 그런 경우라면, 루틴은 Request-URI를 제 1 Route 헤더 필드화하고 마지막 Route 헤더 필드에 포함된 값을 Request-URI화한다.
블록 306에서, 루틴은 접속을 통해 도달된 메시지가 신뢰될 수 있는 것인지 의 여부를 판정한다. 예를 들어, 접속이 TLS(Transport Layer Security)를 사용하고 시스템이 메시지를 송신 중인 엔티티가 TLS 인증서를 가졌다는 것을 확인했거나 다른 방법으로 시스템의 관리자에 의해 접속이 신뢰할 수 있는 것으로 마킹된 경우라면, 접속은 신뢰될 수 있다. TLS는 장치들간의 전용 디지털 통신(private digital communications)을 가능하기 위해 인증서를 사용한다. 본 기술은, 예를 들어, Kerberos, Advanced Encryption Standard, 또는 Data Encryption Standard를 포함하여, 전용 통신을 가능하게 하기 위한 임의의 기술을 사용할 수 있다. 접속이 안전하다면, 루틴은 블록 310으로 진행한다. 그렇지 않으면, 루틴은 블록 308로 진행한다.
블록 308에서, 루틴은 일부의 헤더 필드들을 프로세싱하고 변경할 수 있다. 예를 들어, 루틴은 에지 프럭시(edge proxy)의 FDQN을 지시하는 Record-Route 헤더 필드들 및 헤더 필드들을 제거할 수 있다. 에지 프럭시는, 에지 프럭시의 인터넷 측상의 장치가 에지 프럭시만을 통해 인트라넷상의 장치들과 통신하도록, (예를 들어, "비무장 지대" 또는 "DMZ"의) 인트라넷 및 인터넷을 스트래들(straddle)하는 프럭시 서버이다. 시스템은 접속이 불안전할 때의 헤더 필드들에 대한 유효성을 신뢰하지 않기 때문에, 시스템은 이러한 헤더 필드들을 제거한다. 프럭시 서버가 헤더 필드들을 제거하지 않으면, 후속 서버들은 잘못하여 헤더들을 신뢰할 수 있다. 접속이 신뢰될 수 없을 경우, 프럭시 서버는 클라이언트들로부터의 직접적인 접속들을 기대하는데, 이 경우, 이러한 헤더 필드들은 존재할 수 없다. 클라이언트가 다른 프럭시를 통해 접속할 경우, 다른 프럭시는 TLS를 통해 자신을 확인할 수 있으므로(또는 안전한 접속의 다른 소정 지시를 가질 것이므로), 접속이 신뢰될 것이다. 헤더 필드들을 프로세싱하는 동안, 루틴은, Request-URI가 서명되었는지의 여부를 판정할 수도 있다. Request-URI가 서명되지 않았다면, 시스템은 상기한 바와 동일한 이유들로 인해 서버 역할들을 지시하는 파라미터들 또는 서버 풀의 특정 서버들에 대한 지시자들을 신뢰할 수 없고, 따라서, 이러한 파라미터들을 제거한다. 또한, 루틴은, 메시지에서 접촉을 위해 지시된 IP 어드레스가 메시지를 송신 중인 장치의 IP 어드레스와 동일한 IP 어드레스인지의 여부를 판정하는 것에 의해, Contact 헤더를 확인한다. 메시지의 Contact 헤더는, 메시지의 송신자가 요청들을 수신할 URI를 포함한다.
블록 310에서, 루틴은, 최고의 Route 헤더 필드가, 그 값이 최고의 Via 헤더 필드(the topmost Via header field)의 IP 어드레스와 매칭되는 "maddr" 파라미터를 갖는지의 여부를 판정한다. 헤더 필드가 maddr 파라미터를 갖지만 헤더 필드에서 지시된 IP 어드레스가 메시지를 송신 중인 엔티티의 IP 어드레스와 매칭되지 않으면, 루틴은 헤더 필드에서 식별된 FQDN에 관한 IP 어드레스 및 포트 파라미터들을 송신자의 IP 어드레스 및 포트로 대체한다. 또한, 루틴은 다이얼로그의 후속 메시지들이 정확한 접속을 통해 송신될 것이라는 것을 보장하기 위해 Received-CID URI 파라미터를 (예를 들어, 다이얼로그를 개시하는 INVITE 메시지에) 부가한다. Received-CID 파라미터는, 클라이언트가 이전에 참여하지 않았던 다이얼로그에 접속하는 것을 방지하는데 사용되는 고유한 숫자를 포함할 수 있다. 예를 들어, 클라이언트가 서버로부터 적절하게 차단하지 않아 새로운 클라이언트가 서버의 동일 한 포트에 접속한다면, 새로운 클라이언트는 다이얼로그를 계속할 수 있다. 그러나, 서버가 메시지에 Received-CID 파라미터를 부가하지 않을 것이기 때문에, 새로운 클라이언트는 정확한 Received-CID 파라미터를 소유하지 않을 것이다. 부정확한 Received-CID 파라미터는 서버에게, 새로운 클라이언트가 다이얼로그에 속하지 않는다는 지시가 될 것이다. 에지 프럭시의 FQDN(또는 네트워크 어드레스 변환기의 FQDN)이 헤더 필드에서 지시된다면, 루틴은 FQDN을 보존하고 헤더 필드가 메시지와 함께 서버 풀로 이동하는 것을 방지하기 위해 그 헤더 필드를 제거한다.
블록 312에서, 루틴은, 메시지가 수신된 접속이 연합 도메인(federated domain)을 사용하는지의 여부를 판정한다. 연합 도메인은 프럭시 서버가 동작하는 도메인 이외의 안전한 도메인이다. 루틴은, 루틴을 수행 중인 서버가 에지 프럭시일 경우에 접속이 연합 도메인을 사용하는지의 여부를 평가할 수 있다. 메시지가 연합 도메인으로부터 기인한다면, 루틴은 블록 314로 진행한다. 그렇지 않다면, 루틴은 블록 316으로 진행한다.
블록 314에서, 루틴은 메시지의 Route 헤더 필드들 및 Request-URI가 디지털 서명되었는지의 여부를 판정한다. 이러한 필드들이 유효한 서명으로 디지털 서명되었다면, 루틴은 블록 316으로 진행한다. 그렇지 않다면, 루틴은 Route 헤더 필드들이 존재하지 않는지의 여부 및 Request-URI가 디지털 서명되지 않았는지의 여부를 판정한다. 그렇다면, 루틴은 서버의 역할을 지시하는 헤더 필드들의 파라미터들을 제거하고 블록 316으로 진행한다. 그렇지 않다면, 루틴은 블록 322로 진행한다. 블록 322에서, 루틴은, 사용자 에이전트 서버가 기존 트랜잭션(예를 들어, 세션)과 매칭되지 않는 요청을 수신했다는 것을 지시하는, 응답 코드 481을 포함하는 응답을 리턴한다. 사용자 에이전트 클라이언트가 이러한 응답을 수신할 경우, 사용자 에이전트 클라이언트는 세션의 재확립을 시도하는 것으로 반응할 수 있다.
블록 316에서, 루틴은 Process_Header 서브루틴을 호출하고 블록 318에서 루틴은 Application_Routing 서브루틴을 호출한다. 이러한 서브루틴들은 각각 도 4 및 도 5와 관련하여 상세하게 후술된다. 루틴은 블록 320에서 루틴의 호출자에게 리턴한다.
도 4는 요청 메시지 헤더를 프로세싱하기 위해 프럭시 서버에 의해 수행되는 루틴의 일 실시예를 도시하는 흐름도이다. 루틴은, 메시지를 파라미터로서 수신하는 블록 402에서 시작한다. 블록 404에서, 루틴은 메시지에 Route 헤더 필드들이 존재하는지의 여부를 판정한다. Route 헤더 필드가 발견되면, 루틴은 블록 406으로 진행한다. 그렇지 않다면, 루틴은 블록 410으로 진행한다.
블록 406에서, 루틴은 최고 Route 헤더 필드의 FQDN이 서버가 속하는 서버 풀의 FQDN과 매칭되는지의 여부를 판정한다. FQDN이 매칭되면, 루틴은 블록 408로 진행한다. 그렇지 않다면, 루틴은 블록 420으로 진행한다. 블록 408에서, 루틴은 Route 헤더로부터 서버의 역할을 지시하는 파라미터들 및 메시지가 라우팅될 서버의 식별 정보를 추출한다.
블록 410에서, 루틴은 Request-URI로부터 서버의 역할 및 메시지가 라우팅될 서버의 식별 정보를 추출한다. 이러한 파라미터들은, 엔티티가 헤더를 프로세싱 중인 프럭시 서버가 수행할 역할을 판정했을 때, 그 엔티티에 의해 Request-URI에 부가되었을 수도 있다. 블록 412에서, 루틴은, 목적지 서버를 식별하는 파라미터가 루틴을 수행 중인 서버 이외의 서버를 지시하는지의 여부를 판정한다. 그렇다면, 루틴은 블록 414로 진행한다. 그렇지 않다면, 루틴은 블록 416으로 진행한다. 블록 414에서, 서버의 역할을 지시하는 파라미터가 추출되었다면, 그 역할은, 추가적인 프로세싱을 수행 중인 애플리케이션이, 예를 들어, 서버에 결합된 데이터베이스에서 역할에 관련된 정보를 검색할 수 있는 방식으로 저장된다. 블록 416에서, 루틴은, 루틴이 수행되고 있는 서버로 메시지를 송신한 엔티티에 의해 삽입된 것으로 보이도록, 최고의 Route 헤더를 복제한다. 블록 420에서, 루틴은, 요청을 수신한 사용자 에이전트 서버가 대응되는 트랜잭션(예를 들어, 세션)을 갖지 않는다는 것을 지시하는, 481의 응답 코드로 응답한다. 블록 418에서, 루틴은 자신의 호출자에게로 리턴한다.
도 5는 요청 메시지를 프로세싱하기 위해 시스템의 ESC에 의해 수행되는 루틴의 일 실시예를 도시하는 흐름도이다. ESC는, 애플리케이션에 의해 메시지들에 기초한 특별한 프로세싱을 수행하는데 사용될 수 있는 로직을 제공한다. 컴포넌트는, 그것이 "To" 서버인지 또는 "From" 서버인지의 여부에 기초하여 (예를 들어, 송신된 또는 수신된 메시지들에 관한 과금 정보 수집의) 프로세싱을 수행할 수 있다. "To" 서버는 원래 세션 생성 요청의 목적지에 대한 서버 풀에서의 서버이다. 반대로, "From" 서버는 원래 세션 생성 요청의 송신자에 대한 서버 풀에서의 서버이다. 서버가 "From" 서버인지 "To" 서버인지의 여부를 서버의 "역할(role)"이라고 한다.
루틴은, 서버가 NOTIFY 메시지를 생성할 경우에는 블록 548에서 또는 다른 여타 환경에서는 (예를 들어, 서버가 메시지를 소유할 경우에는) 블록 502에서 시작할 수 있다. 서버가 NOTIFY 메시지를 생성할 경우, 루틴은 블록 548에서 수행을 시작한다. 이런 경우, 서버의 역할은 암시적으로 "From"으로 설정될 수 있다. NOTIFY 메시지는 리소스의 상태를 지시하는 사용자 에이전트로부터 다른 것으로의 메시지이다. 블록 549에서, 루틴은 생성된 NOTIFY 메시지가 이미 Route 헤더들을 가지고 있는지의 여부를 판정한다. 서버는 데이터베이스로부터 Route 헤더들을 검색하여 생성된 NOTIFY 메시지에 Route 헤더들을 배치했을 수도 있다. NOTIFY 메시지가 이미 Route 헤더들을 가지고 있다면, 루틴은 블록 508로 진행한다. 그렇지 않다면, 루틴은 블록 528로 진행한다.
루틴은, 메시지를 파라미터로서 수신하는 블록 502에서 시작할 수 있다. 블록 504에서, 루틴은, 메시지가 인증을 위해 신뢰될 수 있는지의 여부를 판정한다. 메시지가 루틴을 수행 중인 서버와 동일한 도메인의 다른 서버로부터의 TLS 접속을 통해, 메시지가 신뢰될 수 있다고 지시하는 에지 프럭시로부터의 TLS 접속을 통해, 또는 관리자에 의해 신뢰될 수 있는 것으로 마킹된 접속으로 도달한다면, 메시지는 인증을 위해 신뢰될 수 있다. 상기한 바와 같이, 이 기술은, 전용 통신을 가능하게 하는 임의의 기술과 함께 사용될 수 있다. 메시지가 인증을 위해 신뢰될 수 있다면, 루틴은 블록 506으로 진행한다. 그렇지 않다면, 루틴은 블록 536으로 진행한다.
블록 506에서, 루틴은, 메시지에 Route 헤더들이 존재하는지의 여부를 판정 한다. 메시지의 Route 헤더 필드들의 존재는, 서버가 이미 메시지를 위한 후속 홉을 지시했거나 메시지가 이전 메시지들에 의해 이미 라우트(예를 들어, 홉들의 시퀀스)가 확립된 기존 세션의 일부이므로, 서버가 후속 홉을 판정할 필요가 없다는 것을 지시한다. 일 실시예에서, 서버는, 서버가 메시지의 헤더에서 지시된 URI를 책임지지 않는다는 것을 확인할 수도 있다. Route 헤더들이 존재한다면, 루틴은 블록 508로 진행한다. 그렇지 않다면, 루틴은 블록 512로 진행한다. 블록 508에서, 루틴은, 도 6과 관련하여 다음에서 부연되는 Other_Routing 서브루틴을 호출한다. 블록 510에서, 루틴은 루틴의 호출자에게로 리턴한다.
블록 512에서, 루틴은, (예를 들어, 프럭시 서버에 의해, 메시지를 핸들링 중인 이전의 서버에 의해, 세션의 이전 메시지를 라우팅하는 것에 의해) 역할 파라미터들이 사전에 보존되었는지의 여부를 판정한다. 이러한 파라미터가 사전에 보존되었을 경우, 이것이 루틴에게는 서버의 역할이 이미 판정되었다는 지시이다. 그런 경우라면, 루틴은 블록 514로 진행한다. 그렇지 않다면, 루틴은 블록 528로 진행한다.
블록 514에서, 루틴은 서버의 역할이 "To"인지의 여부를 판정한다. 그런 경우라면, 루틴은 블록 516으로 진행한다. 그렇지 않다면, 루틴은 블록 524로 진행한다. 블록 516에서, 루틴은 요청의 목적지가 "To" 서버 풀의 서버인지의 여부를 판정한다. 그렇다면, 루틴은 블록 518로 진행한다. 그렇지 않다면, 루틴은 블록 520으로 진행한다. 블록 518에서, 루틴은 요청을 프로세싱하며 응답을 송신할 수 있다.
블록 520에서, 루틴은, EPID(endpoint identifier)를 지시하는 파라미터가 메시지의 헤더 필드에 존재하는지의 여부를 판정한다. EPID는 사용자에 관련된 다수 로그인들(예를 들어, 데스크탑 컴퓨팅 장치로부터의 로그인 및 셀룰러 전화기로부터의 로그인)을 구별하는데 사용된다. EPID 파라미터의 존재는, 메시지들에 EPID 파라미터를 처음으로 부가한 것이 "To" 서버이기 때문에, "To" 서버 풀의 종점(end point)이 이미 선택되었다는 것을 지시하며, 이 파라미터는 후속 메시지들에 보존된다. EPID 파라미터가 존재한다면, 루틴은 블록 522로 진행한다. 그렇지 않다면, 루틴은 블록 508로 진행한다. 블록 522에서, 루틴은 후속 서버가 "To" 서버라는 것을 지시하는 Route 헤더들을 메시지에 삽입한다. 또한, 서버는, 메시지가 풀의 다른 서버로 라우팅되지 않는다면, 자신의 역할을 "To"로 설정할 수 있는데, 이 경우, 서버는 최고의 Route 헤더 필드에 서버 풀의 다른 서버를 포인팅하기 위한 파라미터를 부가할 것이다.
블록 524에서, 루틴은, 요청에 대한 목적지가 "From" 서버인지의 여부를 판정한다. 그렇다면, 루틴은 블록 518로 진행한다. 그렇지 않다면, 루틴은 블록 526으로 진행한다. 블록 526에서, 루틴은, 서버의 역할이 "From"이라는 지시를 보존한다. 블록 528에서, 루틴은, 서버가 "To" 서버 풀의 도메인에 속하는지를 판정한다. 그렇다면, 루틴은 블록 530으로 진행한다. 그렇지 않다면, 루틴은 블록 508로 진행한다.
블록 530에서, 루틴은 "To" 서버 풀의 FQDN을 검색한다. 블록 532에서, 루틴은, 루틴을 수행 중인 서버가 "To" 서버 풀의 멤버인지의 여부를 판정한다. 그 렇다면, 루틴은 블록 516으로 진행한다. 그렇지 않다면, 루틴은 블록 534로 진행한다. 블록 534에서, 루틴은 "To" 서버 풀의 FQDN을, 후속 서버가 "To" 서버라는 것을 지시하는 파라미터를 가진 메시지의 Request-URI에 부가한다. 그 결과, Request-URI가 프럭시 서버에 의해 후속적으로 프로세싱될 때, 메시지는 "To" 서버 풀의 서버로 송신될 것이다.
블록 536에서, 루틴은, 메시지가 인증되었는지의 여부를 판정한다. 메시지가 인증되었다면, 루틴은 블록 538로 진행한다. 그렇지 않다면, 루틴은 블록 546으로 진행한다. 블록 546에서, 루틴은 메시지를 조사할 것을 프럭시 서버에 요청한다.
블록 538에서, 루틴은, 메시지에 메시지가 기존 세션의 다이얼로그 일부라는 것을 지시하는 Route 헤더들이 존재하는지의 여부를 판정한다. 그렇다면, 루틴은 블록 508로 진행한다. 그렇지 않다면, 루틴은 블록 540으로 진행한다.
블록 540에서, 루틴은 "From" 서버 풀의 FQDN을 검색한다. 블록 542에서, 루틴은, 루틴을 수행 중인 서버가 "From" 서버 풀의 멤버인지의 여부를 판정한다. 그렇다면, 루틴은 블록 524로 진행한다. 그렇지 않다면, 루틴은 블록 544로 진행한다. 블록 544에서, 루틴은 "From" 서버 풀의 FQDN을, 후속 서버가 "From" 서버라는 것을 지시하는 파라미터를 가진 메시지 헤더들의 Request-URI에 부가한다. Request-URI가 프럭시에 의해 후속적으로 프로세싱될 때, 메시지는 "From" 서버 풀의 서버로 송신될 것이다.
도 6은 애플리케이션-관련 라우팅을 가능하게 하기 위해 요청 메시지 헤더를 프로세싱하는 루틴의 일 실시예를 도시하는 흐름도이다. 루틴은, 메시지를 파라미터로서 수신하는 블록 602에서 시작한다. 블록 604에서, 루틴은 헤더 필드들 및 관련 값들을 메시지에 삽입한다. 예를 들어, 루틴은 라우트 헤더들을 삽입할 것을 프럭시에 요청할 수 있다. 이런 경우, 프럭시 또한 서버의 역할을 설정할 수 있다. 루틴을 수행 중인 서버에서 실행 중인 애플리케이션들은 추가적인 Record-Route 헤더 필드들을 부가할 수 있다. 예를 들어, 기록 보존 애플리케이션(archiving application)은, 메시지가 기록 보존되었다는 것을 지시하기 위해, 메시지에 Record-Route 헤더 필드를 부가할 수 있다. 메시지를 다시 수신할 때(또는 메시지가 통과하는 다른 서버상에서 실행 중인 애플리케이션이 메시지를 수신할 때), 애플리케이션은, 이 필드가 이미 부가되었기 때문에, 메시지가 이미 기록 보존되었다는 것을 판정할 수 있다.
블록 606에서, 루틴은, 메시지에 대한 후속 홉이 메시지의 헤더로부터 판정될 수 있는지의 여부를 평가한다. 목적지를 지시하는 Route 헤더 필드가 존재한다면, 루틴은 Route 헤더로부터 후속 홉에 대한 FQDN 또는 IP 어드레스를 판정한다. 그렇지 않고, 서버 풀의 서버가 Request-URI에서 식별되고 메시지가 라우팅을 위해 신뢰될 수 있다면, 지시된 서버는 후속 홉으로서 사용된다. 그렇지 않고, Request-URI가 서버와 관련된 정적인 라우팅 테이블(static routing table)의 패턴과 매칭된다면, 정적인 라우팅 테이블로부터 후속 홉이 검색된다. 메시지가 안전한 접속으로 수신되거나 메시지의 Request-URI가 서버상에 설치된 애플리케이션에 의해 변경된 경우, 또는 라우팅 정보가 디지털 서명된 경우, 메시지는 라우팅을 위 해 신뢰될 수 있다. 메시지가 라우팅을 위해 신뢰된다면, 루틴은 메시지 헤더의 Request-URI에 대한 호스트 부분을 후속 홉으로서 식별한다. 후속 홉이 판정될 수 없다면, 루틴은 블록 620으로 진행한다. 그렇지 않다면, 블록 608에서, 루틴은 판정된 후속 홉의 FQDN 또는 IP 번호를 리졸브하고, 식별된 엔티티에 접속한다(또는 이미-개방된 접속을 사용한다).
블록 610에서, 루틴은, FQDN이 리졸브될 수 있는지 그리고 접속이 개방인지의 여부를 판정한다. 그렇다면, 루틴은 블록 612로 진행한다. 그렇지 않다면, 루틴은 블록 620으로 진행한다. 블록 612에서, 루틴은, 요청이 국소적으로 생성되었는지의 여부 및 Record-Route가 필요한지의 여부를 판정한다. 서버 역할 파라미터가 보존될 때 그리고 다른 일부 상황들에서, Record-Route가 에지 프럭시들, 전송 프럭시들상에 필요하다. NOTIFY, MESSAGE, INFO, 및 SERVICE 메시지 유형들과 같은, 다이얼로그를 개시하지 않는 메시지들에 대해서는 Record-Route가 불필요하다. 메시지가 국소적으로 생성되지 않았거나 Record-Route가 필요하다면, 루틴은 블록 614로 진행한다. 그렇지 않다면, 루틴은 블록 616으로 진행한다.
블록 614에서, 루틴은 메시지에 헤더 필드들 또는 파라미터들을 추가할 수 있다. 어떤 헤더들 및 파라미터들이 추가되는지는 메시지가 송신될 접속이 "일방(one-way)"으로 마킹되어 있는지의 여부에 의존할 수 있다. 관리자는, 예를 들어, 장치를 좀더 안전하게 하기 위해, 일방 접속들에 대해서만 장치를 인에이블할 수 있다(예를 들어, 장치는 다른 장치들로부터 접속 요청들을 수용할 수 없다). 접속이 "일방"으로 마킹될 경우, 루틴은 메시지의 Record-Route 헤더 필드에, 메시지의 수신자가 메시지를 리턴할 때의 세션을 위해 장치에 의해 확립된 접속을 사용할 수 있게 하는, 서버의 FQDN, 및 포트와 IP 어드레스 정보를 부가할 수 있다. 접속이 일방으로 마킹되지 않았고 루틴을 수행 중인 장치가 서버 풀의 서버라면, 루틴은 서버 풀의 FQDN을 서버(예를 들어, 서버만의 고유한 FQDN 또는 단순히 도메인에 관련된 서버 이름)를 식별하는 파라미터를 가진 Record-Route 헤더 필드에 부가한다. 후속 메시지가 세션의 시스템에 의해 수신될 때, 시스템은, 파라미터에 기초하여 후속 메시지를 라우팅할 서버를 판정할 수 있다. 접속이 일방으로 마킹되지 않았고 루틴을 수행 중인 장치가 서버 풀에 속하지 않는다면, 루틴은, 장치가 에지 프럭시인지 그리고 평가되고 있는 요청 메시지가 클라이언트 또는 전송 프럭시에 기인하는지의 여부를 판정한다. 그렇다면, 루틴은 접속이 일방으로 마킹된 경우에 부가된 것들과 유사한 헤더 필드들 및 파라미터들을 부가할 수 있으므로, 후속 메시지들이 동일한 에지 프럭시를 통해 라우팅된다. 그렇지 않다면, 루틴은 서버의 FQDN을 Record-Route 헤더 필드에 부가할 수 있다. 장치가 에지 프럭시라면, 장치는, 메시지가 전송될 장치에 의해 리졸브될 수 있는 FQDN(즉, 후속 서버가 인트라넷 내부에 있는지 아니면 외부에 있는지에 따라 인트라넷 내부에서 또는 외부에서 리졸브될 수 있는 FQDN)을 부가할 수 있다. 이러한 헤더 필드들을 부가한 후, 반대 파라미터(opposite parameter)가 사전에 저장되었다면, 루틴은 서버의 역할을 (예를 들어, From에서 To로, 또는 그 반대로) 반전하는 파라미터를 추가적으로 부가할 수 있다.
블록 616에서, 루틴은 메시지를 전송한다. 메시지를 전송하기 전에, 루틴 은, 메시지가 송신될 접속이 라우팅을 위해 신뢰될 수 있는지의 여부를 판정한다. 예를 들어, TLS(또는 전용 통신을 가능하게 하는 소정의 다른 메커니즘)를 사용하거나 관리자에 의해 신뢰될 수 있다고 명시적으로 지시된 접속들은 라우팅을 위해 신뢰될 수 있다. 접속이 라우팅을 위해 신뢰될 수 있고 프로세스가 에지 프럭시에 의해 수행되는 중이라면, 루틴은 접속이 연합 도메인을 이용하는지의 여부를 판정한다. 연합 도메인은 서버 도메인 이외의 신뢰되는 도메인이다. 접속이 신뢰되지 않거나 연합 도메인을 사용하지 않는다면, 루틴은 메시지에서의 임의의 Contact 및 Record-Route 헤더 필드들을 디지털 서명하고 서명들을 최고의 Record-Route 헤더 필드에 배치한다. Via 헤더들도 디지털 서명된다. 그 다음, 루틴은 메시지를 전송한다. 블록 618에서, 루틴은 자신의 호출자에게로 리턴한다. 블록 620에서, 루틴은, 서버가 요청의 프로세싱을 시도했을 때 시기적절한 응답을 수신하지 않았다는 것을 지시하는, 504 응답 코드로 응답한다.
도 7은 응답 메시지를 프로세싱하는 루틴의 일 실시예를 도시하는 흐름도이다. 루틴은, 응답 메시지를 파라미터로서 수신하는 블록 702에서 시작한다. 블록 706에서, 루틴은, 메시지가 하나 이상의 Via 헤더 필드를 포함하는지의 여부를 판정한다. 메시지가 하나 이상의 Via 메시지 필드를 포함하면, 그것은, 응답이 다른 서버로 전송될 필요가 있을 수도 있다는 지시이다. 그렇다면, 루틴은 블록 708로 진행한다. 그렇지 않다면, 루틴은 응답을 국소적으로 소비하고 블록 716으로 진행한다.
블록 708에서, 루틴은, 메시지가 수신된 접속이 라우팅을 위해 신뢰될 수 있 는지의 여부를 판정한다. 접속이 신뢰될 수 있는 루틴에 대한 환경들은, 예를 들어, 도 6과 관련하여, 상술되었다. 접속이 라우팅을 위해 신뢰될 수 있다면, 루틴은 헤더 필드가 이러한 값을 지시할 때 에지 프럭시의 FQDN을 보존하고 헤더 필드를 누락한다. 그렇지 않다면, 루틴은, 이러한 필드들이 서버가 접속되어 있는 엔티티(또는 프럭시)와 동일한 IP 어드레스를 지시하는지를 평가하고 루틴을 수행 중인 서버와의 세션을 가진 다른 클라이언트가 동일한 IP 어드레스 및 포트를 사용하지 않는다는 것을 보장하려는 의도에서 Received-CID URI 파라미터를 부가하는 것에 의해, 응답 메시지의 Contact 헤더 필드들을 프로세싱한다. 접속이 라우팅을 위해 신뢰될 수 있고 라우팅이 에지 프럭시에 의해 수행되는 중이라면, 루틴은, 접속이 연합 도메인에 대한 것인지의 여부를 판정한다. 접속이 연합 도메인에 대한 것이라면, 또는 Contact 헤더 필드들을 프로세싱한 후에, 루틴은 메시지의 라우팅 정보가 Record-Route 및 Via 헤더 필드들의 서명과 매칭되는지를 확인한다. 접속이 연합 도메인으로부터 기인하지 않았거나 라우팅 서명들이 확인되면, 루틴은 애플리케이션들 및 기업 서비스들이 응답을 프로세싱할 수 있게 한다. (예를 들어, 헤더들이 적절하게 디지털 서명되지 않았기 때문에) 라우팅 서명들이 확인되지 않았다면, 루틴은 응답을 취소한다. 루틴은, 응답의 헤더 필드들을 분석하는 것에 의해, 이러한 루틴을 수행 중인 서버가 이전 요청에 Record-Route 헤더 필드를 삽입했는지의 여부를 판정한다. 그렇다면, 루틴은 블록 710으로 진행한다. 그렇지 않다면, 루틴은 블록 712로 진행한다.
블록 710에서, 루틴은 Record-Route 헤더 필드들을 프로세싱한다. 루틴은, 응답에 Contact 헤더가 존재하지 않는다면 루틴을 수행 중인 서버를 지시하는, 존재한다면, Record-Route 헤더 필드들을 제거한다. 또한, 루틴은, 현재의 응답을 초래한 이전 요청을 프로세싱할 때 루틴이 또는 다른 프럭시가 삽입했을 수도 있는 다른 관련 헤더 필드들도 제거할 수 있다. 또한, 루틴은, 이전 요청의 송신자가 후속 요청을 송신할 때 역할이 식별되거나 사용될 수 있도록 하기 위해, 서버의 역할을 지시하는 파라미터들을 헤더들에 부가(또는 삭제된 파라미터들의 값들을 사용)할 수도 있다. 루틴은, 관리자가 접속을 일방으로서 마킹했는지의 여부를 체크한다. 일방 접속은, 네트워크의 다른 장치들이 서버의 FQDN을 리졸브하거나 서버로의 역접속을 확립할 수 없다는 지시이다. 예를 들어, 관리자는 서버를, 출력되는 접속들은 가능하지만 입력되는 접속들은 불가능한, 방화벽화하고자 할 수 있다. 접속이 일방으로 마킹되면, 루틴은 서버의 FQDN, IP 어드레스, 및 포트 정보를 응답의 Record-Route 헤더 필드에 부가할 수 있다. 루틴은 또한 이전 홉의 Via 헤더 필드로부터의 전송점 파라미터(forward-point parameter)를 사용해 네트워크 어드레스 변환기들(network address translators)을 통과하는 것에 관한 문제들을 핸들링할 수 있다.
접속이 일방으로 마킹되지 않았고 루틴을 수행 중인 장치가 서버 풀의 서버라면, 루틴은 서버 풀의 FQDN을 서버의 FQDN을 지시하는 파라미터를 가진 Record-Route 헤더 필드에 부가한다. 후속 메시지가 세션의 시스템에 의해 수신될 때, 시스템은 파라미터에 기초하여 후속 메시지가 라우팅될 서버를 판정할 수 있다. 접속이 일방으로 마킹되지 않았고 루틴을 수행 중인 장치가 서버 풀에 속하지 않는다 면, 루틴은, 장치가 에지 프럭시인지 그리고 평가되고 있는 요청 메시지가 클라이언트 또는 전송 프럭시에서 기인했는지의 여부를 판정한다. 그렇다면, 루틴은, 접속이 일방으로 마킹되었을 때 부가된 것들과 유사한 헤더 필드들 및 파라미터들을 부가할 수 있으므로, 후속 메시지들은 동일한 에지 프럭시를 통해 라우팅된다. 그렇지 않다면, 루틴은 서버의 FQDN을 Record-Route 헤더 필드에 부가할 수 있다. 장치가 에지 프럭시라면, 장치는 메시지가 전송될 장치에 의해 리졸브될 수 있는 FQDN을 부가할 수 있다. 이러한 헤더 필드들을 부가한 후, 반대 파라미터가 사전에 저장되었다면, 루틴은 추가적으로 서버의 역할을 (예를 들어, From에서 To로 또는 그 반대로) 반전하는 파라미터를 부가할 수 있다.
블록 712에서, 루틴은 최고의 Via 헤더 필드를 제거한다. 블록 714에서, 루틴은 응답을 전송한다. 출력되는 접속이 (예를 들어, 전용 통신을 가능하게 하는 TLS 또는 다른 소정 메커니즘을 사용하거나 관리자에 의해 신뢰되는 것으로 지시되었기 때문에) 라우팅을 위해 신뢰될 수 있다면, 루틴은 접속이 연합 도메인에 대한 것인지의 여부를 판정한다. 접속이 연합 도메인에 대한 것이라면, 루틴은 Record-Route 및 Contact 정보를 포함하는 헤더 필드들을 디지털 서명한다. 또한, 출력되는 접속이 라우팅을 위해 신뢰될 수 없다면, 루틴은 이러한 헤더 필드들을 서명한다. 다음으로, 루틴은 응답을 응답 라우트의 후속 엔티티로 전송한다. 블록 716에서, 루틴은 그것의 호출자에게로 리턴한다.
메시지들을 효율적으로 라우팅하는 시스템이 구현되는 컴퓨팅 장치는 CPU, 메모리, 입력 장치들(예를 들어, 키보드 및 포인팅 장치들), 출력 장치들(예를 들 어, 디스플레이 장치들), 및 저장 장치들(예를 들어, 디스크 드라이브들)을 포함할 수 있다. 메모리 및 저장 장치들은, 보안 시스템을 구현하는 명령어들을 포함할 수 있는 컴퓨터-판독 가능 매체들이다. 또한, 데이터 구조들 및 메시지 구조들은, 통신 링크상의 신호와 같은, 데이터 전송 매체를 통해 저장되거나 전송될 수 있다. 인터넷, LAN, WAN, 또는 점-대-점 다이얼-업 접속(point-to-point dial-up connenction)과 같은, 다양한 통신 링크들이 사용될 수 있다.
도 1 및 도 2는, 보안이 구현될 수 있는 적당한 동작 환경의 일례를 도시한다. 동작 환경은 적당한 동작 환경의 일례일 뿐이며 확장 가능한 무선 프레임워크의 사용 또는 기능 범위를 제한하려는 것은 아니다. 사용하기에 적합할 수 있는 공지의 다른 컴퓨팅 시스템들, 환경들, 및 구성들로는 퍼스널 컴퓨터들, 서버 컴퓨터들, 핸드-헬드 또는 랩탑 장치들, 멀티프로세서 시스템들, 마이크로프로세서-기반 시스템들, 프로그램 가능한 사용 전자 장치들, 네트워크 PC들, 미니컴퓨터들, 메인프레임 컴퓨터들, 상기 시스템들 또는 장치들 중 어떤 것을 포함하는 분산 컴퓨팅 환경들 등을 들 수 있다.
보안 시스템은 하나 이상의 컴퓨터들 또는 다른 장치들에 의해 실행되는, 프로그램 모듈들과 같은, 컴퓨터-실행 가능 명령어들의 일반적인 맥락에서 설명될 수 있다. 일반적으로, 프로그램 모듈들은, 특정한 태스크들을 수행하거나 특정한 추상적 데이터형들을 구현하는, 루틴들, 프로그램들, 오브젝트들, 컴포넌트들, 데이터 구조들 등을 포함한다. 통상적으로, 프로그램 모듈들의 기능은 다양한 실시예들에서의 필요에 따라 조합되거나 분산될 수 있다.
상기한 바로부터, 여기에서는 본 발명의 특정 실시예들이 예시를 위해 설명되었지만, 본 발명의 정신 및 범위를 벗어나지 않으면서, 다양한 변경들이 이루어질 수 있다는 것을 알 수 있을 것이다. 따라서, 본 발명은 첨부된 청구항들에 의해서만 한정될 뿐이다.
따라서, 본 발명에 따르면, 서버들의 풀을 사용해 메시지들을 효율적으로 라우팅하는 접근 방법들이 제공된다. 일 실시예에서, 본 시스템은, 서버 풀이 각각 고유한 이름을 가진 다수 서버들을 포함하는 경우라 하더라도, 클라이언트들이 서버 풀에 대한 도메인 이름을 특정할 수 있게 하는 것에 의해, 서버들의 높은 이용 가능성을 보장할 수 있다. 클라이언트가 서버 풀의 도메인 이름을 사용하여 세션을 개시할 때, 본 시스템은 상이한 이름을 가진 이용 가능한 서버를 선택할 수 있고, 선택된 서버로의 세션 동안 요청 및 후속 메시지들을 라우팅한다. 본 시스템은 풀로부터 최저 부하를 가진 서버를 선택할 수도 있다. 또한, 본 시스템은, 세션의 후속 메시지들이 통과할 서버들을 지시할 수도 있다. 그 다음, 후속 메시지들은 지시된 서버들로 라우팅되어, 지시된 서버들상의 애플리케이션 서비스들이 메시지들 및 메시지들의 다이렉션에 기초하여 동작들을 취하게 할 수 있다.

Claims (40)

  1. 복수의 전단 서버(front end server)를 포함하는 서버 풀(server pool) 중 하나의 전단 서버로 메시지들을 효율적으로 라우팅(routing)하기 위한, 컴퓨터 시스템에 의해 수행되는 방법으로서,
    클라이언트 컴퓨팅 장치로부터 다이얼로그(dialog)를 개방(open)할 것을 표시(indicate)하는 메시지를 수신하는 단계 - 상기 메시지는 상기 서버 풀을 식별하는 도메인 이름으로 송신됨 -;
    상기 서버 풀 중 하나의 전단 서버를 선택하는 단계 - 상기 전단 서버는 서버 도메인 이름을 가짐 -;
    상기 선택된 전단 서버의 서버 도메인 이름에 대한 표시를 부가하도록 상기 메시지의 헤더 필드를 변경하여, 상기 다이얼로그의 후속 메시지들이 상기 표시에 기초하여 상기 선택된 전단 서버로 송신될 수 있도록 하는 단계; 및
    상기 클라이언트 컴퓨팅 장치와 상기 선택된 전단 서버 간에 상기 다이얼로그를 개방하도록, 상기 변경된 메시지를 상기 선택된 전단 서버로 전달하는 단계
    를 포함하는 방법.
  2. 제1항에 있어서,
    상기 클라이언트 컴퓨팅 장치로부터 상기 다이얼로그의 후속 메시지들을 수신하는 단계;
    상기 후속 메시지들의 헤더 필드에 포함되어 있는 상기 서버 도메인 이름에 대한 표시로부터 상기 선택된 전단 서버를 검출하는 단계; 및
    상기 후속 메시지들에 포함되어 있는 상기 서버 도메인 이름에 대한 표시에 기초하여 상기 후속 메시지들을 상기 선택된 전단 서버로 전달하는 단계를 포함하는 방법.
  3. 제1항에 있어서,
    상기 다이얼로그의 후속 메시지들은, 상기 서버 풀의 다른 컴퓨팅 장치에 의해 전달되지 않고, 상기 클라이언트 컴퓨팅 장치와 상기 선택된 전단 서버 간에서 교환되는 방법.
  4. 제1항에 있어서,
    상기 선택된 전단 서버에 대한 역할을 표시하는 헤더 필드 값을 부가하는 단계를 포함하는 방법.
  5. 제1항에 있어서,
    상기 서버 풀의 상기 선택된 전단 서버가 이용 불가능할 때, 상기 서버 풀 중 다른 전단 서버를 선택하는 단계를 포함하는 방법.
  6. 제1항에 있어서,
    상기 선택하는 단계는 서버 부하를 판정하는 단계를 포함하는 방법.
  7. 제1항에 있어서,
    상기 후속 메시지들은 동일한 세트(identical set)의 네트워크 장치들을 통과(traverse)하는 방법.
  8. 복수의 전단 서버를 포함하는 서버 풀 중 하나의 전단 서버로 메시지들을 효율적으로 라우팅하기 위한 시스템으로서,
    클라이언트 컴퓨팅 장치로부터 다이얼로그를 개방할 것을 표시하는 메시지를 수신하는 컴포넌트 - 상기 메시지는 상기 서버 풀을 식별하는 도메인 이름으로 송신됨 -;
    상기 서버 풀 중 하나의 전단 서버를 선택하는 컴포넌트 - 상기 전단 서버는 식별자(identifier)를 가짐 -; 및
    상기 선택된 전단 서버의 식별자에 대한 표시를 상기 메시지의 헤더 필드에 부가함으로써 상기 메시지를 변경하는 컴포넌트
    를 포함하는, 라우팅 시스템.
  9. 제8항에 있어서,
    상기 클라이언트 컴퓨팅 장치와 상기 선택된 전단 서버 간에 상기 다이얼로그를 개방하도록 상기 변경된 메시지를 상기 선택된 전단 서버로 전달하는 컴포넌트를 포함하는, 라우팅 시스템.
  10. 제8항에 있어서,
    상기 클라이언트 컴퓨팅 장치로부터 후속 메시지들을 수신하고 각각의 상기 후속 메시지를 상기 후속 메시지의 헤더 필드에서 표시된 상기 선택된 전단 서버로 전달하는 컴포넌트를 포함하는, 라우팅 시스템.
  11. 클라이언트 컴퓨팅 장치로부터 다이얼로그를 개방할 것을 표시하는 메시지를 수신하는 단계 - 상기 메시지는 서버 풀을 식별하는 도메인 이름을 표시함 -;
    상기 서버 풀 중 하나의 전단 서버를 선택하는 단계 - 상기 전단 서버는 식별자를 가짐 -;
    상기 선택된 전단 서버의 식별자에 대한 표시를 부가하도록 상기 메시지의 헤더 필드를 변경하여, 상기 다이얼로그의 후속 메시지들이 상기 식별자에 기초하여 상기 선택된 전단 서버로 송신될 수 있도록 하는 단계; 및
    상기 클라이언트 컴퓨팅 장치와 상기 선택된 전단 서버 간에 상기 다이얼로그를 개방하도록 상기 변경된 메시지를 상기 선택된 전단 서버로 전달하는 단계
    를 포함하는 방법을 컴퓨팅 시스템으로 하여금 수행하게 하는 컴퓨터 판독가능 명령어들이 기록된, 컴퓨터-판독 가능 기록매체.
  12. 제11항에 있어서,
    상기 방법은,
    상기 클라이언트 컴퓨팅 장치로부터 상기 다이얼로그의 후속 메시지들을 수신하는 단계;
    상기 후속 메시지들의 헤더 필드에 포함되어 있는 상기 선택된 전단 서버의 식별자로부터 상기 선택된 전단 서버를 검출하는 단계; 및
    상기 후속 메시지들의 헤더 필드에 포함되어 있는 상기 선택된 전단 서버의 식별자에 기초하여 상기 선택된 전단 서버로 상기 후속 메시지들을 전달하는 단계를 포함하는, 컴퓨터-판독 가능 기록매체.
  13. 제11항에 있어서,
    상기 다이얼로그의 후속 메시지들은, 상기 서버 풀의 다른 컴퓨팅 장치에 의해 전달되지 않고, 상기 클라이언트 컴퓨팅 장치와 상기 선택된 전단 서버 간에 교환되는, 컴퓨터-판독 가능 기록매체.
  14. 서버 풀 중의 하나의 전단 서버를 표시하기 위한 컴퓨터-판독 가능 기록매체로서,
    서버 풀을 식별하는 헤더 필드를 포함하는 메시지; 및
    상기 전단 서버를 표시하는 상기 헤더 필드에 대한 파라미터가 기록된, 컴퓨터-판독 가능 기록매체.
  15. 제14항에 있어서,
    상기 전단 서버에 대한 역할의 표시가 기록된, 컴퓨터-판독 가능 기록매체.
  16. 삭제
  17. 삭제
  18. 삭제
  19. 삭제
  20. 삭제
  21. 삭제
  22. 삭제
  23. 삭제
  24. 삭제
  25. 삭제
  26. 삭제
  27. 삭제
  28. 삭제
  29. 삭제
  30. 삭제
  31. 삭제
  32. 삭제
  33. 삭제
  34. 삭제
  35. 삭제
  36. 삭제
  37. 삭제
  38. 삭제
  39. 삭제
  40. 삭제
KR1020050042306A 2004-05-21 2005-05-20 서버 풀들을 이용할 때의 효율적인 메시지 라우팅 KR101120695B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US10/851,003 2004-05-21
US10/851,003 US8024476B2 (en) 2004-05-21 2004-05-21 Efficient message routing when using server pools

Publications (2)

Publication Number Publication Date
KR20060048035A KR20060048035A (ko) 2006-05-18
KR101120695B1 true KR101120695B1 (ko) 2012-03-23

Family

ID=34939686

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020050042306A KR101120695B1 (ko) 2004-05-21 2005-05-20 서버 풀들을 이용할 때의 효율적인 메시지 라우팅

Country Status (5)

Country Link
US (1) US8024476B2 (ko)
EP (1) EP1599015A1 (ko)
JP (1) JP2005339550A (ko)
KR (1) KR101120695B1 (ko)
CN (1) CN1700680B (ko)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7535905B2 (en) * 2004-03-31 2009-05-19 Microsoft Corporation Signing and validating session initiation protocol routing headers
US8024476B2 (en) 2004-05-21 2011-09-20 Microsoft Corporation Efficient message routing when using server pools
US7506369B2 (en) * 2004-05-27 2009-03-17 Microsoft Corporation Secure federation of data communications networks
US20060048163A1 (en) * 2004-08-27 2006-03-02 Thierry Bessis Method for routing messages between servers located on the same board
US20060083242A1 (en) * 2004-10-20 2006-04-20 Nokia Corporation Address modification in application servers
US8583827B2 (en) * 2005-05-26 2013-11-12 Citrix Systems, Inc. Dynamic data optimization in data network
US20070055784A1 (en) * 2005-09-08 2007-03-08 Pancholi Ketan P Method to reduce the learning curve of a transmission control protocol connection
US8943181B2 (en) 2005-11-29 2015-01-27 Ebay Inc. Method and system for reducing connections to a database
WO2008048304A2 (en) 2005-12-01 2008-04-24 Firestar Software, Inc. System and method for exchanging information among exchange applications
US9953097B2 (en) * 2006-03-16 2018-04-24 Ebay Inc. System and method for managing network traffic routing
JP4632450B2 (ja) 2006-04-17 2011-02-16 キヤノン株式会社 通信装置及びその制御方法
FR2902590B1 (fr) * 2006-06-16 2008-08-01 Alcatel Sa Detection de boucles au sein d'un element intermediaire de signalisation sip
JP4910542B2 (ja) * 2006-07-27 2012-04-04 富士通株式会社 Ｓｉｐメッセージ引渡プログラム
US7761538B2 (en) * 2006-08-30 2010-07-20 Microsoft Corporation Dynamically configuring, allocating and deploying computing systems
FR2906668A1 (fr) * 2006-10-02 2008-04-04 Alcatel Sa Marqueur pour systemes de communication composes d'une pluralite de serveurs sip.
US7664108B2 (en) * 2006-10-10 2010-02-16 Abdullah Ali Bahattab Route once and cross-connect many
JP4470934B2 (ja) 2006-10-20 2010-06-02 日本電気株式会社 プロキシ・サーバ、通信システム、通信方法及びプログラム
CN101170538B (zh) 2006-10-24 2013-01-16 国际商业机器公司 用于改善sip解析性能的方法和装置
US8929360B2 (en) 2006-12-07 2015-01-06 Cisco Technology, Inc. Systems, methods, media, and means for hiding network topology
CN101242392B (zh) * 2007-02-06 2012-02-08 国际商业机器公司 用于系列服务消息处理的方法、设备和系统
US8713186B2 (en) * 2007-03-13 2014-04-29 Oracle International Corporation Server-side connection resource pooling
WO2009036184A2 (en) 2007-09-11 2009-03-19 Research In Motion Limited System and method for sharing a sip communication service identifier
US20090185673A1 (en) * 2008-01-17 2009-07-23 Avaya Technology Llc Voice-Over-IP Call Recording in Call Centers
JPWO2010106772A1 (ja) 2009-03-17 2012-09-20 日本電気株式会社 分散処理システム及び分散処理方法
US9160610B1 (en) * 2009-03-31 2015-10-13 Symantec Corporation Method and apparatus for coordinating service execution within a shared file system environment to optimize cluster performance
US9378503B2 (en) * 2010-06-30 2016-06-28 Alcatel Lucent Methods of routing for networks with feedback
US9385935B2 (en) * 2013-03-06 2016-07-05 Microsoft Technology Licensing, Llc Transparent message modification for diagnostics or testing
US20150172324A1 (en) * 2013-12-13 2015-06-18 Alcatel-Lucent Usa Inc. Authorized SIP Redirection
CN105338480B (zh) * 2014-06-24 2020-01-24 创新先进技术有限公司 基于lbs的用户匹配方法、消息客户端、服务器及系统
US9612889B2 (en) * 2015-02-27 2017-04-04 Wal-Mart Stores, Inc. Integrating applications
US10826868B2 (en) * 2016-03-29 2020-11-03 T-Mobile Usa, Inc. NAT aware DNS
WO2020091736A1 (en) 2018-10-30 2020-05-07 Hewlett Packard Enterprise Development Lp Software defined wide area network uplink selection for a cloud service
NL2022642B1 (en) * 2019-02-26 2020-09-01 Machsol Holding B V A system for connecting a user to a cloud service and a method for setting up the system
US11792071B1 (en) * 2021-12-17 2023-10-17 Juniper Networks, Inc. Intent-based user authentication for dynamic applications

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11250020A (ja) 1998-03-04 1999-09-17 Fujitsu Ltd 負荷分散システム、セション管理システム、クライアント装置、負荷分散プログラムを記録したコンピュータ読み取り可能な記録媒体、セション管理プログラムを記録したコンピュータ読み取り可能な記録媒体及びローカル代理サーバプログラムを記録したコンピュータ読み取り可能な記録媒体

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6317775B1 (en) * 1995-11-03 2001-11-13 Cisco Technology, Inc. System for distributing load over multiple servers at an internet site
US5774660A (en) * 1996-08-05 1998-06-30 Resonate, Inc. World-wide-web server with delayed resource-binding for resource-based load balancing on a distributed resource multi-node network
US6275937B1 (en) 1997-11-06 2001-08-14 International Business Machines Corporation Collaborative server processing of content and meta-information with application to virus checking in a server network
US6389532B1 (en) 1998-04-20 2002-05-14 Sun Microsystems, Inc. Method and apparatus for using digital signatures to filter packets in a network
US6567915B1 (en) 1998-10-23 2003-05-20 Microsoft Corporation Integrated circuit card with identity authentication table and authorization tables defining access rights based on Boolean expressions of authenticated identities
NO308019B1 (no) 1998-11-27 2000-07-03 Ericsson Telefon Ab L M FremgangsmÕte for Õ utvide bruken av SIP (Session Initiation Protocol)
US6553422B1 (en) 1999-04-26 2003-04-22 Hewlett-Packard Development Co., L.P. Reverse HTTP connections for device management outside a firewall
US6584567B1 (en) 1999-06-30 2003-06-24 International Business Machines Corporation Dynamic connection to multiple origin servers in a transcoding proxy
US8743892B2 (en) 1999-11-08 2014-06-03 Verizon Business Global Llc Method and system for dynamic gateway selection in an IP telephony network
US6434143B1 (en) 1999-11-08 2002-08-13 Mci Worldcom, Inc. Internet protocol telephony voice/video message deposit and retrieval
US6477150B1 (en) * 2000-03-03 2002-11-05 Qualcomm, Inc. System and method for providing group communication services in an existing communication system
US6976090B2 (en) * 2000-04-20 2005-12-13 Actona Technologies Ltd. Differentiated content and application delivery via internet
US6865681B2 (en) 2000-12-29 2005-03-08 Nokia Mobile Phones Ltd. VoIP terminal security module, SIP stack with security manager, system and security methods
US7284271B2 (en) 2001-03-14 2007-10-16 Microsoft Corporation Authorizing a requesting entity to operate upon data structures
US6985958B2 (en) 2001-03-14 2006-01-10 Microsoft Corporation Messaging infrastructure for identity-centric data access
US20020141404A1 (en) 2001-04-03 2002-10-03 Michael Wengrovitz Call routing using information in session initiation protocol messages
US7676430B2 (en) 2001-05-09 2010-03-09 Lenovo (Singapore) Ptd. Ltd. System and method for installing a remote credit card authorization on a system with a TCPA complaint chipset
US20020178240A1 (en) 2001-05-24 2002-11-28 International Business Machines Corporation System and method for selectively confirming digital certificates in a virtual private network
US7243370B2 (en) 2001-06-14 2007-07-10 Microsoft Corporation Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication
US7010727B1 (en) 2001-06-15 2006-03-07 Nortel Networks Limited Method and system for negotiating compression techniques to be utilized in packet data communications
US20030009570A1 (en) 2001-07-03 2003-01-09 International Business Machines Corporation Method and apparatus for segmented peer-to-peer computing
US20030084331A1 (en) 2001-10-26 2003-05-01 Microsoft Corporation Method for providing user authentication/authorization and distributed firewall utilizing same
US7343490B2 (en) 2001-11-30 2008-03-11 Nokia Siemens Networks Oy Apparatus, and associated method, for facilitating authentication of a mobile station with a core network
EP1452000A2 (en) 2001-12-07 2004-09-01 Telefonaktiebolaget LM Ericsson (publ) Lawful interception of end-to-end encrypted data traffic
JP3811057B2 (ja) * 2001-12-10 2006-08-16 富士通株式会社 中継コネクション管理プログラムおよび中継コネクション管理方法
KR100426306B1 (ko) * 2001-12-11 2004-04-08 한국전자통신연구원 인트라 도메인내에서의 ｓｉｐ 서버간 로드 분산 처리 방법
US7085829B2 (en) * 2001-12-31 2006-08-01 Innomedia, Pte Ltd. Method and system for an intelligent proxy server for workload balancing by workload shifting
US7509425B1 (en) 2002-01-15 2009-03-24 Dynamicsoft, Inc. Establishing and modifying network signaling protocols
US7240366B2 (en) 2002-05-17 2007-07-03 Microsoft Corporation End-to-end authentication of session initiation protocol messages using certificates
US7774473B2 (en) * 2002-07-31 2010-08-10 Oracle America, Inc. System and method for sticky routing of requests within a server farm
US20040043756A1 (en) 2002-09-03 2004-03-04 Tao Haukka Method and system for authentication in IP multimedia core network system (IMS)
WO2004023263A2 (en) 2002-09-09 2004-03-18 Netrake Corporation System for allowing network traffic through firewalls
KR100472952B1 (ko) 2002-10-30 2005-03-10 한국전자통신연구원 세션 초기화 프로토콜（ｓｉｐ）기반의 부하 분산장치 및방법
JP4338993B2 (ja) 2003-02-28 2009-10-07 モトローラ・インコーポレイテッド 無線端末のセッション制御方法及びインターフェース設定方法
US7412521B2 (en) 2003-03-12 2008-08-12 Microsoft Corporation End-point identifiers in SIP
US7949785B2 (en) * 2003-03-31 2011-05-24 Inpro Network Facility, Llc Secure virtual community network system
US7421732B2 (en) 2003-05-05 2008-09-02 Nokia Corporation System, apparatus, and method for providing generic internet protocol authentication
US6963635B1 (en) 2003-05-06 2005-11-08 Sprint Spectrum L.P. Method and system for facilitating collection of subscriber past due balance
JP2004364141A (ja) 2003-06-06 2004-12-24 Hitachi Communication Technologies Ltd Ｉｐアドレス変換装置およびパケット転送装置
US20040260752A1 (en) * 2003-06-19 2004-12-23 Cisco Technology, Inc. Methods and apparatus for optimizing resource management in CDMA2000 wireless IP networks
JP4115354B2 (ja) * 2003-07-04 2008-07-09 富士フイルム株式会社 ピア・ツー・ピア通信システム
US7257837B2 (en) * 2003-07-26 2007-08-14 Innomedia Pte Firewall penetration system and method for real time media communications
US7142537B2 (en) 2003-12-18 2006-11-28 Motorola, Inc. Interface call signaling protocol
US7535905B2 (en) 2004-03-31 2009-05-19 Microsoft Corporation Signing and validating session initiation protocol routing headers
US8024476B2 (en) 2004-05-21 2011-09-20 Microsoft Corporation Efficient message routing when using server pools
FR2902590B1 (fr) 2006-06-16 2008-08-01 Alcatel Sa Detection de boucles au sein d'un element intermediaire de signalisation sip

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11250020A (ja) 1998-03-04 1999-09-17 Fujitsu Ltd 負荷分散システム、セション管理システム、クライアント装置、負荷分散プログラムを記録したコンピュータ読み取り可能な記録媒体、セション管理プログラムを記録したコンピュータ読み取り可能な記録媒体及びローカル代理サーバプログラムを記録したコンピュータ読み取り可能な記録媒体

Also Published As

Publication number Publication date
US20060031536A1 (en) 2006-02-09
CN1700680A (zh) 2005-11-23
JP2005339550A (ja) 2005-12-08
KR20060048035A (ko) 2006-05-18
EP1599015A1 (en) 2005-11-23
CN1700680B (zh) 2012-03-14
US8024476B2 (en) 2011-09-20

Similar Documents

Publication Publication Date Title
KR101120695B1 (ko) 서버 풀들을 이용할 때의 효율적인 메시지 라우팅
US7412521B2 (en) End-point identifiers in SIP
US8095681B2 (en) Load balancing server and system
US7945685B2 (en) Controlled relay of media streams across network perimeters
JP4738060B2 (ja) データ通信網のセキュアな連合
US9992152B2 (en) Hub based clearing house for interoperability of distinct unified communications systems
EP2611100B1 (en) SIP session transfer in a back-to-back user agent (B2BUA) environment
RU2413289C2 (ru) Способ и система для наложения ограничений на сессии
US8683053B2 (en) Methods and apparatus for establishing secure communications between client computing devices that use transport and security protocols
US8521839B2 (en) Auxiliary event packages
EP3055953A1 (en) Federating chat rooms across disparate unified communications systems
US8966089B2 (en) Supporting proxy discovery
WO2011160005A2 (en) System and method for transferring a call between endpoints in a hybrid peer-to-peer network
US9241031B2 (en) Selecting an auxiliary event-package server
EP2047374B1 (en) Method and system for selecting an outbound proxy and corresponding backup proxies
Çıkrıkçıoğlu Design and implementation of a VoIP phone using a microprocessor board
Montag Load balancing of IP telephony

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
LAPS Lapse due to unpaid annual fee