KR20120089591A

KR20120089591A - 네트워크 환경에서 비-지속성 메시지의 다중 큐를 관리하기 위한 시스템 및 방법

Info

Publication number: KR20120089591A
Application number: KR1020120010536A
Authority: KR
Inventors: 존 와트
Original assignee: 아이엠브이유 인코포레이티드
Priority date: 2011-02-02
Filing date: 2012-02-01
Publication date: 2012-08-13
Also published as: KR101662352B1; US20120198004A1; JP2012160189A; EP2485443A1; JP5898980B2; US8799400B2

Abstract

네트워크 환경에서 비-지속성 메시지의 다중 큐를 관리하기 위한 시스템 및 방법이 개시된다. 특정 실시형태는, 게이트웨이 프로세스에서 비-지속성 메시지를 수신하는 단계로서, 상기 메시지는 명명된 큐를 나타내는 정보를 포함하는, 상기 비-지속성 메시지를 수신하는 단계; 데이터 프로세서를 사용함으로써, 명명된 큐의 일관된 해시의 사용에 의해 명명된 큐를 큐 노드로 맵핑하는 단계; 큐 노드에서 메시지를 큐 프로세스로 맵핑하는 단계; 큐 프로세스를 사용함으로써, 가입자 게이트웨이의 목록에 액세스하는 단계; 및 메시지를 목록의 가입자 게이트웨이들 각각으로 라우팅하는 단계를 포함한다.

Description

네트워크 환경에서 비-지속성 메시지의 다중 큐를 관리하기 위한 시스템 및 방법{SYSTEM AND METHOD FOR MANAGING MULTIPLE QUEUES OF NON-PERSISTENT MESSAGES IN A NETWORKED ENVIRONMENT}

일 실시형태에 따르면, 본 출원은 네트워크 엔티티에 사용할 방법 및 시스템에 관한 것이며, 보다 구체적으로는 네트워크 환경에서 비-지속성 메시지의 다중 큐를 관리하기 위한 방법 및 시스템에 관한 것이다.

저작권

이 특허 문헌의 개시 부분은 저작권 보호 대상인 자료를 포함한다. 저작권 소유자는 특허 및 상표청의 특허 파일이나 기록에 나타난 바와 같이, 특허 문서 또는 특허 개시물의 팩시밀리 재생산에 이의가 없지만, 그외에는 무엇이든 간에 모든 저작권 권리를 보유한다. 다음의 고지는 아래에 상세한 설명 및 본 문헌의 일부를 형성하는 도면에 설명된 바와 같이 소프트웨어 및 데이터에 적용된다: 저작권 2009-2011 IMVU Corporation, 판권 소유자임.

네트워크 컴퓨터 환경에서 채팅이나 인스턴트 메시징 통신의 사용이 잘 알려져 있다. 아메리카 온라인™ 인스턴트 메시징 시스템 (AIM) 은 네트워크 환경에서 인스턴트 메시징을 제어하는 하나의 널리 공지된 시스템이다. 이러한 선행 기술 시스템에서, 2명의 컴퓨터 사용자는 인스턴트 메시지 (IM) 서버와 협력하여 자신의 컴퓨터에 IM 클라이언트를 사용하여 실시간으로 비-지속성 문자 메시지를 통신할 수 있다.

대부분의 메시징 서비스는 가입 기반 또는 사용자 아이덴티티 기반이고, 특정 메시지나 콘텐츠 소스의 다수의 사용자 또는 콘텐츠 팔로워를 생성할 수도 있다. 이러한 콘텐츠 팔로워 또는 가입자가 특정 콘텐츠 소스 또는 콘텐츠 분배 시스템 주위로 커뮤니티 또는 소셜 네트워크를 형성할 수 있다. 사람들이 서로 연락하기 위한 기반으로서 메시징을 사용함에 따라서 소셜 네트워크는 인기를 얻어 가고 있다.

사용자 풀 (pool), 가입자, 소셜 네트워크의 수와 크기가 확장함에 따라서, 가입자, 청취 사용자 및 사용자가 메시지 콘텐츠와 관련된 정도를 추적하고 관리하기가 점점 곤란해진다. 마찬가지로, 다양한 콘텐츠 소스와 소셜 네트워크를 통해 소비되는 가장 인기있는 콘텐츠 항목을 식별하고 순위를 매기기가 점점 더 곤란해진다.

따라서, 네트워크 환경에서 비-지속성 메시지의 다중 큐를 관리하는 시스템 및 방법이 요구된다.

첨부한 도면들의 도에서, 다양한 실시형태를 제한이 아닌 예시의 방식으로 도시한다.
도 1은 예시적인 실시형태의 메시지 큐 시스템의 컴포넌트를 도시한 도.
도 2는 예시적인 실시형태 12 게이트웨이의 컴포넌트를 도시한 도.
도 3 및 도 4는 예시적인 실시형태의 메시지 큐의 컴포넌트를 도시한 도.
도 5는 예시적인 실시형태의 일관된 해시 프로세싱을 도시한 도.
도 6은 예시적인 실시형태에서 메시지 프로세싱을 도시한 도.
도 7은 예시적인 실시형태의 핫 부가 노드 프로세싱을 도시한 도.
도 8은 네트워크 환경에서 비-지속성 메시지의 다중 큐를 관리하는 시스템 및 방법의 예시적인 실시형태를 도시한 도.
도 9는 다양한 실시형태가 동작할 수도 있는 네트워크 시스템의 다른 예시적인 실시형태를 도시한 도.
도 10은 본원에 기재한 바와 같이 메시지 큐 시스템의 프로세싱의 예시적인 실시형태를 도시하는 프로세싱 흐름도.
도 11은 실행되는 경우 머신으로 하여금, 본원에 논의된 방법들 중 임의의 하나 이상을 수행하게 할 수도 있는 명령들의 세트가 내부에 있는 컴퓨터 시스템의 예시적인 형태의 머신의 다이어그램 표현을 도시한 도.

다음 설명에서, 설명을 위해서, 다양한 실시형태에 대한 철저한 이해를 제공하기 위해에 많은 구체적인 세부사항이 명시되어 있다. 그러나, 이 다양한 실시형태들이 이러한 구체적인 설명 없이 실시될 수도 있다는 것은 당업자에게 자명하다.

다양한 예시적인 실시형태에 대한 설명

특정 실시예의 메시지 큐 시스템은, 스케일러블하고, 효율적이고, 보안성 있고, 유연하며 용이하게 이해되는 메시지를 구현하는 독립형 소프트웨어 스택 및 상태 업데이트 스위칭 및 라우팅 패브릭이다. 메시지 큐 시스템은 메시지를 사이트로부터 클라이언트로 라우팅하고, 클라이언트가 연결하는 강력하고 스케일러블한 메시지 큐 시스템이다. 메시지 큐 시스템은 또한 실시간 쌍방향 멀티 플레이어 시스템을 위해 최적화된 경량의 메시지 큐 시스템 및 상태 관리 프로토콜인 것으로 고려될 수 있다. 도 1은 예시적인 실시형태의 메시지 큐 시스템의 컴포넌트를 도시한다. 일 예시적인 실시형태에서, 코어 메시지 큐 시스템 (10) 은 3가지 메인 역할: 클라이언트 게이트웨이(들)(12), 메시지 큐 노드(들)(14), 및 큐 관리 (16) 를 포함한다. 이들은 대략 이하에서 "게이트웨이", "큐 노드" 및 "슈퍼바이저" 또는 "보스"로 지칭한다. "노드"는 일반적으로 메시지 큐 시스템의 일부로서 실행되는 임의의 머신이다. 본원에 사용된 "노드"는 "큐 노드"와 동일하지 않다는 것을 주목한다. 큐 노드는 노드들의 다수의 가능한 유형 중 하나일 수도 있다.

위상기하학적으로, 다양한 실시형태의 클라이언트 게이트웨이 (12) 는 클라이언트 시스템 (20) 에서 사용자에 대한 인터페이스이다. 도 2는 예시적인 실시형태의 게이트웨이 (12) 의 컴포넌트를 도시한다. 특정 도메인 네임에서 사용자 요청이 서버로 들어간다. 수신된 사용자 요청은 게이트웨이 (12) 를 거쳐 로드 밸런서 (22) 의해 로드 밸런싱된다. 한 번에 사용자 당 하나의 동시 세션 (전송 제어 프로토콜 - TCP 연결) 만이 존재할 수 있기 때문에, 각각의 사용자에 대한 연속적인 세션을 동일한 게이트웨이로 이동시키려는 요구는 없다. 세션은 통상적으로 오래 계속된다. 예를 들어, 하나의 세션은 사용자가 클라이언트에 로그인되어 있는 전체 시간 동안 지속될 수 있다. 특정 실시예에서, 세션은 TCP를 통해 구글 프로토콜 버퍼에 기초하여 사용자정의 (custom) 프로토콜을 사용할 수 있다.

게이트웨이 (12) 는 먹싱/디먹싱 기능을 수행하여 사용자 요청을 실제 메시지 큐가 프로세싱되는 메시지 큐 노드 (14) 의 풀로 매개 (vector) 할 수 있다. 클라이언트 (20) 는 특히 메시지 큐로 명명된 메시지 큐를 통하여 인입하는 메시지들을 검사 (예를 들어, 메시지에 대한 액세스를 획득) 하기 위해 가입될 수 있다. 또한, 클라이언트 (20) 는 특히 메시지 큐로 명명된 메시지 큐로 메시지들을 전송하기 위해 가입될 수 있다. 도 3 및 도 4는 예시적인 실시형태의 메시지 큐의 컴포넌트를 도시한다. 특정 실시형태에서, 각 메시지 큐 노드는 메시지 큐의 결정론적인 서브셋에 대한 책임이 있다. 메시지 큐 노드에 큐 네임을 맵핑하는 것은 해싱 프로세스 (예를 들어, 해시 (큐 네임)) 를 이용하여 큐 네임을 "버켓들 (buckets)" 상으로 맵핑하는 큐 맵 또는 노드 맵에 의해 실시된다. 도 5는 예시적인 실시형태의 일관된 해시 프로세싱을 도시한다. 각 버켓은 소정의 큐 노드에 의해 제공된다. 특정 실시형태에서, 소정의 큐 노드는 일반적으로 버켓이 노드들에 걸쳐 타당하게 분포되는 8개 내지 16개의 버켓들을 제공한다. 특정 실시형태가 큐 노드 당 더 많거나 더 적은 수의 버켓을 사용할 수 있다는 것은 당업자에게 자명하다.

슈퍼바이저 (16) 는 노드 맵의 권위있는 소스일 뿐만 아니라 용이한 모니터링을 위해 시스템 전체의 통계가 집계되는 중앙 지점이다. 그러나, 슈퍼바이저 (16) 는 어떠한 실시간 메시지 스트림에 관하여도 관련되지 않고, 따라서 슈퍼바이저 노드가 일시적으로 다운인 경우에도 전체 시스템은 완전한 작동 상태에 있다. 그러나, 노드 맵은 슈퍼바이저에 의한 참여 없이 재구성될 수 없다.

특정 실시형태에서, 모든 머신은 동일한 코드 소스 트리를 실행한다; 하지만, 각각의 노드를 시작하는 명령 라인은 그것이 어떤 종류의 노드인지를 결정한다. 각각의 노드는 슈퍼바이저 (16) 를 이용하여 자신을 등록한다; 따라서, 슈퍼바이저 (16) 는 어느 노드가 효율적인 메시지 큐 시스템 (10) 의 일부인지를 결정하는 편리한 장소이다. 특정 실시형태에서, 각각의 "노드"는 전형적인 8 코어, 8 GB RAM, 연산 전용 (데이터베이스가 아닌) 서버일 수 있다. 특정 시스템에서, 하나의 슈퍼바이저 노드 ("보스")(16) 가 제공된다. 이 슈퍼바이저 노드 (16) 가 다운되면, 즉시 교체가 필요하지 않다; 하지만, 시스템을 모니터링하는 능력이 저하될 것이다. 특정 실시형태에서, 5개 내지 10개의 클라이언트 게이트웨이 노드가 제공될 수 있다. 로드 밸런서 (22) 는 이용가능한 클라이언트 게이트웨이 노드들을 통해 클라이언트 요청을 분산시키기 위해 제공될 수 있다. 특정 시스템에서, 5 내지 10개의 메시지 큐 노드가 제공될 수 있다. 이러한 메시지 큐 노드 또는 큐 노드는 대부분 자신들 간에 메시징할 수 있다. 통상적인 시스템에서, 내부 트래픽은 매우 낮다. 통상적인 실시형태에서, 특징들 및 사용자 수가 이 포인트를 초과하여 늘어날 때까지, 전체 큐는 풀(full) 로드에서 총합으로, 기가바이트 미만의 대역폭을 사용할 것이다. 네트워크 패킷 및 대역폭 인/아웃에 대한 시스템-레벨 메트릭도 제공될 수 있다.

