XMPP 기반 채팅 서비스 아키텍처에 대한 제안 사항은 무엇입니까?

Question

내 목표는 채팅 서비스를 만드는 것입니다. 또한 여러 개의 개별 채팅방이 필요합니다.

스케일링 /로드 밸런싱을 위해 XMPP를 사용하는쪽으로 기울이고 있습니다. 의 내가 다른 하나의 클라이언트에서 메시지를 보낼한다고 가정 해 봅시다 나는 기사 here을 읽고, 나는

에서 찾고 있습니다. 이 다이어그램에 따르면

1) 보낸 사람의 메시지를 보낸 사람의 XMPP 서버로 보냅니다. 2) 보낸 사람의 XMPP 서버가 MUC 서버에 메시지를 릴레이합니다. 3) MUC 서버는 수신자가 연결되어있는 서버를 결정하고 거기에 메시지를 중계합니다.

(내가 틀렸다면 정정 해줘)

두 질문 :

1)이 기사는 여러 서버를 통해 MUC 클러스터링을 시사한다. 이것은 a) 발신자와 수신자 서버를 통해 MUC 서버의 상태를 미러링하거나 b) 다이어그램의 MUC 섹션을 여러 서버로 전환하고 발신자와 수신자 서버가 투명하게 그 클러스터와 통신 하는지를 의미합니까?

2) 사용자가 처음 노드에 연결할 때 네트워크를 통해 사용자를 바인딩 할 서버를 어떻게 알 수 있습니까? 이것을 위임 할 입장 기계가 있습니까?

Answer 1

시스템 진입 점과 관련하여 클라이언트는 기본 진입 점 또는 DNS SRV 설정 (즉, 사용자 rcv)에서 지정한 항목을 사용하고 xmpp 서버 포트 5222 (c2s)를 통해서만 데이터를 보냅니다. 또는 5269 (s2s)입니다.

그래서 MUC 메시지 스탠자 흐름은 (내가 질문을 잘못 해석 된 경우께요 알고)과 같이 표시됩니다 :

A) 송신자/수신자가 모두 서버에 등록 된 경우

sender@myjabber.com > muc.myjabber.com < - -> myjabber.com:5222 < -> receiver@myjabber.com

b) 보낸 경우 @ gmail.com 사용자 < -> myjabber.com:5222 < 및 Rcvr @ myjabber.com 사용자

sender@gmail.com < -> talk.google.com:5222 < -> myjabber.com:5269 < -> muc.myjabber.com < -> myjabber.com:5222 < -> 리시버 @ myjabber.com