Bien que les réponses existantes fournissent une description plus ou moins précise de l'aspect de cette connexion continue - elles décrivent la fonctionnalité en utilisant des termes génériques (IP, API, TCP+keep-alive) et ainsi de suite - qui peuvent être vrais, mais qui manquent le côté "Apple" de la chose. Ces réponses pourraient expliquer à la fois Android et Windows et, en fait, toute plate-forme informatique maintenant des connexions réactives à long terme.
L'ajout important que je veux faire ici - est que le "Base OS" d'Apple - la partie partagée entre MacOS iOS tvOS, watchOS et ainsi de suite - contient plusieurs sous-systèmes et API qui permettent un tel comportement pratiquement "gratuitement" à tout développeur de logiciels, à condition qu'ils utilisent les sous-systèmes "recommandés" de l'OS, et non de simples API de réseau génériques (comme posix, etc.).
La capacité à maintenir une connexion réactive à long terme n'est pas seulement requise par les services basés sur les notifications (comme "FindMy" et autres), mais aussi par tous les services multimédias à distance - FaceTime, iTunes, Maps (Navigation) et en réalité tous leurs concurrents aussi (Zoom, Viber, Slack et amis).
Une caractéristique importante que le PO n'a PAS mentionnée - la capacité de survivre et de renouveler la connexion immédiatement en changeant de réseau, de pile réseau et en utilisant plusieurs piles réseau et installations simultanément - est également importante. Un iPhone peut passer du cellulaire au WiFi, au Bluetooth et même utiliser les 3 ensemble des dizaines de fois au cours d'un seul appel.
Les mécanismes importants à apprendre sont :
- Le cadre SystemConfiguration (pour la "joignabilité" et la capacité de maintenir une connexion sans polling)
- CFNetwork Framework - le cadre de la fondation de base mettant en œuvre la plupart des interfaces de bas et de haut niveau des services de réseau - où tous les accès via "proxy" ou "pare-feu" ou le maintien de la connexion à long terme sont mis en œuvre
- NSURLSession - les API Swift/Obj-C de niveau supérieur permettant aux développeurs d'applications de maintenir de telles connexions.
J'ai dû utiliser les trois lorsque j'ai développé des logiciels d'audio/vidéoconférence, des agents de sécurité, des outils de gestion de bases de données à distance et bien d'autres. Je me suis toujours étonné de la facilité et de l'efficacité des API fournies par Apple par rapport aux solutions que j'ai construites pour d'autres plateformes.
Un tout petit exemple : Lorsque vous "dites au système d'exploitation" que vous souhaitez maintenir la connexion avec un serveur spécifique et être informé des changements dans son "accessibilité", le système d'exploitation le fait pour vous, mais PAS dans votre propre processus. C'est un service de l'OS. Ainsi... votre application peut être tuée, et être relancée immédiatement lorsque la connexion est rétablie. De plus, si 3 processus doivent maintenir la connexion à un domaine ou à un service, l'OS ne suit ce domaine/service qu'UNE SEULE FOIS pour tous les "auditeurs" enregistrés, ce qui améliore également l'efficacité.
Ainsi, lorsque vous branchez ou débranchez le câble Ethernet, le système d'exploitation n'a pas besoin de "sonder" la chose - il maintient le matériel basé sur les interruptions de toute façon. Cela peut être fait de manière beaucoup plus efficace ! De même lorsque vous perdez la connexion cellulaire.
Enfin, je vous recommande d'apprendre ces 3 frameworks Apple, et d'apprendre comment cela se passe sur cette plateforme.
Un bon début peut être de regarder cette vidéo de la WWDC 2015 d'Apple - Présentation de Network.framework : Une alternative moderne aux Sockets