또한, 메시지 큐 노드 (14) 는 주로 승인을 목적으로, 웹 머신으로 어떤 메시징을 할 수 있다. 특정 실시형태에서, 트래픽은 자바스크립트 오브젝트 표기법 (JSON) 과 함께 하이퍼텍스트 전송 프로토콜 (HTTP) 을 사용한다. 메시지 큐 노드는 기존의 웹 풀을 사용하거나 본원에 기재된 바와 같은 메시지 큐 시스템용의 새로운 풀을 특별하게 생성할 수 있다. 일반적으로, 서버의 "풀"은 본원에 사용된 용어에서, 프론트-엔드 로드 밸런싱을 이용하여 특정 도메인 네임 서버 (DNS) 어드레스에 응답하는 서버들의 세트이다. 서버는, 로드 밸런싱된 방법으로, 사용자에게 메시지를 전송할 게이트웨이의 세트가 될 수 있다. 특정 실시형태에서, 이 트래픽은 JSON과 함께 HTTP를 이용할 수 있다. 특정 실시형태에서, 소프트웨어는 얼랭(Erlang)/OTP R13B04의 상단에 기록될 수 있으며, 이는 http://www.erlang.org/에서 소스로부터 다운로드되어 구축될 수 있다.

각 노드는 나기오스-호환 "키 = 값" 텍스트 포맷으로 통계를 출력할 수 있는 URL (Uniform Resource Locator) 을 갖는다. 따라서, 애플리케이션 레벨의 모니터링 스크립트는 단순히 각 노드에서 해당 URL을 쳐서 작성할 수 있다. 노드 소프트웨어는 /etc/init.d로 시작하도록 설정될 수 있고, 올바른 작업 디렉토리 및 지정된 명령 라인 옵션을 가질 수 있다.

다음 섹션에서는 예시적인 실시형태의 메시지 큐 시스템 프로세스의 기능 레벨의 구현을 설명한다. 이 설명은 예시적인 실시형태의 메시지 큐 시스템이 소프트웨어 실행들 및 프로세스들로 분해되는 방법에 대한 설명이 포함한다. 예시적인 실시형태의 메시지 큐 시스템은 3 종류의 프로세스: 1) 복수의 게이트웨이 (12) 프로세스, 2) 복수의 큐 노드 (14) 프로세스, 및 3) 하나의 슈퍼바이저 (16) 프로세스를 포함한다. 특정 실시형태에 대해 도 1에 추가적으로 도시된 바와 같이, 2 이상의 컴포넌트: 복수의 트랜슬레이터 (17) 프로세스 및 상태 관리자 웹 서비스 (18) 가 제공될 수 있다. 이러한 프로세스는 아래에 더 자세히 설명되어 있다. 그러나, 처음에, 본원에 사용된 용어에 대한 요약을 제공한다.

용어 해설

● 메시지 큐 시스템

○ 전체 시스템 -- 클라이언트 라이브러리, 게이트웨이, 큐 노드 및 슈퍼바이저뿐만 아니라, 코어 메시지 큐 시스템에 의해 호출되는 트랜슬레이터 및 웹 서비스와 같은 부수적인 시스템으로 이루어짐.

● 메시지 큐 (이 중에서 대략 1,000,000개가 존재할 수 있다)

○ 가입자 (큐를 통해 트래픽의 청취에 관심이 있는 클라이언트) 의 목록과 마운트의 목록을 포함하는 메시지 큐 시스템에서 가입과 액세스 제어의 하나의 단위. 메시지 큐는 일반적으로 디스크 지속성이 아니다.

● 메시지 스트림 (이 중에서 대략 1,000,000개가 존재할 수 있다)

○ 메시지 큐 시스템의 하나의 어드레스가능한 엔드포인트로서 메시지 큐 시스템을 통하여 메시지가 큐의 모든 가입자에게 브로드캐스트된다. 메시지 스트림은 메시지 큐 내에서 명명된 마운트로서 식별된다.

● 상태 스트림 (이 중에서 대략 1,000,000개가 존재할 수 있다)

○ 메시지 큐 시스템 내의 하나의 어드레스가능한 엔드포인트로서, 메시지 큐 시스템을 통하여 상태 업데이트가 흐른다. 상태 스트림은 일반적으로 디스크 지속성이 아니지만, 키/값 상태의 궁극적인 일관성을 지원하고, 발호를 통한 상태 관리자로의 상태 변경 요청의 검증을 지원한다. 메시지 큐 내에서 명명된 마운트로서 어드레싱됨. 0 이상의 상태 관리자가 있을 수도 있다.

● 마운트

○ 메시지 큐 내의 특정 명명된 스트림 -- 메시지 스트림 또는 상태 스트림. 본원에 사용된 바와 같이, 용어는 "마운트"는 용어는 "스트림"의 동의어로 간주될 수 있다.

● 클라이언트 (이 중에서 대략 1,000,000개가 존재할 수 있다)

게임/시뮬레이션에의 참가자. 이 클라이언트는, 이것이 특별한 권한을 가지고 있지 않다면, 공유 상태의 생성/삭제에 대한 어떤 권위있는 결정을 실행할 것으로 신뢰되지 않는다.

● 게이트웨이 (이 중에서 대략 1,000,000개가 존재할 수 있다)

○ 클라이언트로부터의 접속을 수용하고, 이들을 적절한 엔드포인트 메시지 큐 노드들로 라우팅하는 프로세스. 추가적으로, 게이트웨이는 인증 및 메시지 큐 시스템 T -> 얼랭 직렬화를 수행한다.

● 큐 노드 (이 중에서 대략 10개가 존재할 수 있다)

○ 메시지를 라우팅하고 상태 업데이트하는 프로세스를, 명명된 메시지 큐를 통해 (게이트웨이를 경유하여) 가입된 클라이언트에게 호스팅하는 머신.

● 게이트웨이 노드 (이 중에서 대략 10개가 존재할 수 있다)

○ 머신 호스팅 게이트웨이 및 지속성 프로세스.

● 슈퍼바이저 (이 중에서 1개가 있다)

○ 메시지 큐 인프라스트럭쳐의 구성에 대하여 권위있는 상태를 소유하는 머신과 프로세스.

● 지속성 (이 중에서 대략 1,000,000개가 존재할 수 있다)

○ 게이트웨이의 관점에서 "새로운" 클라이언트로서 역할을 하지만, 트랜슬레이터의 관점에서 REST-스타일 (Representational State Transfer-style) 서버로서 역할을 하는 프로세스. 특정 로그-인 클라이언트에 대한 특정 클라이언트 식별자 (Cid) 와 연관됨. 사실, 특정 필터 플러그-인을 이용하는 게이트웨이일 수도 있다.

● 트랜슬레이터 (이 중에서 대략 1,000,000개가 존재할 수 있다)

○ 일 단에서 (대화할 펄벌 (perlbal) 에 대하여) HTTP 서버로서 역할을 하고, 다른 단에서 얼랭으로 직렬화하는 프로세스. 이 트랜슬레이터는 Cid에 기초하여 인입하는 요청에 대한 적절한 지속성을 디스패치한다. 새로운 시스템에 대화하도록 구 클라이언트에 의해 사용된다.

● 트랜슬레이터 노드 (이 중에서 대략 10개가 존재할 수 있다)

○ 트랜슬레이터 프로세스를 호스팅하는 머신.

● 상태 관리자

○ 큐 노드의 명령으로 상태 업데이트 요청을 확인하고 진화할 수 있는 플러그-인. 입력으로서 "구 상태"와 "변경 요청"을 수신하고, "새로운 상태"를 출력한다.

● 발호 (Call-out)

○ 잘 정의된 프로토콜, 일반적으로 HTTP JSON 서비스에 따라 메시지 큐 시스템으로부터 특정 요청에 응답하는 프로세스. 상태 관리자 중 일 형태는 발호를 사용한다. 게이트웨이는 인증 검증 및 연결 드롭 알림을 위한 발호를 사용한다.

● 서비스 (이 중에서 대략 100개가 존재할 수 있다)

○ 이 시스템 외부의 수단을 통해, 메시지 큐의 생성, 재구성 및 삭제를 요청하는 권한을 가진 프로세스.

● 상태 플러그-인

○ 상태 업데이트 일관성을 강제하기 위해서 상태 스트림 마운트에 의해서 사용된 얼랭 모듈. 일례로 PHP 발호 플러그-인이 있다.

● 필터 플러그-인

○ 클라이언트로 가는 그리고 클라이언트로부터 오는 메시지를 필터링하기 위해 게이트웨이에 의해 사용된 얼랭 모듈. 메시지 시스템의 나머지 부분 또는 주변 통합 시스템을 사용함으로써, 메시지를 상이한 포맷을 사용하여 획일적인 포맷으로 트랜슬레이트하는데 사용될 수 있음.

게이트웨이 프로세스

게이트웨이 (12) 프로세스는 클라이언트뿐만 아니라 지속성 서버 프로세스와 지속성 연결을 유지한다. 연결의 생성은 연결의 지속기간 동안 지속하는 인증을 확립한다. 인증 및 이진 프로토콜 디코드 이외에, 게이트웨이 프로세스는 비교적 간단하다. 게이트웨이 프로세스는 큐 네임 (id) 을 타겟 큐 노드로 맵핑하고 타겟 큐 노드에 메시지를 포워딩할 뿐만 아니라, 적절한 연결된 클라이언트로 응답을 리턴시킬 수 있다. 도 2는 예시적인 실시형태의 게이트웨이 (12) 의 컴포넌트를 도시한다. 도 6은 예시적인 실시형태의 메시지 프로세싱을 도시한다. 게이트웨이 프로세스는 또한 엔드포인트들 (예 : 큐 및 클라이언트) 사이의 가입을 생성할 수 있다. 게이트웨이 프로세스는 큐 id 네임스페이스에 대한 라우팅 패브릭을 확립한다. 큐 노드에 대한 네임스페이스 맵핑의 각 서브셋에 있어서, 게이트웨이는, 게이트웨이가 해당 노드의 큐에 모든 메시지를 라우팅하고 현재 가입된 클라이언트가 그 게이트웨이에 있는 해당 노드의 모든 큐들로부터 메시지를 수신하는 동안 하나 이상의 TCP 연결을 확립한다. 큐가 맵에 아직 없다면, 큐에 대한 가입이 클라이언트에 대해 요청될 경우, 게이트웨이는, 게이트웨이가 현재 청취할 큐의 맵에 큐를 추가한다. 또한, 게이트웨이는 큐 엔트리 내에서부터 클라이언트에 대한 참조를 추가한다. 그 방법은, 게이트웨이가, 연결된 노드 상의 큐로부터 수신된 메시지를 가입된 클라이언트의 적절한 세트로 라우팅할 수 있다. 이 맵핑은, 클라이언트가 큐로부터 가입해제하거나 접속해제한 경우 원상태로 된다. 클라이언트가 큐에 메시지 또는 상태 변경 요청을 전송한 경우, 게이트웨이는 메시지를 적절한 큐로 포워딩한다. 게이트웨이가 포워딩한 어떤 메시지에 있어서, 인증된 사용자가 하는 요청이 요청에 추가된다. 따라서, 클라이언트는 어떤 요청에도 그 자신의 아이덴티티를 포함하지 않는다 (포함하지 않아야 한다) : 대신, 요청자는 게이트웨이 프로세스에 의해 메시지에서 믿을 수 있게 식별될 것이다. 그렇게 하여, 시스템은 위장 (impersonation) 공격에 대한 면역이 생긴다. 게이트웨이도 대량 가입, 생성, 삭제, 및 웹 사이트에서 신뢰할 수 있는 서비스로부터의 업데이트를 허용하는 관리 인터페이스를 갖는다. 게이트웨이 프로세스가 사인-오프를 위한 연결 (hook) 을 요구할 수도 있으며, 게이트웨이 프로세스는, 연결된 사용자의 손실을 시스템에 통보하는 웹 서비스로 발호할 수 있다. 대안으로, 시스템은 소정의 사용자에 대하여 특별하게 큐에 가입하고, 사용자가 연결을 해제하면 사용자-부재 통지를 수신한다. 게이트 웨이는, 프로세스가 계속되면 그 자신을 이용가능한 것으로 등록할 수 있다. 게이트웨이는 시간 기간 (예, 몇 분) 에 한 번씩 슈퍼바이저에게 통계치를 보낼 수 있다.

큐 노드 프로세스

