2009-06-28 6 views
0

Cette question est large mais spécifique. L'idée est que nous souhaitons lier une fonctionnalité «buddy» à une application de communication. Très largement, je crois que les clients de l'application se connecteraient à un service de base de données/authentification central qui fournirait les données de contact et permettrait ensuite aux applications client de se connecter directement les unes aux autres, sans passer par le serveur. Plus précisément, cependant, quelles solutions, logiciels, produits, serveurs, technologies, etc. seraient les mieux à mettre en œuvre pour gérer une telle tâche?Application Buddy Lists and Authentication - Comment tout cela va-t-il ensemble

Merci pour la lecture et les réponses sont très appréciées.

// edit: l'application com peut fonctionner sur une distro linux, peut être basée sur le Web, ou les deux

+0

Sérieusement pas de réponses? – Krevin

+0

Travailler dessus! .... –

Répondre

1

Pour faire quelque chose comme ceci est similaire à une architecture de partage de fichiers. Où vous avez un magasin central pour toutes vos informations de contact. Cela aurait une API basée sur le service que vos autres applications seraient au courant. Le serveur de jumelage devrait connaître les applications client et leurs emplacements physiques. Cela permettra aux applications clientes de se connecter au serveur de messagerie, de localiser les autres clients de la zone, puis de s'y connecter directement.

Lorsque cela devient un problème, contournez les problèmes de pare-feu. Les clients devraient jouer le rôle de mini-serveurs ici. Une fois qu'un client se connecte au serveur de messagerie, il découvre les autres clients avec lesquels il souhaite se connecter, il doit alors établir des communications avec lui ... parfois via un pare-feu. C'est là que je suis perdu car je n'ai pas fait cet aspect. L'autre solution consiste à garder vos clients connectés au serveur de messagerie où toutes les communications sont routées via le serveur vers les autres clients connectés. C'est une manière plus intensive en ressources d'aborder ce type de problème ... et non l'itinéraire suggéré.