¿Se considera que los protocolos sin estado son mejores para usar en protocolos con estado?

Question

Veo que los protocolos con estado conducen a un estado menos emulado 'emulado' como las cookies.

pero las pruebas se vuelven mucho más difíciles para garantizar que su implementación sea correcta y se vuelva a conectar, y la continuación de las sesiones puede ser muy difícil 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 de 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 telefonía IP, probablemente desee algo bastante estable; si puede salirse con la suya sin estado, es más barato y más fácil hacerlo de esa manera. Hacer las cosas de forma pública es necesariamente más frágil porque si uno de los extremos de la conexión se interrumpe o la conexión se interrumpe, corres un mayor riesgo de pérdida de datos, mientras que con una conexión sin estado, es más probable que tengas que esperar un rato y probar 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 tenga la opción.

Answer 2

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 3

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

Answer 4

Ventajas de apátrida:

1. alta escalabilidad(se puede puede enviar la solicitud a cualquier nodo, puede añadir nodos en cualquier momento)
2. alta disponibilidad(si un nodo falla, no hay ningún estado que se pierda, solo reenvía la solicitud a otro nodo)
3. Alta velocidad(ya que no hay estado, los resultados son cacheable)

Answer 5

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

En cuanto a cuándo elegir cuál, hay dos puntos a tener en cuenta. En primer lugar, si bien las opciones de implementación son o bien, el espacio 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 6

Stateful is better. Entonces no tienes que enviar el estado todo el tiempo. El protocolo luego se vuelve más simple.

Answer 7

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

En pocos minutos, la búsqueda en Google revela varios artículos y blogs sobre el estado de NFSv4; esto debería ser una lectura interesante para algunos de los problemas de diseño involucrados.