특정 실시예에서, 큐 노드 (14) 는 메시지 큐를 동작시킨다. 도 3과 도 4는 예시적인 실시형태의 메시지 큐의 컴포넌트를 도시한다. 각 메시지 큐는 현재 가입된 청취자의 목록이나 세트를 갖는다. 이들 목록은 각 메시지 큐에 대해 상이할 수도 있다. 각 메시지 큐는 가입자의 세트와 네임으로 구성되어 있다. 큐 내에서, 메시지 스트림 및 상태 스트림이 "마운트"될 수 있다. 추가적으로, 큐는 또한 구성 상태 관리자 발호 서비스뿐만 아니라, 큐 내에 각각 "마운트"를 가질 수도 있다. 게이트웨이가 노드에 대한 연결을 생성하는 큐 노드는 대부분 수동이며, 노드는 관심있는 게이트웨이를 라우팅 및 통보함으로써 인입하는 메시지에 대해 반응만 할 뿐이다. 큐 노드가 사용자 큐 가입 요청을 수신하는 경우, 이미 존재하지 않는다면, 요청 게이트웨이가 큐에 대한 출력 목록에 추가되고, 가입 사용자가 해당 게이트웨이 엔트리에 엔트리로서 추가된다. 이 방법은, 해당 게이트웨이 상의 다수의 사용자가 동일한 큐에 가입하고 있다 하더라도, 메시지는 한번 만 게이트웨이로 포워딩될 필요가 있다. 사용자가 가입하지 않았거나, 게이트웨이가 (예를 들어, 고장 때문에) 접속해제된 경우, 이 절차는 반대가 된다. 큐 이동에 있어서, 아래에 보다 자세히 설명되는 바와 같이, 큐의 상태가 완전히 직렬화되고 다른 큐 노드로 이동가능해야한다. 또한, 큐 노드는 큐에 대한 새로운 큐 노드로 전송되었던 큐에 대하여 의도된 메시지를 포워딩할 수 있어야 한다. 큐 노드는, 프로세스가 계속되는 경우 그 자신을 이용가능한 것으로 등록할 수 있다. 큐노드는 시간 기간 (예를 들어, 몇 분의 값) 에 한 번씩 슈퍼바이저에게 통계치를 보낼 수 있다.

슈퍼바이저 프로세스

슈퍼바이저 (16) 프로세스는 메시지 큐 시스템의 모든 노드를 관리할 수 있다. 슈퍼바이저 프로세스는 또한 메시지 큐 노드 맵핑 테이블로 큐 네임을 관리한다. 특정 실시형태에서, 이 맵핑은 새로운 노드의 1 대 N 재-맵핑을 기존의 노드의 N개의 세트에 추가하게 하여 전통적인 "원형 해시"로서 (또는, 대안으로, 노드에 맵핑된 버켓으로서) 유지된다. 또한, 슈퍼바이저 프로세스는 시스템의 성능과 로드에 관하여 게이트웨이 노드와 큐 노드로부터 통계치를 수집하고, 관리 인터페이스를 통해 시스템 성능의 종합 보기를 제공한다. 슈퍼바이저 프로세스는 일반적으로 클러스터 네트워크 외부에서 볼 수 있지만, 대신에 웹 관리 서비스를 통해 완전히 액세스된다. 슈퍼바이저는 노드 맵핑 테이블에 대한 업데이트에 대하여 게이트웨이에게 알려준다.

특정 실시형태에서, 하나의 슈퍼바이저 프로세스만 있다. 그러나, 슈퍼바이저 프로세스가 일시적으로 비활성인 경우에도 게이트웨이 및 큐 노드의 구성 네트워크가 계속 동작할 수 있다는 점에서, 슈퍼바이저 프로세스는 단일 고장점 (a single point of failure) 이 아니다. 이 경우, 메시지 큐 시스템은 통계치를 보고하거나 노드 맵핑 테이블을 재구성할 수 없을 뿐이다. 슈퍼바이저 프로세스는 특정 실시 형태에서, 단순히 통계치의 수집기로서 역할을 할 수 있다. 이 단순화로부터, 주요 기능 중, 기존 클라이언트 접속의 중단 없이, 용량을 추가하거나 다운된 노드에서 로드를 재분배하는 능력을 손실한다.

트랜슬레이터 프로세스

메시지 큐 직접 게이트웨이와 직접 통신하도록 업데이드되지 않는 클라이언트 또는 제한적인 HTTP-전용 프록시 방화벽 뒤에 이들이 있기 때문에 그렇게 할 수 없는 구 클라이언트는, 기존의 채팅 스크립트에 대하여 XMLRPC 호출을 계속할 수 있다. XMLRPC는, XML (Extensible mark-up language) 을 이용하여 그 호출과 HTTP를 전송 매커니즘으로서 인코딩하는 종래의 RPC (Remote Procedure Call) 프로토콜이다. 이러한 스크립트는 메시지 큐 게이트웨이로 메시지를 트랜슬레이트하고 포워딩할 필요가 있을 수도 있다. 메시지 큐 게이트웨이는 지속성 접속 모델을 사용하고, XMLRPC 웹 서버는 일반적으로 REST (Representational State Transfer)-형 폴링 (polling) 모델을 사용하기 때문에, 두 모델들 사이에서 트랜슬레이트할 무언가가 필요하다.

특정 실시형태의 트랜슬레이터 (17) 프로세스는 지속성의, 상태기반 (stateful) 프로세스이다. 트랜슬레이터 프로세스는 XMLRPC 응용 프로그래밍 인터페이스 (API) 를 사용하여 메시지 큐 게이트웨이들에, 클라이언트 당 하나씩 연결을 확립한다. 이후, 트랜슬레이터 프로세스는 XMLRPC로부터 JSON 요청을 수신하고 이들을 메시지 큐 시스템 메시지로 변환한다. 또한, 트랜슬레이터 프로세스는 메시지 큐 시스템 큐로부터 메시지를 버퍼링하고 상태 업데이트하고 XMLRPC 시스템의 편의에 따라 이들을, 폴링할 JSON 데이터로서 이용가능하게 한다. 어떠한 메시지도 미리 결정된 시간 (예를 들어, 5 분) 동안 폴링되지 않았다면, 클라이언트는 접속해제된것으로 가정되고, 지속성 접속이 허물어진다.

약간의 구현 변형은 트랜슬레이터 입력을 위해 JSON의 대신 기존의 스크립트들에 대하여 더 용이하게 작업하는 XML을 사용하는 것이다. 보다 실질적인 구현 변형은 채팅 스크립트의 거동을 전체적으로 에뮬레이트하여 채팅 웹 서버에 대한 필요성을 상당히 감소시키거나 제거한다. XMLRPC (채팅웹) 서버로부터 트랜슬레이터 프로세스로의 맵핑은 고객 ID (cid) 에서 간단한 MOD 동작을 사용하여 수행할 수 있다. 대안으로, 맵핑은 채팅웹 인스턴스에 기초하여, 또는 원형 해시 또는 기타 일관된 해시 메커니즘과 같은 어떤 다른 일관된 맵핑 기능을 사용하여 정적으로 수행할 수 있다.

상태 관리자 서비스

특정 상태 (속성 값) 을 도입, 업데이트 또는 삭제하는 요청을 수신하는 큐 상태 스트림은 상태 업데이트에 대한 규칙을 강제하기 위해서 상태 관리자 서비스 (18) 를 따로 호출할 수 있다. 큐 상태 스트림은 JSON 형식의 데이터 블록뿐만 아니라 요청된 상태 변화로 현재 상태를 묶고, 상태 관리자의 웹 서비스에 요청을 게시할 수 있다. 이후, 상태 관리자 웹 서비스 (18) 는 3 가지 결과: a) ok: 요청된 것으로 변경을 적용함, b) 거부 : 변경하지 않음, 또는 c) 변경: 상태 관리자에 의해 리턴된 것과 같이 변경을 적용, 중 하나를 리턴한다. 상태 관리자는 메인 웹 서버에서 무상태 (stateless) 웹 서비스를 실행할 수 있다. 상태 관리자로부터의 로드가 별도로 관리될 필요가 있다면, 이것은 필요에 따라 웹 프런트-엔드의 별개의 풀로 용이하게 시프트될 수 있다. 큐 상태 스트림에 대하여 유효한 상태 관리자는, 큐가 생성되는 경우 파라미터로서 구성된다. 소정의 큐에 대하여 유효한 임의의 수의 상태 관리자들이 존재할 수 있다. 소정의 룸, 오브젝트, 또는 서비스는 필요에 따라 상태의 상이한 세트를 구현하는 다중 큐 상태 스트림을 사용할 수도 있다. 상태 관리자는 상태의 다수의 세트들에 기초하여 결정하기 위해서 다수의 마운트된 스트림을 청취할 수 있다. 예를 들어, 룸 당 아바타 상태 (누가 "왕"인가) 에 대한 정보와 룸 당 상태 (어느 노드가 "왕좌"인가) 에 대한 정보를 필요로 하는 규칙이 마운트되어, 두 종류의 정보를 찾아 왕들만이 왕좌에 앉을 수 있는 규칙을 시행할 수 있다.

게이트웨이 노드

게이트웨이 노드는, 그들이 슈퍼바이저와 연결되어 있고 큐 네임스페이스 맵을 수신한 경우 클라이언트 요청의 서빙을 즉시 시작할 수 있다. 모든 게이트웨이 노드의 요구는 하드웨어 로드 밸런서가 게이트웨이들에서 클라이언트를 포인팅하기 시작하게 하는 것이다. 특정 실시형태에서, 설계 목표는 20,000명의 사용자를 하나의 서버 (8 코어, 24 GB/s 메모리 버스) 에 연결시키는 것이다. (예를 들어, 간헐적인 WiFi 핫스팟 때문에) TPC 접속을 드롭하고 재확립하는 클라이언트에 있어서, 새로운 게이트웨이가 새로운 연결을 위해 선택될 가능성이 높다. 이것을 완화하기 위해서, 클라이언트에 대한 가입 정보는 클라이언트에 특정한 상태 스트림에 보관되고 게이트웨이에 의해 관리된다. 클라이언트가 게이트웨이에 재접속하는 경우, 클라이언트는, 클라이언트가 현재 참여하고 있는 가입의 모든 가입들을 재전달할 것이다. 이 큐는 자동으로 일정량의 타임 아웃 (예를 들어, 60 초) 이후 제거된다. 어떤 클라이언트도 타임 아웃 기간 내에 큐에 가입하지 않는다면, 이 큐는 불필요하게 할당된 시스템 자원을 유지하지 않기 위해서 "철저하게 (hard)" 접속해제한다. 게이트웨이가 접속해제되기 전에, 사인-오프 통지를 버디에게 즉시 제공하기 위해서, 제어된 (사용자-개시된) 사인-오프는 게이트웨이를 통과한 메시지와, 버디 상태 채널의 상태 업데이트를 발생시킨다.

내부적으로, 특정 구현의 게이트웨이가 gen_server (특히, 이진 용 TCP의 서브클래스 및 HTTP 인터페이스 용 HTTP 서버 서브클래스) 에 기초한다. 억셉터들 각각은 각각 인입하는 요청에 대한 새로운 얼랭 프로세스를 시작한다. 장기 실행 접속 (클라이언트에 대한 이진 프로토콜) 에 있어서, 이 프로세스는 사용자에게 특정한 라우팅 상태를 구축한다. 시스템 내의 메시지는 일반적으로 얼랭 스트럭트로 구성된 얼랭 투플 (tuple) 로서 전송된다.

또한, 게이트웨이 노드 당 하나의 '노드 디스패처" 프로세스 또는 "맵핑 포워더" 프로세스가 존재한다. 이 프로세스는 메시지 큐 네임을 해당 큐 노드로 트랜슬레이트하고, 인출되는 패킷을 큐 노드로 포워딩하고, 큐 노드로부터 패킷을 수신하여 가입 연결된 사용자에게 디스패치한다. 특정 실시형태에서, 클라이언트 연결은 통상적으로 포트 (443) 를 통해 인입한다. 각각의 허용된 연결은, 프로토콜 버퍼 프로토콜을 디코딩하고 요청들을 얼랭 투플 (스트럭트) 로 터닝하는 클라이언트 프레이밍 핸들러를 생겨나게 한다. 대부분의 메시지는, 목적지 큐 네임을 소정의 물리 큐 노드로 트랜슬레이트하고 그 큐 노드에 대하여 통신 프로세스로 디스패치하는 큐 맵으로 넘어간다. 각 게이트웨이 노드에 노드 당 적어도 하나의 이러한 프로세스가 존재하고 그 노드에서 게이트웨이 프로세스에 의해 사용된다. 특정 실시형태에서, 가입자에 대한 큐로부터의 응답은 이 "노드 디스패치" 프로세스를 건너뛸 수 있으며; 이러한 반응은 각 가입 게이트웨이 프로세스로 바로 이동할 수 있다. 메시지 "노드 디스패처" 프로세스가 병목 프로세스인 것으로 밝혀진다면, 우리가 연결 처리 프로세스를 구성할 경우 우리는 이 프로세스를 병렬화하고 N개의 메시지 큐 노드 디스패처 프로세스들 간에 순차 순환 대기 시킬 수 있다. 별도의 프로세스를 만드는 포인트는, 네임스페이스의 동적 재-맵핑을, 훨씬 더 쉽게 구현하는 것이다.

통계치를 슈퍼바이저에게 푸쉬하도록 슈퍼바이저 관리 인터페이스가 처음으로 제한된다. 특정 실시형태에서, 이러한 통계는:

