¿Los protocolos sin estado se consideran mejores para usar que los protocolos con estado?

Question

Puedo ver que los protocolos con estado conducen a un "estado emulado" menos fallido como cookies.

pero las pruebas se vuelven mucho más difíciles para garantizar que su implementación sea correcta y se reconecte, y las continuaciones de sesión pueden ser muy difíciles de manejar.

¿Se considera una mejor práctica usar siempre protocolos sin estado, o es realmente un dominio específico?

Creo que la autenticación se vuelve más fácil cuando se trata de protocolos con estado, pero ¿hay alguna otra razón por la que deba usar un protocolo con estado?

Answer 1

¿Qué tan importante es el estado para su aplicación? ¿Necesita un flujo constante de datos entre diferentes máquinas o es más útil tener ráfagas? Si está escribiendo una aplicación de tipo de telefonía IP, entonces probablemente querrá algo bastante con estado, si puede salirse con apátrida es probable que sea más barato y más fácil hacerlo de esa manera. Hacer las cosas con estado es necesariamente más frágil porque si cualquiera de los extremos de la conexión se cae o la conexión se cae, corre un mayor riesgo de pérdida de datos, mientras que con una conexión sin estado es más probable que tenga que esperar un tiempo e intentar de nuevo.

Realmente son herramientas diferentes para diferentes trabajos, pero dada la facilidad y ubicuidad de las tecnologías sin estado en línea, es lógico mirar en esa dirección cuando tienes la opción.

Answer 2

Ventajas de los apátridas:

1. Alta escalabilidad (puede enviar solicitudes a cualquier nodo, puede agregar nodos en cualquier momento)
2. Alta disponibilidad (si un nodo falla, no se pierde ningún estado, solo reenvíe la solicitud a otro nodo)
3. Alta velocidad (como no hay estado, los resultados se pueden almacenar en caché)

Answer 3

Lo consideraría un dominio específico. Si está escribiendo el equivalente moral de ping, un protocolo sin estado es la opción correcta. Por otro lado, si está escribiendo un VNC, con estado es seguramente el camino a seguir.

En cuanto a cuándo elegir cuál, hay dos puntos a tener en cuenta. Primero, si bien las opciones de implementación son o bien, el espacio del problema es un continuo. Todas las tareas del mundo real tienen al menos un pequeño estado, la pregunta es cuánto y la sobrecarga de pasarlo vale la molestia de rastrearlo en ambos extremos. Y segundo, generalmente se trata de una pila de protocolos, no de un solo protocolo; asegurarse de que todo vive en el nivel correcto puede simplificar enormemente las cosas.

Answer 4

Un protocolo sin estado es más fácil de agrupar ya que el estado nunca necesita ser transferido de un servidor a otro en solicitudes posteriores.

Answer 5

No estoy personalmente familiarizado con todos los problemas de diseño de estado con estado sin estado, pero sí sé que NFSv4 tiene estado después de 15 años de versiones anteriores de NFS sin estado, por lo que aparentemente la apatridia se convirtió en una limitación significativa para el Diseñadores NFS.

Unos pocos minutos en Google revela varios artículos y blogs que hablan sobre la capacidad de crecimiento de NFSv4; Esta debería ser una lectura interesante para algunos de los problemas de diseño involucrados.

Answer 6

Otra cosa agradable con los protocolos sin estado es que es más fácil manejar situaciones de conmutación por error del servidor y / o situaciones de agrupamiento / equilibrio de carga.

Answer 7

Con estado es mejor. Entonces no tiene que enviar el estado todo el tiempo. El protocolo se vuelve más simple.