메신저 서버를 만든다면

후배 d* 가 물어본 질문.

d |
d | 질문
d | 메신저를 개발한다고 했을 때
d | 염두에 둬야 할 점은 뭐가 있을까요?
d | 음… 일단 다른 메신저의 소스는 구해놨고, 네트워크 좀 더 공부해야 하려나…

…여기에 대한 몇몇 의견.

p | 부가기능 어디까지 지원하나요
d | 그냥 노멀하고 스탠다드한 메신저라고 가정하지요.
p | 파일전송이 되냐 안되냐, 게임(…)이 되냐 안 되냐에 따라서
p | 레이어가 차이가 있을 것 같지만
p | 저도 네트워크를 잘 아는 건 아니므로
ㅃ | 1:1 대화에서 다대다 대화가 될 경우를 염두에 두면 좋지 않을까

내 경우에는 보통 이런 결정을 내린다 — 특히 개발 기간이 짧아야 한다거나 한 경우에는 더더욱.

있는 솔루션 쓰자 — 이 경우엔 IRC 서버를.

rein | d: IRC서버 고쳐서 써
rein | …
d | …
rein | 아니 농담이 아닌데
rein | 인증이랑 초기 접속만 맞게 수정하고
rein | 나머지는 IRC / IRC query 기능이잖
rein | 잘 알려져있고
rein | 분산 서버 구현도 알려져있고
rein | 테스트되었고
rein | 뭘 더 바라는데

사실 이런 경우엔 아주 이상적인 솔루션이기도한 IRC 서버가 있다. 우리가 만들어야하는 물건 중 상당수는 이미 발명된 경우가 대부분이고 — 많은 경우 수차례 반복된다 — 그 중 적합한게 적어도 하나는 있다.[1]

메신저 서버가 가져야할 안정성 문제[2] , 확장성 문제[3] 가 해결되어있으니 그냥 쓰면 되지 않나 싶다.[4]

재작년에 채팅 서버군 솔루션이란걸 볼 기회가 있었는데 보고나서의 내 논평은,

그냥 IRC 서버 쓰시죠

뭐 그러하다.[5]

  1. 특히나 수정을 할 수 있고, 라이센스 문제 없이 쓸 수 있는 것도 있을 것이다 []
  2. 설마 메신져 서버가 몇 일마다 죽는다거나, 점검이 필요하다고 하면 이해해줄 사용자는 없겠지 []
  3. IRC 서버는 잘 정의된(성능이야 둘째로 쳐도) 그리고 오랜 기간 테스트된 분산 서버 시스템이고 []
  4. 특히나 테스트 문제는 소프트웨어 개발에서 가장 중요하고 가치있는 부분인데 이게 대충 해결되는 솔루션이다 []
  5. 그러고보니 이 대화 역시 IRC에서… []

Author: rein

나는 ...

5 thoughts on “메신저 서버를 만든다면”

  1. “rein | 인증이랑 초기 접속만 맞게 수정하고”
    이것도 검증된 사용자만 채팅을 허용하려면 채널에 +snim 정도 걸면 되지 않을까요.

  2. xenosoz / 것도 좋군 :)

    Dish / 그리고 테스트 되지 않은 코드에 괴로워하고, 늘어나는 개발기간에 슬퍼하겠지…라는게 내 생각.

  3. luzluna / 아마 jabber를 말하는거라고 추정되는데, 새거라고 좋은게 아닙니다.
    * jabber의 확장성이 필요한 것도 아니고
    * jabber 전체를 완전히 구현한 구현체가 현 시점에 없으며,
    * jabber 특유의 분산화된 처리와 트래픽 복사(게임의 경우 중앙 인증서버와 게임서버와의 heartbeat이 있어서 이게 무의미)
    * 확장성(scalability) 문제
    로 이런 응용에 쓸 수 없습니다.

    반면에 IRC서버는 확장성 있는 프로토콜은 아니지만 서버만 믿을 수 있으면되는 중앙에 아주 의존적인 방식이고, 트래픽은 서버간 통신으로 복사를 줄이는 구조라서(heartbeat은 게임 서버로 대체) 훨씬 효율적으로 사용할 수 있습니다. 즉, jabber같은 새 기술을 쓸 의미가 없는거죠 응용에 맞질 않으니.

    TFRC 나온다고 UDP가 바로 버려지는게 아니죠. 필요한 곳에 필요한것만 쓰면 될 뿐

Leave a Reply