● # 초당 라우팅된 메시지 <- 따라서 우리는 워크로드를 추적할 수 있다

● # 클라이언트 연결 <- 따라서 우리는 로드 밸런싱을 확인하고 중단을 검출할 수 있다

● # 연결된 큐 노드 <- 따라서 우리는 연결 문제가 있는지 여부를 확인할 수 있다

● # 클라이언트 당 가입된 큐 <- 통계 및 계획의 목적

● # 턴-어라운드 요청에 대한 최소, 평균 및 최대 레이턴시 (op_id 코드로 요청) <- 특정 타겟 (예를 들어, 100 ms 타겟) 에 대한 성능을 추적하기 위함

● 최종 시간 기간 (예를 들어, 시간) 으로부터 가장 느린 메시지가 왕복 <- 곤란한 요청을 추적하기 위함

● # 초 당 웹 요청 <- 메시지 큐 시스템 상의 클러스터 로드를 추적하기 위함

● 웹 요청에 대해 최소, 평균 및 최대 레이턴시 <- 시스템을 통한 성능을 추적하기 위함

● 최종 시간 기간 (예를 들어, 시간) 으로부터 가장 긴-실행 웹 요청 <- 곤란한 요청을 추적하기 위함

● 총 얼랭 프로세스 메모리 사이즈

● 최대 얼랭 프로세스, 사이즈 및 타입

● 프로세스 종류의 당 얼랭 제외 카운트

● 소프트웨어 버전

을 포함할 수 있다.

아래에 더욱 자세히 설명된 바와 같이 온라인 큐 노드 삽입/이동/제거의 구현의 일부로서, 관리 인터페이스는 또한 큐맵 업데이트 커밋 사이클에 참여할 수 있다. HTTP 인터페이스는 JSON 요청을 수용하고 JSON 데이터를 리턴한다. HTTP 인터페이스는 HTTP 연결 당 하나의 얼랭 프로세스를 생겨나게 한다. 대안적인 실시형태에서, 우리는 요청 핸들러의 풀로 이동할 것을 선택할 수 있다. 인터페이스는 JSON을 얼랭 스트럭트로 트랜슬레이트하고, 얼랭 스트럭트로부터 JSON으로 다시 트랜슬레이트한다. 16 진법에 대해 ＼xXX을 지원하는 JSON을 연장하고, 32보다 작거나 126보다 큰 문자에 대해 그 인코딩을 사용한다. 대안은 -is (유니코드-스타일 JSON으로 예상됨) 또는 ＼uXXXX (ASCⅡ JSON으로 예상) 와 같은 문자를 보내는 것이다.

큐 노드

메시지 큐 노드들은 슈퍼바이저에 의해 관리되는 큐 노드맵으로부터 네임스페이스 영역을 할당받을 때까지 큐 요청의 서빙을 시작할 수 없다. 특정 실시형태에서, 각각의 큐는 하나의 얼랭 프로세스로 표시된다. 이것은, 큐에 있는 모든 마운트된 네임 스페이스 (예를 들어, "프로퍼티 백 (property bags)"으로 표시된 메시지 스트림 및 상태 스트림) 가 큐 내에서 직렬화된다는 것을 의미한다. 웹 서비스에 대한 발호는 발호를 요청하는 스트림에 대하여 마찬가지로 직렬화된다; 메시지 스트림에 게시된 메시지들은 발호할 필요가 없을 수도 있으므로 상태 변경 요청과 비교하여 외부 검증의 필요성을 재순서화할 것이다. 또한, 큐는 얼랭 프로세스에 플러그-인들으로서 로딩된, 인-프로세스 필터 또는 상태 관리자를 포함하고, (다시, 직렬화 목적으로) 큐 프로세스 그 자체의 일부로서 실행할 수 있다.

특정 구현에서, 설계 목표는 최대 100,000개의 큐가 하나의 서버 (8 GB, 8 코어, 24 GB/s 메모리 버스) 에 계속되게 하는 것이다. 이것은, 큐 당 상태의 80 kB 까지 허용한다. 메모리 제한이 큐당 오버헤드 때문에 문제가 된다면, 시스템 전체의 레이턴시를 낮게 유지하기 위해서, 우리는 하나의 상자 내에 RAM을 증가시키기 보다는 더 많은 큐 노드로 분할할 수 있다. 특정 실시형태에서, 설계 목표는 하나의 메시지가 100 밀리초 이내에 시스템을 통해 (인입하는 게이트웨이로부터 큐 노드를 통해 청취하는 클라이언트에게로) 흐르도록 하는 것이다. RAM의 8 GB와 24 GB/s 메모리 버스를 이용하는 서버가 8 GB 작업 세트를 통해 작업하기 위해서는 350 밀리초가 소요된다는 것을 주목한다.

명명된 큐의 큐 노드로의 맵핑은 큐 네임의 MD5 해시를 통하여 완성되는데, 그 다음에, 노드 서버에 할당된 버켓들의 순서로 MD5 해시의 상단 N 비트 (예를 들어, 10 비트) 의 맵핑이 이루어진다. MD5 해싱은 당업자에게 알려져 있다. 처음에는, 많은 버켓이 각각의 참여 큐 노드에 할당된다. 더 많은 큐 노드가 온라인 상태로 있기 때문에, 버켓이, 할당된 노드로부터 상당히 제거되고 새로운 노드에 추가되어 확률적으로 밸런싱된 1/N 로드 맵핑을 유지한다. 슈퍼바이저는 해시-투-노드 맵핑의 마스터 맵을 보유한다. 특정 실시형태에서, 노드 당 최소 수의 버켓을 강제할 수 있으며, 심지어 로드조차도 그렇다. 예를 들어, 하나의 노드가 2개의 버켓에 의해 맵핑되고, 하나의 노드가 3개의 버켓에 의해 맵핑되는 것을 허용한다면, 다른 방법으로 균일한 로드 분배를 가정하는 로드의 차는 제 1 노드에서보다 제 2 노드에서 50 % 더 높을 것이다. 특정 실시형태에서, 노드 당 최소 수의 버켓 정책 (예를 들어, 노드 당 최소 8개의 버켓) 이 강제될 수 있다. 일단 모든 노드가 8개의 버켓을 가지면, 예를 들어, 우리는 맵핑된 어드레스 공간을 변경하지 않고 노드 당 버켓의 수를 두 배로 할 수 있다. 이러한 방식으로, 각각의 버켓은 노드 당 총 16개의 버켓을 위하여 2개의 새로운 버켓이 된다. 그런 다음, 우리는 로드 불균형을 염려하지 않고 타당하게 다시 재분배를 시작할 수 있다. 노드 당 사용되는 최소 수의 버켓은 다른 방법으로 균일한 로드 ("핫 키" 아님) 를 가정하는 최대 로드 불균형을 결정한다. 노드 당 최소 8개의 버켓에 있어서, 최악 경우의 비율은 8:9이거나, 제 2 호스트에 12.5 % 더 많은 로드가 있는 것이다. 최소 수의 버켓을 증가시키는 데는 비용이 든다; 노드 맵이 큐 노드 맵퍼 프로세스에 대한 "핫 데이터"이기 때문이다. 따라서, 노드 맵은 L1 캐시에 이상적으로 잘 맞는다.

내부적으로, 각각의 메시지 큐는 얼랭 프로세스이다. 또한, 각각의 게이트웨이로부터 인입하는 메시지에 대한 수신 프로세스이다.

메시지 큐 노드는 게이트웨이로부터 요청을 수신한다. 이러한 요청은 물리 노드에 대한 "중앙 입력" 프로세스로 이동하는데, "중앙 입력" 프로세스는 적절한 메시지 큐 프로세스로 차례차례 디스패치한다. 메시지 큐는 얼랭 프로세스이다 - 메시지 큐당 하나. 각각의 메시지 큐 내에서, 서로 다르게 명명된 "핸들러"는 "마운트"된다. 이들은 메시지 포워딩 또는 상태 저장과 같은 특정 거동을 구현한다. 핸들러는 네임으로 참조되는 얼랭 모듈의 형태를 취한다. 상태 저장 핸들러는 또한 다시 얼랭 모듈로 작성된 플러그-인 상태 관리자를 지원한다. 당업자는, 얼랭 모듈이 아닌 다른 유형의 모듈이 비슷하게 사용될 수 있다는 것을 이해한다. 하나의 상태 관리자 핸들러 플러그-인은 PHP 발호 핸들러이다. 이것은, 이러한 경우, 발호할 URL이 무엇인지와 같이 플러그-인들이 구성 데이터로 허용된다는 것을 의미한다. 각각의 큐는 게이트웨이 엔트리 당 사용자의 목록에 의해, 가입된 게이트웨이 노드의 목록으로 분류된, 가입된 사용자의 목록을 포함하는데, 이는 출력 노드에 대한 카운팅뿐만 아니라 존재 정보의 생성을 참조하게 한다.

우리는 대부분의 경우 핫 코드 재-로드 (re-load) 에 대하여 설계한다. 이것은, 모듈 네임을 통해 명시적으로 테일-재귀적으로 (tail-recursively) 그 자신을 호출하는 "루프" 기능으로 설명된다. 특정 데이터 구조 업데이트는 대신 롤링 재시작을 요구할 것이다. 테스트는 이러한 경우 대부분을 발견하는데 사용될 수 있고, 단계적인 디플로이먼트 상에서 웹 푸쉬 모니터와 비슷한 예외 카운터를 통해 이들을 검출할 수 있다. 슈퍼바이저는 현재 런타임 메트릭의 수신자이다. 특정 실시형태에서, 이러한 메트릭은:

● # 시간 기간당 라우팅된 메시지

● # 메시지 큐

● # 메시지 큐당 마운트

● 큐당 평균 상태 저장 메모리

● 큐 프로세스에 의해 사용된 총 메모리

● 최대의 프로세스, 사이즈 및 유형

● 얼랭 예외, 카운트 및 프로세스 유형

● 소프트웨어 버전

을 포함할 수 있다.

슈퍼바이저 (16) 는 또한 노드 수신기 프로세스가 큐 이동 (queue migration) 에 참여하게 할 수 있다. 큐 이동은, 노드가 메시지 큐들을 직렬화하게 하여 새로운 호스트 노드로 이동하게 하고, 그 이후, 이동된 메시지 큐에 대하여 의도된 메시지가 타겟 노드로 포워딩될 것이라는 것을 의미한다. 이것은, 모든 게이트웨이가 새로운 메시지 디스패치 맵을 수용할 때까지 계속될 것이며, 그때에, 이동되어 나간 큐에 대한 임의의 정보는 제거될 수 있다. 이 프로세스는 핫 부가 노드 프로세싱을 표시할 수 있다. 도 7은 예시적인 실시형태의 핫 부가 노드 프로세싱을 도시한다. 큐 이동은 한번에 하나의 큐를 요청받을 수 있는데, 이는 노드가 다른 요청의 서빙을 하고 그동안, 이동 중에 있는 큐에 대하여 의도된 큐 전용 메시지를 서빙하게 한다. 이동된 큐가 성공인 것으로 리포트되는 경우, 펜딩된 메시지가 포워딩되고 다음 큐가 이동하기 시작한다. 100,000개의 큐를 갖고, 밀리초 마다 하나의 큐를 이동시키고, 모든 큐들 중 1/10이 이동시킨 경우, 이 프로세스는 10초가 걸리므로, 이동은 시스템 응답에 중요할 때까지 요청을 서빙할 수 있다.

메시지 큐는, 클라이언트가 접속해제하고 재접속하는 경우, 놓친 메시지를 재전송할 책임이 있다. 이것을 지원하기 위해서, 메시지 큐는 마운트에 의해 생성된 각각의 인출되는 메시지의 번호를 매길 수 있다. 클라이언트가 접속하는 경우, 클라이언트는 "최종 수신 메시지"에 일련 번호를 제공할 수 있다. 이 일련 번호가 큐에 의해 계속해서 기억되는 메시지 (또는 가장 오래 기억된 메시지 앞의 일련 번호) 와 일치한다면, 그 이후의 메시지가 재전송될 것이고, 클라이언트는 최신인 것으로 가정될 것이다. 일련 번호가 0인 경우, 또는 일련 번호가 기억된 메시지의 범위 앞에 오는 경우, 그 접속은 "새로운" 것으로 다루어질 것이고 메시지 스트림이 아무것도 안 하고 상태 스트림이 상태 모두의 스냅샷을 전달하는, "새로운 상태"를 전달하도록 각각의 마운트가 호출될 것이다.

슈퍼바이저 노드

