Est-il préférable d'utiliser les protocoles sans état sur des protocoles avec état?

Question

Je peux voir que les protocoles avec état conduisent à un "état émulé" moins bâclé comme les cookies.

mais les tests deviennent beaucoup plus difficiles pour s'assurer que votre implémentation est correcte et que vous vous reconnectez, et que les continuations de session peuvent être très difficiles à gérer.

Est-il considéré comme une meilleure pratique de toujours utiliser des protocoles sans état, ou est-ce vraiment spécifique à un domaine?

Je pense que l'authentification devient plus facile lorsqu'il s'agit de protocoles avec état, mais existe-t-il d'autres raisons pour lesquelles vous devriez utiliser un protocole avec état?

Answer 1

Quelle est l’importance de l’état pour votre application? Avez-vous besoin d’un flux constant de données entre différentes machines ou est-il plus utile d’avoir des rafales? Si vous écrivez une application de type téléphonie IP, vous voudrez probablement quelque chose d'assez précis, si vous pouvez vous en sortir sans état, il sera probablement moins cher et plus facile de le faire de cette façon. Faire les choses en état est forcément plus fragile, car si l'une des extrémités de la connexion est interrompue ou si la connexion elle-même tombe en panne, vous courez un risque plus élevé de perte de données, alors qu'avec une connexion sans état, vous aurez plus de chances d'attendre un moment et d'essayer. encore.

Ce sont vraiment des outils différents pour des emplois différents, mais compte tenu de la facilité et de l'omniprésence des technologies sans état en ligne, il est logique de regarder dans cette direction lorsque vous avez la possibilité.

Answer 2

Avantages de l'apatride:

1. Évolutivité élevée (vous pouvez envoyer une demande à n'importe quel noeud, vous pouvez ajouter des noeuds à tout moment)
2. Haute disponibilité (si un noeud échoue, aucun état n'est perdu, il suffit de renvoyer la demande à un autre noeud)
3. Haute vitesse (en l'absence d'état, les résultats sont susceptibles d'être mis en cache)

Answer 3

Je considérerais cela comme étant spécifique à un domaine. Si vous écrivez l'équivalent moral de ping, un protocole sans état est le bon choix. D'autre part, si vous écrivez un VNC, l'état avec état est certainement la voie à suivre.

Quant à savoir quand choisir lequel, il y a deux points à garder à l'esprit. Premièrement, bien que les choix de mise en œuvre soient l'un ou l'autre, l'espace de problème est un continuum. Toutes les tâches du monde réel ont au moins un petit état, la question est de savoir combien et quel est le surcoût de le faire passer qui vaut la peine de le suivre des deux côtés. Et deuxièmement, vous avez généralement affaire à une pile de protocoles, pas à un seul protocole; en veillant à ce que tout vive au bon niveau puisse simplifier énormément les choses.

Answer 4

Un protocole sans état est plus facile à mettre en cluster car l'état n'a jamais besoin d'être transféré d'un serveur à un autre lors des demandes suivantes.

Answer 5

Je ne connais pas personnellement tous les problèmes de conception entre état et apatride, mais je sais que NFSv4 le fait après 15 ans de versions antérieures de NFS, ce qui est apparemment l'apatridie. Les concepteurs NFS.

Googling, publié en quelques minutes, contient plusieurs articles et blogs sur l'état de présentation de NFSv4. cela devrait être une lecture intéressante pour certains des problèmes de conception impliqués.

Answer 6

Une autre bonne chose avec les protocoles sans état est qu’il est plus facile de gérer les situations de basculement de serveur et / ou les situations de clustering / équilibrage de charge.

Answer 7

Stateful, c'est mieux. Ensuite, vous n'êtes pas obligé d'envoyer l'état tout le temps. Le protocole devient alors plus simple.