4581
2015-09-11 10:27:27
1
여러 방법이 있긴 한데, 메시징 관련해서 요즘 가장 많이 쓰이는건 HTTP위에서 long-polling 이라고 하여 일종의 홀디드 커넥션을 하는게 있고요
다만 long-poling의 경우 TCP 연결이 timeout시까지 유지되어야 해서 백그라운드로 넘어갈 경우 연결이 유실되거나 배터리 소모가 커질 수 있습니다.
또는 클라이언트 측에서 GCM으로 푸시를 받으면, 백그라운드 서비스에서 해당 푸시를 받았다는 응답을 서버로 보내는 방법도 있습니다.
서버측에서는 푸시에 대한 응답이 일정 시간(예: 5분) 내에 돌아오지 않으면, 수신을 못한걸로 간주하고 다시 푸시를 보내구요.
이 경우 푸시를 받을 때만 커넥션을 열기 때문에 비교적 배터리 소모가 적은 장점이 있으나, 아무래도 백그라운드시 실시간성이 좀 떨어고 모바일 장치가 꺼져 있을경우 서버가 푸시를 무제한으로 보낸다던지, 클라이언트가 푸시 중복수신한다던지 등에 대한 별도 처리를 해 주어야 합니다.
일단 위 두가지를 섞어 써야 상업적으로 쓸만한 메시징 전송보장이 가능합니다.
혹은 아예 전문적으로 메시징을 구현한다고 하면 MQTT라고 하여 임베디드나 모바일 환경에서 메시징큐를 구현하기 위해 있는 메시징 프로토콜도 있는데, 메시지 발송시 GCM처럼 유실되어서 상관 없는 메시지부터 반드시 전달되어야 하는 메시지까지 다양한 설정이 가능합니다. 다만 전달 과정이 엄밀할수록 성능이나 배터리 이슈가 생기죠.
다만 iOS에서는 백그라운드 태스크가 제한적이라 MQTT 구현은 안드로이드에서만 가능하고요.(대신 배터리 소모량이...)