슈퍼바이저는 얼랭 런타임에 시스템 전체 등록된 네임 (예를 들어, "슈퍼바이저") 을 이용하여 어드레싱될 것이다. 슈퍼바이저는 특수 커맨드-라인 아규먼트를 이용하는 슈퍼바이저로 시작된다. 온라인 상태에 있는 메시지 큐 노드와 게이트웨이 노드는, 노드의 실행 프로세스에 대하여 커맨드-라인 파라미터에 의해 설명된 타입을 이용하여, 그들 자신을 슈퍼바이저와 함께 등록한다. 슈퍼바이저는 상이한 노드로부터의 통계치를 종합하고 시스템 내의 메트릭들의 종합적인 관리 개요를 제공한다. 새로운 메시지 큐 노드를 시스템에 삽입할 경우, 슈퍼바이저는 먼저 새로운 맵을 모든 큐 노드에게 알릴 것이고, 이후 큐 노드들이 큐 상태 (뿐만 아니라 타겟 큐에 대한 인입하는 트래픽) 를 새로운 노드로 포워딩하게 한다. 이후, 슈퍼바이저가 새로운 맵을 모든 게이트웨이로 분배할 것이므로, 게이트웨이는 인입하는 트래픽이 적절한 새로운 노드로 전송되는 것을 알게 될 것이다. 최종적으로, 모든 모드는, 새로운 노드가 "수용"되었음을 듣게 되고, 구 노드는 새로 이동된 메시지 큐와 관련된 어떤 상태를 제거할 수 있다.

클라이언트

클라이언트가 메시지 큐 시스템 (예를 들어, 도메인 네임 서버 - DNS 네임에 의해) 에 연결하도록 업데이트된다. checkForMessages()와 같은 XMLRPC 호출은 메시지 큐 게이트웨이로부터의 트래픽에 의해 구동되도록 재매개 (re-vectored) 된다. 게이트웨이와 클라이언트 사이에 단지 하나의 접속만이 필요하다. 사용자는, 만료 시간, 사용자 id 및 해시 시그니처를 포함한 해시-서명 쿠키를 통해 게이트웨이에 대해 식별된다. 클라이언트가 먼저 로그 인할 때 (로그인이 게이트웨이를 통해 완전히 발생할 때까지 그리고 발생하지 않는 경우) 이 쿠키가 웹 시스템에 의해 이슈된다. 쿠키 도난을 방지하기 위해서, 3가지 방법의 핸드쉐이크가 있는데, 게이트웨이는 암호화 랜덤 챌린지를 클라이언트에게 이슈하고, 클라이언트를 사용자의 패스워드를 이용하여 이것을 서명하고 게이트웨이로 리턴시킨다. 이후, 게이트웨이는, 그 시그니처가 국부적으로 챌랜지를 서명함으로써 획득한 시그니처와 연관성이 있음을 확인한다. 이것은 사용자의 패스워드가 서버측에서 보유될 것을 요구한다. 이것에 대항하기 위해서, 일 실시형태에서, 사용자는 패스워드의 해시를 이용하여 챌린지에 서명하고, 패스워드가 서버 측에 저장되는데, 이는 패스워드의 해시가 새로운 "패스워드"이지만, 시스템 침해 사건이 있을 경우 평문의 패스워드 누설을 방지한다는 것을 의미한다.

보안

다양한 실시형태의 시스템은 사용자 위장 공격을 방지하도록 설계된다. 이 시스템은 또한 아이덴티티 도용 공격을 완화시키고, 셋-업 핸드쉐이크 단계에 대한 인증 검사 비용을 감소시키도록 설계된다. 어떠한 소스-의존 동작에 있어서 서비스가, 확립된 아이덴티티 (예를 들어, 고객 id) 를 사용하는 한, 시스템은 안전하다. 서비스하기 위해 평문 id들을 전달하는 기형 서비스는 이 수준에서 보호될 수 없지만; 대신 적절한 API 설계 및 별도의 서비스 감사에 의해 완화되어야 한다.

예시적인 실시형태에서 클라이언트/서버 통합

큐에 대한 모든 생성, 가입, 및 가입해제는, 일부 XMLRPC 또는 다른 API 호출의 부작용으로, 서버 측에서 발생한다. 예를 들어, 사용자 로그인 프로세스의 일부로서, 로그인 프로세스는 사용자의 시스템 채팅과 버디-상태 큐를 생성하고 사용자를 이러한 채팅 및 상태 큐에 가입시킬 수 있다. 큐에 가입할 경우, 3개의 플래그를 지정할 수 있다:

● 큐가 이미 존재하지 않는 경우 당신이 큐를 생성할지 안 할지 여부 (즉, 당신의 버디상태에 가입할 경우 참, 당신 친구의 버디상태에 가입하는 경우 거짓)

● 당신이 큐에 대하여 다른 가입자들을 아는데 관심이 있는지 여부

● 당신이 "킵-얼라이브" 참여인지 여부; 당신의 존재가 큐의 존재를 제어해야 하는지 여부 (다시, 당신의 버디상태에 대한 것이면 참, 친구의 버디상태에 대한 것이면 거짓)

성공적인 가입은 네트워크 상의 "큐 가입" 메시지를 클라이언트에게 생성하는데, 이는, 클라이언트 세션이 XMLRPC 호출에서 발생한 큐 가입을 학습하는 방법이다. 직접 TCP 접속이 그 클라이언트에 대하여 확립되지 않은 경우, 게이트웨이는 큐 가입을 기억하여 클라이언트가 접속하지 않은 경우, 모든 가입 메시지가 전송될 수 있다. 이것은, 클라이언트가 TCP를 통해 게이트웨이로 접속하기 전에 하는 사용자 로그인 동안 발생하는 큐 가입의 경우를 처리한다. 비슷하게, 가입해제는 "큐 가입해제됨" 메시지를 클라이언트에게 전송할 것이다.

예시적인 실시형태의 클라이언트 프로세싱

처음에, 서비스가 클라이언트에 등록되어 본원에 설명된 메시지 큐 시스템과 연관된 클라이언트측 프로세싱을 처리한다. 특정 실시형태에서, 클라이언트의 서비스제공자 (ServiceProvider) 모듈은, 메시지 큐 시스템과 연관된 클라이언트측 프로세싱을 처리하기 위해서, 새로운 서비스, MQManager를 등록할 수 있다. 클라인언트 로그인 이후, MQManager 서비스는 클라인언트에 관한 인증 및 접속 프로세스를 시작시킬 필수 데이터를 가질 수 있다. 특정 실시형태의 로그인 프로세스에 관한 보다 상세한 설명은 아래를 참조한다.

큐에 관심있는 오브젝트는 네임에 의해, MQManager를 이용하여, 그 큐에 대한 청취자로서 등록하고, 메시지 핸들러 콜백을 제공한다. 하나의 오브젝트만이 소정의 큐의 권위 있는 처리 및 소모에 책임이 있으므로, 하나의 오브젝트만이 청취하도록 허용된다. MQManager가 이미 큐 네임 X를 대기하는 청취자와 청취하기 위한 등록을 시도하는 다른 청취자를 갖는다면, MQManager는 예외를 형성할 것이다. 더 많은 오브젝트가 해당 큐에 대한 메시지 알 필요가 있는 경우, 청취 오브젝트의 메시지 핸들러는 이벤트들을 다른 청취자에게 알릴 수 있다.

MQManager는, 각각의 큐 네임에 대하여 콜백을 저장하고 MQManager가 메시지를 수신함에 따라 이러한 콜백을 호출한다. MQManager가 먼저 메시지를 디코딩하므로, 청취자의 메시지 핸들러는 메시지 오브젝트를 수신하고 비트 스트링을 수신하지 않는다. 큐 가입 메시지 그 자체는 청취자의 메시지 핸들러와 함께 전송될 것인데, 이 메시지가 초기 상태 또는 초기 참여 데이터를 포함할 수도 있기 때문이다. 또한, 청취 오브젝트는 가입의 포인트에 관심이 있을 수도 있다. 비슷하게, 가입해제 메시지가 메시지 핸들러로 전송될 수 있다. 가입해제 메시지가 수신되는 경우, 우리는 즉시 목록에서 청취자를 제거하지 않는다는 것을 주목한다. 대신, 우리는, 청취 오브젝트가 다시 가입하지 않고, 청취자가, 동일한 큐에 대한 다른 가입 요청이 발생했는지 여부를 자동으로 검출하기를 원한다. MQManager가 메시지를 수신하고, 디코딩된 메시지 오브젝트로 청취자의 콜백을 호출하는 경우, MQManager는 또한 청취한 하나의 콜백을 이용하는 오브젝트에 대하여 큐 네임을 다수의 큐들에게 전달할 수 있다. MQManager는 이 사용자로부터 비롯된 것으로 마킹되는 메시지들을 필터링 해내므로, 채팅 세션이 반향 (echo) 메시지로 처리하지 않는다.

MQManager에 의해 수신된 가입 메시지가 그 큐를 청취하는 오브젝트를 갖지 않는다면, MQManager는 큐 네임에 의해 가입 메시지를 백로그한다. 그 큐에 대하여 들어오는 후속하는 메시지는 동일한 스팟에서 백로그될 것이다. 오브젝트가 어떤 나중 포인트에서 해당 큐 네임을 청취할 것을 시도한다면, 오브젝트는, 오브젝트로 전송된 메시지들의 이 백로그된 배치 (batch) 를 즉시 가질 수 있다. 이것은, 오브젝트들이 큐 네임을 즉시 알지 않더라도, 오브젝트로 하여금 가입을 청취할 수 있게 한다. 예를 들어, 사용자가 채팅을 생성하지만, 호가 새롭게 생성된 chatId 49723942로 리턴할 때까지 새로운 채팅의 큐 네임이 "chat/49723942/메시지"라는 것은 알지 못한다. 메시지를 백로그하는 경우, 해당 큐에 대한 백로그의 가장 오래된 메시지가 시간 기간 (예를 들어, 5분) 보다 더 오래된 경우, 우리는 에러를 잘라내고, 그 큐의 백로그를 폐기하고, 그리고 그 큐에 대한 후속 메시지의 백로깅을 중단할 수 있다.

MQManager의 메시지 전송 컴포넌트 (예를 들어, sendMessage) 는 선택적인 "expectAsyncResult" 플래그를 취할 수 있다. 이 플래그와 함께 전송된 메시지는 메시지에 덧붙여지고 sendMessage에 의해 리턴되게 될 MQManager에 의해 생성된 op_id를 가질 수 있다. "expectAsyncResult"와 함께 전송된 메시지는 통과/실패 응답을 제외한 상태 메시지이다; op_id와 함께 전송된 메시지는, 메시지가 어느 op_id와 관련되는지를 명시하는 네트워크로부터 응답과, 통과/실패 결과를 비동기적으로 수신할 수 있다. sendMessage에 의해 생성된 op_id와, 그 핸들러로 전송된 후속 결과 메시지를 이용하여 호출 오브젝트가 어떤 것을 할지는 전적으로 호출 오브젝트의 책임이다. 사용의 예시에 대한 아래의 채팅 개시물을 참조한다.

다른 아웃바운드 트래픽이 없다면, MQManager는 또한 매 시간 기간 (예를 들어, 20초) 마다 TCP를 통하여 킵-얼라이브 핑의 전송을 처리할 수 있다. 다른 인바운드 트래픽이 없다면, MQManager는 또한 게이트웨이로부터 매 시간 기간 (예를 들어, 20초) 마다 킵-얼라이브 핑의 수신을 처리할 수 있다. 예상된 킵-얼라이브가 존재하지 않거나 접속이 달리 예상치 못하게 손실되는 경우, MQManager는, 소켓 오류 동안 보류되었을 수도 메시지를 비롯하여, 비접속 상태 동안 전송될 대기열의 메시지들을 명료하게 재접속시킬 수 있다. 일단 접속이 재확립되면 이러한 대기열에 있던 메시지들이 전송되어 나갈 수 있다. 재접속이 충분히 신속할 경우, 게이트웨이는 클라이언트를 위한 가입을 자동으로 유지할 수 있다. 합리적인 시간 프레임 내에서 접속이 재확립될 수 없다면 (게이트웨이가 이 클라이언트의 연장된 접속 부재가 타임아웃인 것으로 고려하고 기존의 가입을 죽일 (kill) 것이기 때문에), 클라이언트는 통상적으로 확장된 네트워크 중단에 대해 하는 것과 같이 행동하여, 사용자가 다시 서명할 것을 요구한다. 접속 경과 (lapse) 는, 인출되는 메시지로 하여금 이후의 전달을 위해 대기열에 있게 하는 유일한 것이다; op_id가 지정되지 않았다면 (예를 들어, "expectAsyncResult가" MQManager.sendMessage로 전달되었다), 게이트웨이내 sendMessage에서의 어떤 실패 또는 이를 넘어서는 것 (예를 들어, 존재하지 않는 큐로 전송하는 것, 가입되지 않았거나 기록할 수 없는 큐로 전송하는 것) 은 묵시적으로 실패일 것이다. 이 경우, 에러 결과가 다시 돌아올 것이다.

예시적인 실시형태의 로그인 프로세싱

MQManager가 serviceProvider에 의해 등록되는 경우 MQManager가 생성되더라도, MQManager는, 사용자 로그인이 완료될 때까지 TCP 접속의 확립을 시작하지 않는다. 접속이 발생한 후, 인증 프로세스가 개시된다. 특정 실시형태에서, 인증은 다음 단계를 포함하는 다단계 프로세스이다:

