Conception d'un protocole d'application [fermé]

Question

J'ai une application autonome existante qui sera étendue par un tiers, à l'aide d'un protocole réseau. Les fonctionnalités sont déjà mises en œuvre, tout ce dont j'ai besoin est de les exposer à l'extérieur.

En supposant que le protocole de transport soit déjà choisi (UDP), existe-t-il des ressources qui pourraient m'aider à concevoir mon protocole d'application?

Il semble y avoir beaucoup d'informations sur la conception de logiciels, mais pas sur la conception de protocoles. J'ai déjà consulté Conception de protocole d'application .

Answer 1

Voir les consignes de création de protocoles Jabber et RFC 4101 . Bien qu’il ait pour but de rendre les RFC plus faciles à comprendre pour les réviseurs, ce RFC fournit quelques conseils intéressants.

Answer 2

Avez-vous consulté le tampon de protocole Google ? Cela semble être un bon moyen de résoudre ce problème.

Vous pouvez créer un point de terminaison qui communique avec votre application existante et qui répond ensuite de "l'extérieur" à l'aide du protocole Protobuffer. C'est binaire, donc c'est minuscule et rapide et vous n'avez pas à écrire votre propre gestionnaire de protocole, car vous pouvez utiliser ceux de Google. L’inconvénient est qu’il doit être mis en œuvre des deux côtés du système (côté serveur et côté client / client).

Answer 3

Une autre recommandation concernant les tampons de protocole - un binaire compact et agréable sans effort. Notez cependant que, bien que le protocole binaire soit bien défini, il n'existe pas encore de norme RPC convenue ( plusieurs sont en cours , tendant vers TCP ou HTTP).

Il est très facile d’inscrire le client et le serveur dans différentes architectures , ce qui est bon - plus il est extensible.

Avertissement: je suis l'auteur de l'une des versions .NET . , donc je peux bien être biaisé ;-p

Answer 4

Tout d’abord, UDP est avant tout une méthode de transport de diffusion unidirectionnelle. En outre, il est potentiellement avec perte , vous devez donc être en mesure de gérer les paquets manquants et les paquets en panne. Si vous avez besoin d’un niveau de fiabilité de la part du protocole UDP, ou si vous avez besoin de connexions bidirectionnelles, vous aurez besoin de presque tout du TCP, c’est pourquoi vous pouvez également commencer par cela et laisser la pile réseau s'en charger. / p>

Ensuite, si vos données sont potentiellement plus volumineuses qu'un seul paquet IP, vous aurez besoin d'un moyen d'identifier le début et la fin de chaque paquet et d'un moyen de gérer les paquets illégaux ou corrompus. Je recommanderais une sorte d'en-tête avec une longueur de paquet, une sorte de pied de page et peut-être une somme de contrôle.

Ensuite, vous avez besoin d’un moyen de coder les messages et les réponses. Il existe de nombreux protocoles RPC autour. Vous pouvez regarder SOAP, ou concevoir un protocole personnalisé basé sur XML, ou un protocole binaire.

Answer 5

Vous devriez vraiment vous demander si vous voulez vraiment concevoir, documenter et maintenir votre propre protocole ou utiliser quelque chose qui existe déjà. Il est probable qu'un protocole documenté existe déjà pour répondre à vos besoins. En fonction de ce que vous faites, le résultat sera probablement excessif au début et la mise en œuvre de toutes les spécifications paraîtra fastidieuse et bien moins amusante que de rédiger la vôtre, mais si vous souhaitez que votre application soit encore activement développée dans quelques années, elle devrait vous faire gagner du temps. beaucoup de temps et d’argent pour utiliser quelque chose qui existe déjà et qui est connu de tiers. En outre, si vous pouvez utiliser une bibliothèque existante pour ce protocole, la partie implémentation devrait être beaucoup plus rapide.

Concevoir un nouveau protocole est plus amusant que d’en implémenter un mais moins que de le maintenir, car il faut vivre avec tous les défauts. Aucun protocole n'est parfait, mais si vous n'en avez jamais conçu, vous pouvez être sûr que vous ferez plus d'erreurs en le concevant que les personnes qui ont conçu le protocole existant que vous pourriez utiliser à la place.

En bref, exploitez autant que possible ce qui existe déjà.

Answer 6

Si vous ne souhaitez pas créer votre protocole à partir de zéro, consultez SOAP . La prise en charge varie selon les langages de programmation, mais la communication entre langues est explicitement encouragée.

Malheureusement, UDP et SOAP semblent être restés bloqués dans leurs débuts, HTTP est le plus couramment utilisé.

Answer 7

Si vous choisissez XML, gardez à l’esprit que vous aurez une surcharge de balisage énorme.

Un simple protocole binaire nécessitera également moins de ressources à analyser que le XML.

Answer 8

  

J'ai une application autonome existante qui sera étendue par un tiers, à l'aide d'un protocole réseau.

Il serait utile d’en savoir un peu plus sur ce que fait votre programme et sur la nature de ces extensions tierces. Peut-être quelques raisons d'utiliser UDP?