Je développe une application pour iOS et Android. La fonctionnalité de base consiste à conserver un certain ensemble de données synchronisées sur tous les périphériques d'un réseau Wi-Fi sans serveur central. Chaque appareil peut modifier cet ensemble de données.
L'approche actuelle consiste à découvrir les autres appareils via Bonjour / Zeroconf, puis envoyez les "messages de changement" sur tous les périphériques via zeromq.
Comme les deux cadres entraînent beaucoup de problèmes à mettre en œuvre, je demande si c'est la bonne façon de l'accomplir.
J'ai eu la majeure partie de la logique mise en œuvre avec BONJOUR et HTTP-Demandes envoyées à tous les appareils. Le problème était simplement des demandes de réseau qui ne seraient pas reçues, même après trois essais, car le réseau a échoué. Je veux avoir une sorte de reconstruction d'un État général ou un cadre de messagerie plus fiable.
une approche de potins pour diffuser l'information ainsi que découvrir tous les appareils sont meilleurs?
3 Réponses :
Je ne connais pas les détails de votre problème, mais:
pourrait avoir un diffusion UDP travail de message?
Si vous interrogez le réseau et obtenez l'adresse de diffusion, cela pourrait être un moyen facile de distribuer / interroger pour des informations sans avoir à l'envoyer à chaque périphérique individuellement. Bien entendu, UDP n'est pas fiable, vous devez donc implémenter une sorte de mécanisme de "requête" dans lequel le périphérique demanderait des mises à jour une fois qu'il (RE) se connecte à un réseau.
Seulement une autre option, plus fiable, que je pouvais penser utiliserait les notifications pustiques de la plate-forme. Dans ce cas, Apple / Google s'assurera que vos messages sont livrés, votre seul travail consiste à conserver une liste d'appareils dans "Un groupe" (par exemple sur le même WiFi). Mais cette solution inclut à nouveau d'avoir un serveur central et, encore plus, accès à Internet.
Je n'ai pas trop de données (texte uniquement), mais les demandes se produisent assez rapidement et chaque appareil peut envoyer plus de 1req / s par lui-même. Je vais toujours regarder dans ça.
ni un rôle ad hoc-asymétrie de devenir un serveur à la demande afin de décider d'une modification comme dans "Sondage (chacun votes)" (fig.-s courtoisie nanomsg.org )
ou une coalition-de-nœuds de nœuds-symétrie dans un est une tâche à utiliser comme une auto-identification continue, de manière à donner la coalition de nœuds l'ensemble d'informations pertinent pour qui attendre pendant le vote et pour qui non. Réciproquement, lorsqu'il est juste pour la diffusion << EM> Alistitem > Modifier et attendre un vote à appuyer sur la coalition-de-nœuds "quartier".
pieter hintjens '400 pages de pages 400+ Le guide Zeromq - pour les développeurs de Python, chapitre 8.3 vous donnera des idées initiales sur la découverte autonome préventive et / ou coopérative et certaines remarques sur la WiFi sont des chapitres précédents. . Veuillez également noter une remarque de clôture sur les incertitudes ISO-OSI-L2 / L3 dans >>> Limitations sur la découverte basée sur wifi SSID L3 ARP
est juste un autre sous-protocole (couche) à mettre en œuvre à l'intérieur de la coalition-de-nœuds.
Peut-être oui, peut-être non.
première Liste Toutes les exigences pour pouvoir concevoir "contre" un tel ensemble de fonctionnalités obligatoires.
Deuxièmement, Troisième, Conception La communauté non bloquante et auto-récupéenne - A 
répond à toutes les exigences en soi.
une découverte continue "Phase"
Méthodes de << em> Alistitem > Changer la propagation Accross La coalition actuelle-de-nœuds
est un bus ou un modèle de communication formel évolutif hybride avec vote «Enquête» répondant à toutes les exigences?
Merci pour votre réponse étendue, mais je pense que la voie à suivre est avec Alljoyn. Si je peux le faire fonctionner, je suis sûr que c'est beaucoup moins réinventer la Weel en écrivant mon propre protocole (de quelque couche).
Obtenir que les trucs de serveur client travaillant de manière fiable peuvent être assez difficiles. en particulier la plate-forme inter-plate-forme; Il semble toujours y avoir une autre affaire de bord qui doit être résolue. Plutôt que de reconstruire la roue, je recommande d'utiliser une bibliothèque existante où quelqu'un d'autre a déjà élaboré tous les kinks. Je ne l'ai pas encore utilisé pour rien au-delà d'un prototype, mais le Le projet AllJoyn Open-Source est très prometteur . Une autre option est le Google APIS à proximité , qui ne sont que pour Android et iOS.
J'ai eu quelques personnes proposant Alljoyn, a l'air assez prometteur, je vais certainement vérifier!
Page non trouvée exception :(
J'ai mis à jour le lien et ajouté une référence / lien vers Google à proximité.
La décentralisation sera toujours un problème et vous ne pouvez pas faire grand chose à ce sujet. Je choisirais simplement l'un des appareils du réseau et il suffirait d'agir en tant que serveur et tous les autres appareils communiquant avec un seul appareil. Cela facilite définitivement cela mais je ne le considérerais toujours pas facile. Pourriez-vous peut-être nous montrer un code pertinent ou expliquer plus en détail ce que vous avez essayé et ce qui a mal tourné?
J'ai considéré un serveur fluctuant, mais cela pose également des problèmes. A) Comme il s'agit d'un réseau Wi-Fi avec smartphones, les déconnexes vont se produire fréquemment b) choisir un serveur et faire savoir à tous les appareils qu'il est (ou s'il y en a déjà une) est vraiment difficile. Je vais éditer la question avec des détails.
Je me rends compte que, mais vous ne pouvez pas nier qu'il est beaucoup plus facile que d'essayer d'avoir une consistance transactionnelle dans un réseau décentralisé. S'il n'y a personne pour décider de la commande et de la validité de chaque changement que vous allez simplement rencontrer des problèmes insolvables. Image juste Il y a deux modifications en même temps sur deux périphériques différents. Qui décide si la modification est possible du tout (imaginez qu'ils modifient la même chose). Qui décide lequel est avant l'autre. S'il n'y a pas d'autorité centrale pour prendre ces décisions que vous allez avoir beaucoup de problèmes.
Je comprends ce que vous dites, mais dans mon ensemble de données est une liste d'éléments et que chaque utilisateur peut avoir un vote sur un élément ou non, il n'y a donc aucun conflit direct entre les appareils.
Le moyen le plus fiable est que les appareils communiquent avec un périphérique dédié. S'ils modifient quelque chose, le serveur décide s'il est possible et si oui, le serveur la synchronise sur les autres périphériques. Si le serveur disparaît, un autre périphérique est cueilli, ce qui tient par rapport à des actes de serveur. La partie délicate ici est bien sûr choisi le serveur et tout cela, mais aussi longtemps que vous avez raison, je pense que vous le trouverez beaucoup plus facile que l'autre option.
Je ne sais pas si cela s'applique à votre situation, mais vous pouvez simplement accueillir un backend quelque part qui prend le rôle de serveur. Bien sûr, vous avez toujours besoin d'Internet pour cela, mais à nouveau ce que WiFi n'a pas de connexion Internet. Un backend Gae simple avec GCM serait parfait. Et vous n'avez plus besoin que les périphériques soient dans le même réseau.
Les articles sont-ils fixés ou peuvent-ils être ajoutés et supprimés?
J'ai pensé à un backend comme Gae, mais il préférait évidemment trouver une solution qui reste dans le Wi-Fi. Tout le monde peut ajouter des articles, les articles sont supprimés progressivement
Vous allez devoir trouver un moyen fiable de synchroniser ces changements, mais je soupçonne que ce sera difficile. Bien qu'il y ait certains protocoles de faire exactement cela, mais je ne décrirais pas les implémenter aussi facilement. Un backend GAE pourrait en fin de compte être la solution la plus simple, la plus rapide et la meilleure. Avez-vous de l'expérience avec GAE?
Quels protocoles avez-vous à l'esprit? Je n'ai pas d'expérience avec Gae, mais je sais qu'environ ce qu'il peut faire.
Vous pouvez également utiliser Analyse ou une bibliothèque similaire. Je voudrais essayer ça. L'analyse peut manipuler à peu près toutes les synchronisations et économiser dans le nuage et il vous suffit de vous soucier de la logique commerciale.
Je continuerai à regarder cette question, donc si vous faites des progrès ou si vous avez des problèmes, n'hésitez pas à la mettre à jour, je serai informé de tous les changements!
Très bien merci pour votre aide!
Problème intéressant ... Je suggérerais d'utiliser des techniques de potins pour la découverte de l'appareil et la propagation d'informations et des arbres de merkle pour la fusion des changements. De toute évidence, cela soulève beaucoup plus de questions. Le premier qui me vient à l'esprit est de savoir comment gérer l'horloge (horloges vectorielles, etc.). Bien sûr, toute solution à base de nuages est beaucoup plus facile et plus rapide à mettre en œuvre, mais P2P One serait beaucoup plus élégante (en supposant que vous disposez de temps et de ressources illimitées pour cette tâche :)
J'ai cherché beaucoup pour un cadre pour mettre en œuvre l'approche de potins / découverte. Avez-vous une recommandation? P2P serait assez bénéfique pour les exigences :)
@Lukasleitter Nope, je ne suis au courant d'aucun cadres adaptés aux téléphones mobiles. Je connais la mise en œuvre des commérages à Apache Cassandra, mais cela ne ressemble pas à un ajustement parfait.
Il suffit de suggérer une autre façon de faire Thigs - presque tous les appareils d'aujourd'hui sont connectés à Internet. Insté d'entre eux se découverte, vous pouvez envoyer leurs coordonnées GSM / GPS sur Central Server via Internet et tirez les données PUSH pour l'emplacement dont vous avez besoin.
@Jehy j'ai déjà discuté de cela avec lui, j'ai suggéré parse comme une solution simple.