● 로그인되면, 클라이언트가 그 자신을 식별할 쿠키를 전송한다

● 게이트웨이는 랜덤 챌린지로 응답한다

● 클라이언트는 패스워드의 해시로 챌린지에 서명하고 서명된 챌린지를 전송한다

● 게이트웨이는 패스워드의 해시로 국부적으로 그 챌린지에 서명하고 클라이언트가 방금 서빙한 것과 이것이 일치하는지를 확인하고, 클라이언트에게 통과/실패를 나타낸다.

인증이 실패하면, 사용자는 로그인 실패와 유사한 방식으로 다시 로그인할 것을 요청받는다. 로그인 프로세스사용자의 일부로서, 로그인 컴포넌트는 시스템 채팅 큐와 버디 상태 큐를 생성하고 사용자를 시스템 채팅 큐와 버디 상태 큐에 가입시킨다. 시스템 채팅 큐와 버디 상태 큐 둘 모두에 있어서, 그 가입은 다른 가입자에 대하여 관심이 없는 것으로, 그리고 사용자가 킵-얼라이브 참여자인 것으로 표시된다. 또한, 로그인 컴포넌트는 사용자의 친구, 팬, 최근의 채팅한 사람, 사용자의 친구 모드에 나타난 그 누구든지, 이들 모두에 걸쳐 루핑하여, 사용자의 큐에 그 사용자를 가입시키고 사용자의 큐에 이들 모두를 가입시킨다. 가입이 비-생성인 것으로 표시되기 때문에, 그 자신의 큐가 없거나 사용자의 큐에 가입할 방법이 없는 오프라인 친구들에 대해서는 아무것도 발생하지 않는다. 이 가입은 또한 모두 논-킵얼라이브인 것으로 표시된다.

예시적인 실시형태의 시스템 채팅 프로세싱

특정 실시형태에서, systemchat 가입 메시지를 청취하는 관리자 오브젝트가 존재한다. systemchat 메시지를 수신하는 즉시, 관리자 오브젝트는, 소비할 모든 클라이언트를 위해 systemchat 메시지 콘텐츠를 이벤트 버스 상에 반향시킨다. 관리자 오브젝트는 가입 및 가입해제 메시지들을 반향시키지 않는다. 일 실시형태에서, 시스템 채팅 이벤트는 임의의 페이로드의 JSON의 blob를 이용하는 스트링 토큰으로서 서버로부터 온다.

예시적인 실시형태의 친구 프로세싱

클라이언트에 로그인한 직후, BuddyState 오브젝트가 활성화된다. BuddyState 오브젝트는 사용자의 버디를 관리하는 메인 버디 관리자 오브젝트이다. BuddyState 오브젝트는, 로그인 직후 사용자의 친구 목록 (버디들) 을 즉시 페치할 수 있다. 목록에 있는 각각의 버디에 있어서, BuddyState 오브젝트는 (예를 들어, 버디들 모두에 대하여 단 하나의 콜백을 이용하여) 그 친구에 대한 buddyState 큐를 청취할 수 있다. 특정 큐에 대한 가입 메시지는, 사용자의 친구가 온라인 상태로 있다는 것을 의미하고, 그 특정 큐에 대한 가입해제 메시지는, 사용자의 친구가 오프라인 상태로 있다는 것을 의미한다. 따라서, BuddyState 오브텍트 초기화 시에, 모든 친구들은 다르게 입증될 때까지 오프라인 상태에 있다. 이러한 큐를 통한 다른 메시지는 실제 버디 상태 (예를 들어, 방해금지 (DND; Do Not Disturb), 성인 전용, 잠시 비움 등) 를 사용자에게 통보할 수 있다. 온라인 상태 및 실제 버디 상태로의 업데이트가 BuddyState 오브젝트의 이벤트 시스템을 사용하여 클라이언트의 다양한 부분들로 전달될 수 있다. BuddyState 오브젝트는 또한, 사용자의 buddyState 큐를 처리하고, 사용자의 buddyState 큐로 메시지 (예를 들어, 나는 DND에 있다, 나는 이용가능하다, 나는 사인 오프 중이다 등) 를 전송할 책임이 있다. 사용자가 사인 오프한 경우, "사인 오프" 메시지가 그 buddyState 큐에 전송되므로, 사용자가 오프라인 상태가 되기 때문에 BuddyState 오브젝트는 몇몇 친구에 대하여 사인오프 메시지 또는 가입해제 메시지 중 어느 하나를 해석할 수 있다. 사용자가 사인오프 메시지 없이 사라지는 경우, 그들의 게이트웨이는 결국 그들을 타임아웃시키고 그들의 큐 모두로부터 이들을 가입해제시킨다. 사용자가 그 자신의 버디 큐에 대한 킵-얼라이브 참가자였기 때문에, 그 버디 큐는 허물어질 것이고 다른 참가자 모두는 가입해제될 것인데, 이는 다른 클라이언트가 사용자의 타임아웃을 학습하게 되는 방법이다. 심지어 가입해제가 발생한 후라도 청취자가 MQManager 주위에서 유지되기 때문에, 친구가 오프라인으로 이동하고 네트워크로부터 가입해제가 수신되는 경우, BuddyState 오브젝트는 다시 청취할 필요가 없다는 것을 주목한다. 사용자가 온라인으로 들어오는 새로운 친구를 학습한다; 왜냐하면, 그 친구의 로그인 프로세싱의 일부가 그 친구들 모두의 buddyState 큐에 가입하는 것이기 때문이다. 버디 목록이 변하기 때문에 (예를 들어, 친구 추가, 친구 제거 등), BuddyState 오브젝트는 새로운 친구에 대한 가입을 청취하고, 사용자를 가입시키거나 각각 다른 것들의 buddyState 큐로부터 사용자를 가입해제시킬 수 있다. 비슷하게, 새로운 최근 채팅에 있어서, BuddyState 오브젝트는 새로운 최근 채팅에 대한 가입을 청취하고, 최근 채팅한 사용자들 간에 적절한 가입을 생성할 수 있다.

예시적인 실시형태의 로그아웃 프로세싱

완전히 접속해제된 TCP 접속은 게이트웨이로 하여금 로그 아웃된 사용자를 모든 큐들로부터 가입해제 하게 하는데, 이는, 큐들에 대한 사용자의 킵-얼라이브 상태에 따라, 어떤 큐를 완전히 허물을 것이다. 부정 (unclean) 셧다운의 경우, 사용자의 게이트웨이는 사용자를 타임아웃시키고 동일한 단계를 수행할 것이다. 게이트웨이 충돌의 경우, 타임아웃의 기간 동안 '강력한' 가입 사용자가 존재하지 않는다면, 큐의 존재가 멈춘다.

예시적인 실시형태의 채팅 생성 프로세싱

