큰 지연 (시간)이 허용되는 경우 푸시 대 폴

오늘날 폴링은 나쁜 습관이며 원격 서버에서 지속적으로 데이터를 수신해야하는 모바일 애플리케이션을 개발할 때 추진하는 길은 상식적인 것 같습니다.

모든 주요 모바일 상점은 푸시 알림 서비스 버전을 제공합니다.

• Apple 푸시 알림 서비스
• Android 용 Google 클라우드 메시징
• Microsoft 푸시 알림 서비스

그러나 나는이 가정이 어느 정도 유효한지 궁금합니다. 즉, 하루에 몇 번만 원격 서버를 폴링하고 "알림"을 즉시 전달할 필요가없는 (큰 지연이 허용되는) 응용 프로그램이 있다면 좋은 결정이 될 것입니다. 데이터를 푸시하지 않고 폴링합니다.

미리 감사드립니다!

실시간이 필요하지 않은 경우 항상 폴링이 허용됩니다. 스스로에게 물어봐야 할 것은 왜 다른 것을 사용하지 않습니까?

푸시 서비스의 목적은 몇 가지입니다. 푸시가 브로드 캐스트이고 타사 제공 업체가 브로드 캐스트를 수행하는 경우 처리하는 트래픽이 훨씬 적을 수 있습니다. 이렇게하면 하나의 메시지를 보내고 수천 명의 메시지를받을 수 있습니다. 그러나 알다시피 푸시 서비스의 가장 큰 장점은 즉시 업데이트가 소비자에게 도달 할 수있는 실시간 특성입니다. 그러나 푸시를 할 때는 브로드 캐스트 할 때 대용량 데이터 세트를 푸시하고 싶지 않으며, 사용하는 타사 푸시 서비스 (자신을 사용하는 경우)의 자비에 달려 있습니다.

폴링의 목적은 데이터 차이를 주기적으로 확인하는 것입니다. 여기서 업데이트 기간에는 특정 기간까지 부정확 한 SLA가 허용됩니다. 폴링은 모든 클라이언트가 주기적으로 데이터를 요청하도록 요구합니다. 즉, 실행중인 모든 클라이언트에 대해 연결이 요청되고 해당 데이터를 폴러에게 제공하기 위해 해당 데이터를 정확하게 모니터링 할 수있는 라이브 서비스가 필요합니다. 정확한 데이터를 제공한다는 것은 일부 데이터 지속성을 의미하며 디스크 및 유지 관리 시간이 소요됩니다.

따라서 네트워크 트래픽 또는 서비스 유지 관리에 대한 우려가있는 경우 (요청 인증 / 권한 부여, 디스크 공간을 차지하는 로깅, 서비스 유지에 필요한 모든 일반 요구 사항을 의미 함) 클라이언트가 강제로 폴링하고 싶지 않습니다. 그러나 유스 케이스에 특히 큰 데이터 세트를 전송해야하거나 SLA 또는 요금뿐만 아니라 시간이 변경 될 수있는 써드 파티 API에 테 더링 할 수없는 경우, 자체 재배 폴링 시스템이 적용 가능하지만 유지 보수가 가능합니다. 오버 헤드가 훨씬 더 클 수 있습니다. 또는 이미 서비스를 실행 중이고 데이터가 지속되어 폴링이 이미 내부 인프라에 약간 추가되어 폴링이 더 바람직합니다.

중심점까지는 당신을 옳게 만듭니다. 실시간이 필요한 경우 폴링은 수행되지 않습니다. 그렇지 않은 경우 클라이언트주기에 데이터를 주기적으로 곱하는 방법과 데이터 세트 크기를 곱한 방법 에 대한 계산을 수행 하여 네트워크 비용이 가치가 있는지 또는 푸시 서비스인지 결정해야합니다. 2 단계에서 대규모 데이터 세트를 요청하도록하는 변경 이벤트를 항상 푸시 할 수있는 경우에 더 좋습니다 (이 단계의 원자 성은 데이터의 중요도에 따라주의해야 할 수도 있음).

귀하의 경우에는 폴링이 좋을 것입니다. 또한 다른 시스템 (또는 여러 플랫폼의 여러 시스템) 과 통합 할 필요가 없습니다 .

그러나 장치 관련 문제가 문제 일 수 있습니다. 앱이 기기의 중앙에 있고 중앙에 있지 않을 때 안정적으로 폴링 할 수 있습니까? (문제가 될 수도 있고 아닐 수도 있습니다). 이를 수행하는 능력은 앱 개발에 사용하는 기술에 따라 달라질 수 있습니다.

물론이야. 또한 더 쉽습니다 (모든 사람이 같은 일정을 잡아 당기면 당기는 스파이크에주의하십시오).

즉, 모바일 사용자의 기대를 고려할 때 '큰 지연이 허용됩니다'라는 가정에 도전합니다. ( '실시간으로지도가 업데이트되지 않습니다! 받아 들일 수 없습니다!'-또는- '날씨 서비스라는 것을 알고 있지만 내일 예측이 화창해질 때까지 5 초마다 새로 고침 버튼을 계속 누르고 있습니다!')