사용자가 클라이언트에서 채팅 세션을 개시하는 경우, 클라이언트 채팅 모듈 또는 MQManager는 채팅 세션 식별자 (chatId) 를 생성할 수 있다. 이후, MQManager는 그 채팅을 위한 메시지 큐 (messageQueue) 와 상태 큐 (stateQueue) 를 생성하고 사용자를 가입시킬 수 있다. 메시지 큐는 참가자에게 관심이 있는 것으로 표시되고, 메시지 큐 및 상태 큐 둘 모두에 대해, 사용자는 킵-얼라이브 사용자인 것으로 표시되지 않는다. 최초 및 진행 중인 참가자 정보는 messageQueue뿐만 아니라, 애니메이션과 같은 실제 메시지 및 다른 채팅스트림 메시지를 통해 클라이언트의 세션 오브젝트에 양쪽 방향으로 전달된다. 최초 및 진행 중인 좌석 상태는 stateQueue를 통해 채팅 세션에 양쪽 방향으로 전달된다. 상태 큐 메시지가 되는 좌석 배정은 비동기 응답을 기대할 수 있다. 따라서, 좌석 메시지를 전송할 경우, 채팅 세션은 "expectAsyncResponse" 플래그를 참으로 설정하고, sendMessage로부터 리턴된 op_id를 저장하고, 결과 메시지가, 미래의 어떤 시점에 그 op_id에 대한 결과를 갖는 메시지 청취자 기능이 될 것을 기대한다. 예를 들어, 우리는 국부적으로 좌석을 이동시키고, 메시지를 전송하고, 채팅 세션 어딘가에 좌석 이동 및 op_id을 기록할 수 있다 (예를 들어, op_id를 포함하는 오브젝트: (cid, 구_좌석, 신_좌석). 그 소정의 op_id에 대하여 결과 메시지가 네트워크로부터 수신되는 경우, 우리는, (좌석 배정이 통과된 경우) 우리의 엔트리를 op_id를 포함하는 오브젝트의 밖으로 이동시키거나, (좌석 배정이 실패한 경우) 국부적인 좌석 이동을 원상태로 돌릴 수 있다. chatId들은 명명할 수단으로서 단지 존재할 수도 있고 특정 채팅에 대한 큐들을 고유하게 식별할 수도 있다는 것을 주목한다. 어떤 채팅을 위한 큐의 존재는 꼭 그 채팅의 존재를 나타내는 그 무엇이다.

예시적인 실시형태의 채팅 참가 프로세싱

사용자가 클라이언트에서 채팅 세션에 참가하는 경우, 클라이언트 채팅 모듈 또는 MQManager는 사용자가 참가를 시도하고 있는 chatId에 대한 messageQueue와 stateQueue로 사용자를 가입시키고, 그 가입을 논-킵-얼라이브 및 비-생성으로 표시한다. 큐들이 존재하지 않는 경우, 우리는 에러 카운터를 증가시킬 수 있다. 클라이언트 채팅 모듈 또는 MQManager는 chatId에 대한 messageQueue와 stateQueue로부터 사용자를 가입해제시킬 책임이 있을 수 있다.

예시적인 실시형태의 초대 프로세싱

특정 실시형태에서, chatgateway.attemptInvite XMLRPC 호출은 데이터베이스에 초대를 생성하는 데에, 그리고 chatGateway.checkForInvite를 호출하고, 초대를 검색하고, 수락하거나 거절 이유를 제공하도록 그 클라이언트를 지시하는 systemChat 통지를 알림을 초대받은 자에게 전송하는 데에 사용될 수 있다. 수락 또는 거절 이유는, attemptInvite 호출에 대한 동기식 리턴 값으로서 초대자에게 리턴될 수 있다. 대안적인 실시형태에서, 초대자는 systemchat 초대를 초대받은 자에게 전송할 수 있으며, 초대받은 자의 답신은 또 다른 systemChat 메시지로서 비동기식으로 초대자에게 되전송된다.

특정 예시적인 실시형태의 세부 사항

도 8을 참조하면, 예시적인 실시형태에서, 네트워크 환경에서 비-지속성 메시지의 다중 큐를 관리하기 위한 시스템 및 방법이 개시된다. 다양한 예시적인 실시형태에서, 통상적으로 호스트 사이트 (예를 들어, 웹 사이트)(110) 상에서 동작하는 애플리케이션 또는 서비스 프로그램이나 서비스가 제공되어 비-지속성 메시지를 단순화하고 용이하게 하고 호스트 사이트 (110) 로부터 사용자 플랫폼 (140) 의 복수의 사용자들 사이에서 상태가 전환된다. 이것에 의해 본원에 기재된 바와 같이 호스트 사이트 (110) 는 메시지 큐 시스템 사이트 (110) 로 간주될 수 있다. 다수의 사용자 플랫폼 (140) 은, 사용자가 콘텐츠 소비자 및/또는 콘텐츠 제공자가 될 수도 있는 복수의 메시지 스트림을 제공한다. 메시지 큐 시스템 사이트 (110) 및 사용자 플랫폼 (140) 은 메시지, 관련 콘텐츠, 및 정보를 광역 데이터 네트워크 (예를 들어, 인터넷)(120) 를 통해 통신하고 이송할 수도 있다. 메시지 큐 시스템 사이트 (110) 의 다양한 컴포넌트는 또한 종래의 인터넷 또는 근거리 네트워크 (LAN)(114) 를 통해 내부적으로 통신할 수 있다.

네트워크들 (120 및 114) 은 일 컴퓨팅 디바이스를 다른 컴퓨팅 디바이스와 연결하도록 구성된다. 네트워크들 (120 및 114) 은 일 전자 디바이스로부터 다른 전자 디바이스로 정보를 통신하기 위한 컴퓨터 판독 가능 매체의 모든 형태를 채용하기 위해 사용될 수도 있다. 네트워크 (120) 는 LAN (114) 이외의 인터넷, 광역 네트워크 (WAN), USB (Universal Serial Bus) 포트를 통해 같은 적접 연결, 다른 형태의 컴퓨터 판독가능 매체, 또는 그 임의의 조합을 포함할 수 있다. 서로 다른 아키텍처 및 프로토콜을 기반으로 하는 것을 포함하는 LAN들의 상호접속된 세트 상에서, 라우터는 LAN들 간의 링크로서 역할을 하여, 메시지가 컴퓨팅 디바이스들 사이에서 전송될 수 있게 한다. 또한, LAN내의 통신 링크들은 통상적으로 이중 연선 또는 동축 케이블을 포함하는 반면, 네트워크들 간의 통신 링크는 아날로그 전화선, T1, T2, T3 및 T4를 포함하는 전체 또는 부분 전용 디지털선, ISDN (Integrated Services Digital Networks), 디지털 사용자 (User) 라인 (DSL), 위성 링크를 포함한 무선 링크, 또는 당업자에게 알려진 다른 통신 링크를 사용할 수도 있다. 또한, 원격 컴퓨터 및 다른 관련 전자 디바이스는 모뎀 및 임시 전화 링크를 통해 LAN 또는 WAN 중 어느 하나에 원격으로 접속될 수 있다.

네트워크들 (120 및 114) 은 독립형 애드-혹 네트워크를 추가적으로 오버레이할 수도 있는 다양한 무선 서브-네트워크들 중 어느 것을 더 포함하여 인프라스트럭처-지향 접속을 제공할 수도 있다. 이러한 서브-네트워크는 메쉬 네트워크, 무선 LAN (WLAN) 네트워크, 셀룰러 네트워크 등을 포함할 수도 있다. 네트워크들 (120 및 114) 은 또한 단말기, 게이트웨이, 라우터, 및 무선 통신 링크 또는 무선 송수신기에 의해 접속된 기타의 자율 시스템을 포함할 수도 있다. 이러한 커넥터는, 네트워크들 (120 및 140) 의 토폴로지가 신속하게 변경될 수 있도록, 그들 자신을 자유롭게 그리고 무작위로 이동시키고 임의로 체계화하도록 구성될 수도 있다.

네트워크들 (120 및 114) 은 또한 셀룰러 시스템용의 2 세대 (2G), 2.5 세대, 3 세대 (3G), 4 세대 (4G) 무선 액세스, WLAN, 무선 라우터 (WR) 메시 등을 비롯한 다수의 무선 기술을 사용할 수도 있다. 2G, 3G, 4G 및 장래의 액세스 기술과 같은 액세스 기술은 다양한 정도의 이동성을 이용하여 하나 이상의 클라이언트 디바이스 (141) 와 같이, 모바일 디바이스를 위한 광역 커버리지를 가능하게 할 수도 있다. 예를 들어, 네트워크들 (120 및 114) 은 GSM (Global System for Mobile communication), GPRS (General Packet Radio Services), EDGE (Enhanced Data GSM Enviroment), 광대역 코드 분할 다중 접속 (WCDMA), CDMA2000 등과 같은 무선 네트워크 액세스를 통한 무선 접속을 가능하게 할 수도 있다. 네트워크들 (120 및 114) 은 또한 TCP/IP, UDP, SIP, SMS, RTP, WAP, CDMA, TDMA, EDGE, UMTS, GPRS, GSM, LTE, UWB, WiMax, IEEE 802.11x 등을 포함한 다양한 다른 유선 및 무선 통신 프로토콜에 의한 사용을 위해 구성될 수도 있다. 본질적으로, 네트워크들 (120 및 114) 은 사실상, 정보가 일 컴퓨팅 디바이스와 다른 컴퓨팅 디바이스, 네트워크 등 사이에서 트래블링할 수도 있게 하는 임의의 유선 및/또는 무선 통신 메커니즘을 포함할 수도 있다. 일 실시형태에서, 네트워크 (114) 는, 예를 들어, 비지니스 데이터 센터 내에서, 방화벽 (미도시) 뒤에 구성되는 LAN을 나타낼 수도 있다.

사용자 플랫폼 (140) 은 네트워크 전송가능 디지털 센터의 임의의 다양한 제공자를 포함할 수도 있다. 통상적으로, 사용되는 파일 포맷은 XML이지만, 다양한 실시형태들은 이것으로 제한되지 않으며, 다른 파일 포맷이 사용될 수도 있다. 예를 들어, HTML/XML 이외의 다른 피드 포맷 또는 오픈/스탠다드 피드 포맷 이외의 포맷이 다양한 실시형태에 의해 지원될 수 있다. PDF (Portable Document Format) 와 같은 전자식 파일 포맷, 오디오 (예를 들어, 동영상 전문가 그룹 오디오 계층 3 - MP3 등), 비디오 (예를 들어, MP4 EMD) 및 특정 콘텐츠 사이트들에 의해 정의된 임의의 소유권 교환 포맷이 본원에 기술된 다양한 실시형태에 의해 지원될 수 있다. 배급된 콘텐츠는, 뉴스 피드, 이벤트 목록, 보도 기사, 블로그 콘텐츠, 헤드라인, 프로젝트 업데이트, 공개 토론으로부터의 발췌부분, 사업 또는 정부 정보 등을 포함하지만, 이것으로 제한되지 않는다. 청구범위를 포함한 본 출원 전체에 걸쳐서 사용된 바와 같이, 용어 "피드"는 때때로, 사용자 플랫폼 (140) 으로부터의 콘텐츠 액세스를 가능하게 하는 임의의 메커니즘에 속하는 채널을 지칭한다.

특정 실시형태에서, 하나 이상의 클라이언트 디바이스 (141) 를 갖는 사용자 플랫폼 (140) 은 사용자가 메시지 큐 시스템 사이트 (110) 및 네트워크 (120) 를 통해 다른 사용자 플랫폼 (140) 으로부터의 콘텐츠에 액세스할 수 있게 한다. 클라이언트 디바이스 (141) 는 사실상, 네트워크 (120) 과 같은 네트워크를 통해 정보를 전송하고 수신하도록 구성되는 임의의 컴퓨팅 디바이스를 포함할 수도 있다. 이러한 클라이언트 디바이스 (141) 는 셀룰러 전화기, 스마트폰, 디스플레이 페이저, 무선 주파수 (RF) 디바이스, 적외선 (IR) 디바이스, GPS (Global Positioning Device), PDA (Personal Digital Assistants), 휴대용 컴퓨터, 착용 컴퓨터, 태블릿 컴퓨터, 앞의 디바이스들 중 하나 이상을 결합한 통합 디바이스 등과 같은 휴대용 디바이스 (144 또는 146) 을 포함할 수도 있다. 클라이언트 디바이스 (141) 는 또한 개인 컴퓨터 (142), 멀티프로세서 시스템, 마이크로프로세서-기반 또는 프로그램가능한 가전제품, 네트워크 PC 등과 같은 다른 컴퓨팅 디바이스를 포함할 수도 있다. 이와 같이, 클라이언트 디바이스 (141) 는 능력 및 특징 면에서 광범위하게 다양하다. 예를 들어, 셀 폰과 같이 구성된 클라이언트 디바이스는 텍스트만 디스플레이될 수도 있는 모노크롬 LCD 디스플레이의 몇 라인 및 숫자 키패드를 구비할 수도 있다. 다른 실시예에서, 웹-인에이블 클라이언트 디바이스는 터치 민감성 스크린, 스타일러스, 및 텍스트와 그래픽 둘 모두를 디스플레이할 수도 있는 컬러 LCD 디스플레이의 여러 라인을 구비할 수도 있다. 또한, 웹-인에이블 클라이언트 디바이스는 무선 애플리케이션 프로토콜 메시지 (WAP), 및/또는 유선 애플리케이션 메시지 등을 수신하고 전송하도록 인에이블된 브라우저 애플리케이션을 포함할 수도 있다. 일 실시형태에서, 브라우저 애플리케이션은 HTML (HyperText Markup Language), 다이나믹 HTML, HDML (Handheld Device Markup Language), WML (Wireless Markup Language), WML스크립트, 자바스크립트, xHTML (EXtensible HTML), 콤팩트 HTML (CHTML) 등을 사용하여 메시지를 디스플레이하고 전송하도록 인에이블된다.

클라이언트 디바이스 (141) 는 또한 네트워크 통신을 통해 다른 컴퓨팅 디바이스로부터 콘텐츠 또는 메시지를 수신하도록 구성되는 적어도 하나의 클라이언트 애플리케이션을 포함할 수도 있다. 클라이언트 애플리케이션은, 본문 콘텐츠, 그래피컬 콘텐츠, 비디오 콘텐츠, 오디오 콘텐츠, 경보, 메시지, 통지 등을 제공하고 수신하는 능력을 포함할 수도 있다. 또한, 클라이언트 디바이스 (141) 는 또한, 예를 들어, 단문 메시지 서비스 (SMS), 직접 메시징 (예, 트위터), 이메일, 멀티미디어 메시지 서비스 (MMS), 인스턴트 메시징 (IM), 인터넷 중계 채팅 (IRC), mIRC, 재버 (Jabber), 향상된 메시징 서비스 (EMS), 텍스트 메시징, 스마트 메시지, OTA (Over the Air) 메시징 등을 통해서, 다른 컴퓨팅 디바이스 등 간에 메시지를 통신하고/하거나 수신하도록 구성될 수도 있다.

클라이언트 디바이스 (141) 는 또한, 디바이스의 사용자로 하여금 적어도 하나의 메시지 소스에 가입할 수 있게 하도록 클라이언트 애플리케이션이 구성되는 무선 애플리케이션 디바이스 (148) 을 포함할 수도 있다. 이러한 가입은, 사용자 플랫폼 (140) 에서의 사용자로 하여금 메시지 콘텐츠 중 적어도 일부에서 클라이언트 디바이스 (141) 를 통해 수신할 수 있게 한다. 이러한 콘텐츠는 인스턴트 메시지, 트위터 트윗, 게시물, 주식 피드, 뉴스 기사, 개인 광고, 쇼핑 목록 가격, 이미지, 검색 결과, 블로그, 스포츠, 날씨 리포트 등을 포함하지만, 이것으로 제한되지 않는다. 또한, 콘텐츠는 IM, SMS, 트위터, 페이스북, MMS, IRC, EMS, 오디오 메시지, HTML, 이메일, 또는 다른 메시징 애플리케이션을 비롯한 임의의 다양한 전달 메커니즘을 이용하여 클라이언트 디바이스 (141) 에 제공될 수도 있다. 특정 실시형태에서, 본원에 기재된 바와 같은 콘텐츠 가입을 위해 사용된 애플리케이션 실행가능 코드 그 자체는, 네트워크 (120) 를 통해 무선 애플리케이션 디바이스 (148) 로 다운로드될 수 있다.

어떤 경우, 사용자 플랫폼 (140) 에서의 사용자는 클라이언트 디바이스(들)(141) 에서 이용가능한 모든 메커니즘들에 의해 제공된 특정 콘텐츠 및/또는 콘텐츠 채널에 가입할 수 있다. 본원에 기재된 다양한 실시형태들에서, 호스트 사이트 (110) 는 프로세싱된 정보를 채용하여, 다양한 전달 메커니즘을 이용하여 콘텐츠 채널 정보를 사용자에게 전달할 수 있다. 예를 들어, 콘텐츠 채널 정보는, 몇 가지만 예를 들면 이메일, 단문 메시지 서비스 (SMS), 무선 애플리케이션, 및 직접 메시징 (예를 들어, 트위터) 으로 전달될 수 있다. 또한, 콘텐츠 채널 정보는 사용자로부터의 요청에 응답하여 사용자에게 전달될 수 있다.

계속해서 도 8을 참조하면, 메시지 큐 시스템 (200), 인트라넷 (114) 및 메시지 큐 시스템 데이터베이스 (105) 를 포함하는 예시적인 실시형태의 호스트 사이트 (110) 이 도시된다. 메시지 큐 시스템 (200) 은 또한 게이트웨이 (12), 메시지 큐 노드 (14), 슈퍼바이저 (16), 트랜슬레이터 (17), 상태 관리자 (18), 및 로드 밸런서 (22) 를 포함할 수 있다. 이러한 모듈들 각각은 호스트 사이트 (110) 상에서 동작하는 메시지 큐 시스템 (200) 의 실행가능 환경 내에서 실행하는 소프트웨어 컴포넌트들로서 구현될 수 있다. 예시적인 실시형태의 이러한 모듈들 각각은 본원에 제공된 도면과 결합하여 보다 상세하게 상술되었다.

이제, 도 9를 참조하면, 다양한 실시형태들이 동작할 수도 있는 네트워크 시스템의 다른 예시적인 실시형태가 도시된다. 도시된 실시형태에서, 호스트 사이트 (110) 은 메시지 큐 시스템 (200) 을 포함하는 것으로 도시된다. 메시지 큐 시스템 (200) 은 기능성 컴포넌트 (12 내지 22) 를 포함하는 것으로 도시된다. 특정 실시형태에서, 호스트 사이트 (110) 는 또한, 사용자가 사용자 인터페이스 또는 웹 인터페이스를 통해 호스트 사이트 (110) 와 상호작용할 수도 있게 하는 웹 인터페이스를 구비한 웹 서버 (904) 를 포함할 수도 있다. 호스트 사이트 (110) 는 또한, 호스트 사이트 (110) 가 계획식 또는 자동식 데이터 이송 레벨에서 다른 네트워크 엔티티와 상호작용할 수도 있게 하는 애플리케이션 프로그래밍 인터페이스 (API)(902) 를 포함할 수도 있다. API (902) 및 웹 인터페이스 (904) 는 직접 또는 인터페이스 (906) 를 통해 메시지 큐 시스템 (200) 과 상호작용하도록 구성될 수도 있다. 메시지 큐 시스템 (200) 은 직접 또는 인터페이스 (906) 를 통해 데이터 저장 디바이스 (105) 에 액세스하도록 구성될 수도 있다.

도 10은 본원에 기재된 바와 같이 메시지 큐 시스템의 예시적인 실시형태를 도시하는 프로세싱 흐름도이다. 예시적인 실시형태의 방법은: 게이트웨이 프로세스에서 비-지속성 메시지를 수신하는 단계로서, 상기 메시지는 명명된 큐를 나타내는 정보를 포함하는, 상기 비-지속성 메시지를 수신하는 단계 (프로세싱 블록 1010); 데이터 프로세서를 사용함으로써, 명명된 큐의 일관된 해시의 사용에 의해 명명된 큐를 큐 노드로 맵핑하는 단계 (프로세싱 블록 1020); 큐 노드에서 메시지를 큐 프로세스로 맵핑하는 단계 (프로세싱 블록 1030); 큐 프로세스를 사용함으로써, 가입자 게이트웨이의 목록에 액세스하는 단계 (프로세싱 블록 1040); 및 메시지를 목록의 가입자 게이트웨이들 각각으로 라우팅하는 단계 (프로세싱 블록 1050) 를 포함한다.

도 11은 실행되는 경우 머신으로 하여금, 본원에 논의된 방법들 중 임의의 하나 이상을 수행하게 할 수도 있는 명령들의 세트가 내부에 있는 컴퓨터 시스템 (700) 의 예시적인 형태의 머신의 다이어그램 표현을 도시한다. 대안적인 실시형태에서, 머신은 독립형 디바이스로서 동작하거나 다른 머신들에 접속 (예를 들어, 네트워크화) 될 수도 있다. 네트워크화된 디플로이먼트에서, 머신은 서버-클라이언트 네트워크 환경에서 서버 또는 클라이언트 머신의 능력 안에서 작동하거나, 피어-투-피어 (또는 분산) 네트워크 환경에서 피어 머신으로서 동작할 수도 있다. 머신은 개인용 컴퓨터 (PC), 태블릿 PC, 셋톱 박스 (STB), 개인용 디지털 보조기 (PDA), 휴대 전화, 웹 어플라이언스, 네트워크 라우터, 스위치 또는 브리지, 또는 그 기계에 의해 취해질 동작을 지정하는 명령들의 세트 (순차적 또는 기타) 를 실행할 수 있는 어떤 머신일 수도 있다. 또한, 하나의 머신만을 설명하였지만, 용어 "머신"은 또한 본원에 논의된 어떤 하나 이상의 방법들을 실시할 명령들의 세트 (또는 다수의 세트) 를 개별적으로 또는 공동으로 실행하는 머신들의 임의의 집합을 포함하도록 사용될 수 있다.

예시적인 컴퓨터 시스템 (700) 은, 데이터 프로세서 (702)(예를 들어, 중앙 처리 장치 (CPU), 그래픽 처리 장치 (GPU), 또는 둘 모두), 메인 메모리 (704) 및 정적 메모리 (706) 를 포함하며, 이들은 서로 버스 (708) 를 통해 통신한다. 컴퓨터 시스템 (700) 은 또한, 비디오 디스플레이 유닛 (710)(예를 들어, 액정 디스플레이 (LCD) 또는 음극 선관 (CRT)) 을 포함할 수도 있다. 컴퓨터 시스템 (700) 은 입력 디바이스 (712)(예를 들어, 키보드), 커서 제어 디바이스 (714) (예를 들어, 마우스), 디스크 드라이브 유닛 (716), 신호 발생 디바이스 (718)(예를 들어, 스피커) 및 네트워크 인터페이스 디바이스 (720) 를 포함한다.

디스크 드라이브 유닛 (716) 은 본원에 기재된 임의의 하나 이상의 방법 또는 기능을 구현하는 하나 이상의 명령들의 세트 (예를 들어, 소프트웨어 (724)) 가 저장된 비일시적 머신-판독가능 매체 (722) 를 포함한다. 명령들 (724) 은 컴퓨터 시스템 (700) 에 의한 그 실행 동안 메인 메모리 (704), 정적 메모리 (706) 내에, 및/또는 프로세서 (702) 내에 완전히 또는 적어도 부분적으로 상주할 수도 있다. 메인 메모리 (704) 및 프로세서 (702) 는 또한 머신-판독가능 매체를 구성할 수도 있다. 명령들 (724) 은 또한 네트워크 인터페이스 디바이스 (720) 를 경유하여 네트워크 (726) 를 통해 전송되거나 수신될 수도 있다. 예시적인 실시형태에서는 머신-판독가능 매체 (722) 가 하나의 매체인 것으로 도시되었지만, 용어 "머신-판독가능 매체"는 하나 이상의 명령들의 세트를 저장하는 하나의 비일시적 매체 또는 다수의 매체 (중앙 또는 분산 데이터베이스, 및/또는 연관 캐시 및 서버) 를 포함하도록 사용된다. 용어 "컴퓨터-판독가능 매체"는 또한, 임의의 비일시적 매체 또는 비일시적 또는 반(semi)비일시적 매체를 생성하기 위해 협력하는 일시적 매체의 조합을 포함하는 것으로 사용될 수 있으며, 비일시적 또는 반(semi)비일시적 매체는 머신에 의해 실행하기 위한 명령들의 세트를 저장, 인코딩, 또는 운반할 수 있고 머신으로 하여금 다양한 실시형태의 임의의 하나 이상의 방법을 수행하게 하거나, 이러한 명령들의 세트에 의해 사용되거나 명령들의 세트와 연관된 데이터 구조물을 저장, 인코딩 또는 운반할 수 있다. 따라서, 용어 "머신-판독가능 매체"는 고체 상태 메모리, 광학 매체, 및 자성 매체를 포함하는 것으로 사용될 수 있지만, 이것으로 제한되지 않는다.

독자가 빠르게 본 기술 개시물의 유형을 확인할 수 있게 하는 요약서를 요구하는, 37 C.F.R.§1.72 (b) 를 준수하기 위해서, 본 개시의 요약서를 제공한다. 청구의 범위 또는 의미를 해석하거나 제한하는데 사용되어서는 안 된다는 것임을 이해함으로써 요약서를 제출한다. 이외에도, 전술한 상세한 설명에서, 다양한 특징들이 본 개시의 간소화의 목적으로 하나의 실시형태에서 함께 그룹화된다. 본 개시의 방법은, 청구된 실시형태가 각각의 청구항에 명시적으로 인용된 것보다 더 많은 특징을 요구한다는 의도를 반영하는 것으로 해석되지 않는다. 오히려, 다음의 청구범위가 반영하는 바와 같이, 신규한 주제는 하나의 개시된 실시형태의 모든 특징들보다 적게 존재한다. 따라서 다음과 같은 청구범위는 상세한 설명에 포함되며, 각각의 청구항은 별개의 실시형태로서 그 자체의 지위가 있다.

Claims

게이트웨이 프로세스에서 비-지속성 메시지를 수신하는 단계로서, 상기 비-지속성 메시지는 명명된 큐를 나타내는 정보를 포함하는, 상기 비-지속성 메시지를 수신하는 단계;
데이터 프로세서를 사용함으로써, 상기 명명된 큐의 일관된 해시의 사용에 의해 상기 명명된 큐를 큐 노드로 맵핑하는 단계;
상기 큐 노드에서 상기 비-지속성 메시지를 큐 프로세스로 맵핑하는 단계;
상기 큐 프로세스를 사용함으로써, 가입자 게이트웨이의 목록에 액세스하는 단계; 및
상기 비-지속성 메시지를 상기 목록에 있는 상기 가입자 게이트웨이들 각각으로 라우팅하는 단계를 포함하는, 방법.
제 1 항에 있어서,
게이트웨이와 클라이언트 간의 지속성 접속을 유지하는 단계를 포함하는, 방법.
제 2 항에 있어서,
상기 클라이언트를 상기 명명된 큐에 대한 청취자로서 등록하는 단계를 포함하는, 방법.
제 3 항에 있어서,
상기 등록하는 단계는 메시지 핸들러 콜백을 제공하는 단계를 포함하는, 방법.
제 1 항에 있어서,
상기 명명된 큐를 상기 큐 노드로 맵핑하는 것을 관리하기 위해서 슈퍼바이저 프로세스를 이용하는 단계를 포함하는, 방법.
제 1 항에 있어서,
상기 큐 노드에서 메시지 스트림들과 상태 스트림들을 마운팅하는 단계를 포함하는, 방법.
제 1 항에 있어서,
핫 부가 노드 (hot add node) 프로세스에서 상기 큐 노드의 상태를 새로운 큐 노드로 이동시키는 단계를 포함하는, 방법.
제 1 항에 있어서,
상기 게이트웨이 프로세스에서 트랜슬레이터 프로세스를 통해 상기 비-지속성 메시지를 수신하는 단계를 포함하는, 방법.
제 1 항에 있어서,
상기 큐 노드의 상태를 업데이트하기 위해서 상태 관리자 서비스를 이용하는 단계를 포함하는, 방법.
제 1 항에 있어서,
로그인 시에 사용자를 시스템-채팅 큐와 버디-상태 큐에 가입시키는 단계를 포함하는, 방법.
데이터 프로세서;
상기 데이터 프로세서와의 데이터 통신 시, 네트워크에 액세스하기 위한 네트워크 접속부; 및
메시지 큐 시스템 모듈을 포함하고,
상기 메시지 큐 시스템 모듈은, 상기 데이터 프로세서에 의해 실행가능하여,
게이트웨이 프로세스에서, 명명된 큐를 나타내는 정보를 포함하는 비-지속성 메시지를 수신하고;
상기 명명된 큐의 일관된 해시의 사용에 의해 상기 명명된 큐를 큐 노드로 맵핑하고;
상기 큐 노드에서 상기 비-지속성 메시지를 큐 프로세스로 맵핑하고;
상기 큐 프로세스를 사용함으로써, 가입자 게이트웨이의 목록에 액세스하고; 그리고
상기 비-지속성 메시지를 상기 목록에 있는 상기 가입자 게이트웨이들 각각으로 라우팅하는, 시스템.
제 11 항에 있어서,
게이트웨이와 클라이언트 간의 지속성 접속을 유지시키도록 더 구성되는, 시스템.
제 12 항에 있어서,
상기 클라이언트를 상기 명명된 큐에 대한 청취자로서 등록하도록 더 구성되는, 시스템.
제 13 항에 있어서,
상기 등록하는 것은 메시지 핸들러 콜백을 제공하는 것을 포함하는, 시스템.
제 11 항에 있어서,
상기 명명된 큐를 상기 큐 노드로 맵핑하는 것을 관리하기 위해서 슈퍼바이저 프로세스를 이용하도록 더 구성되는, 시스템.
제 11 항에 있어서,
상기 큐 노드에서 메시지 스트림들과 상태 스트림들을 마운팅하도록 더 구성되는, 시스템.
제 11 항에 있어서,
핫 부가 노드 프로세스에서 상기 큐 노드의 상태를 새로운 큐 노드로 이동시키도록 더 구성되는, 시스템.
제 11 항에 있어서,
상기 게이트웨이 프로세스에서 트랜슬레이터 프로세스를 통해 상기 비-지속성 메시지를 수신하도록 더 구성되는, 시스템.
제 11 항에 있어서,
상기 큐 노드의 상태를 업데이트하기 위해서 상태 관리자 서비스를 이용하도록 더 구성되는, 시스템.
제 11 항에 있어서,
로그인 시에 사용자를 시스템-채팅 큐와 버디-상태 큐에 가입시키도록 더 구성되는, 시스템.
머신에 의해 실행되는 경우, 명령들을 포함하는 비일시적 머신-사용가능 저장 매체로서,
상기 명령들은, 상기 머신으로 하여금,
게이트웨이 프로세스에서, 명명된 큐를 나타내는 정보를 포함하는 비-지속성 메시지를 수신하게 하고;
상기 명명된 큐의 일관된 해시의 사용에 의해 상기 명명된 큐를 큐 노드로 맵핑하게 하고;
상기 큐 노드에서 상기 비-지속성 메시지를 큐 프로세스로 맵핑하게 하고;
상기 큐 프로세스를 사용함으로써, 가입자 게이트웨이의 목록에 액세스하게 하고; 그리고
상기 비-지속성 메시지를 상기 목록에 있는 상기 가입자 게이트웨이들 각각으로 라우팅하게 하는, 비일시적 머신-사용가능 저장 매체.