¿Cómo evito las respuestas tardías a un socket TCP?

Estoy escribiendo una biblioteca de base de datos que tendrá que soportar inteligentemente tiempos de espera. Ahora que estoy mirando a la agrupación de conexiones, estoy particularmente preocupado por el siguiente escenario:¿Cómo evito las respuestas tardías a un socket TCP?

Enviar consulta # 1
Tiempo después n segundos.
Enviar consulta # 2
recibir una respuesta a la consulta # 1

Paso cuatro pueden pasar, porque las consultas no están marcados con un identificador de consulta: Lo que sé es que he recibido una respuesta, y no sé a qué consulta pertenece. Se podría argumentar que esto constituye un error en el protocolo, pero eso no depende de mí.

Antes de enviar la consulta n. ° 2, ¿qué debería hacer con el socket para evitar una respuesta tan tardía? ¿Es la única forma correcta de shutdown(), close() y volver a connect()?

Fuente

2011-10-22 Andres Jaan Tack

¿Qué pasa con la adición constante al selecto de todas las consultas por lo que su biblioteca podría identificar qué consulta la respuesta es para? – T3hc13h

Esa es una gran idea, pero lamentablemente no es muy buena para una biblioteca. Tal vez a través de un complemento ... –

Me temo que esta es la única manera segura de operar su conexión, porque no hay otra manera de obtener un uno-a-uno entre preguntas y respuestas sobre TCP. Parece que hay una falta de algún tipo de función de cancelación entre ellas.

Esta referencia da una visión más clara: http://www.ssfnet.org/Exchange/tcp/tcpTutorialNotes.html

Fuente

2011-10-22 16:26:57 kroonwijk

A su vez, eso se debe a que TCP no sabe nada de las llamadas "consultas", "respuestas" o "cancelaciones". Un conector conectado es solo dos tubos unidireccionales para bytes (Ted Stevens tenía razón). Si uno de los extremos escribe cosas y el arroyo no sube, entonces el otro extremo puede leerlo. Entonces, establecer qué "consulta" es "para" la respuesta es un problema a nivel de aplicación. O bien está integrado en el protocolo que define la consulta/respuesta, o no existe. –

Es decir, lo sé. :-) Pero TCP tiene números de secuencia, así que esperaba que hubiera algún tipo de truco que pudiera aprovechar. –

@Andres: lamentablemente los números de secuencia solo permiten que la capa TCP ensamble la secuencia; no hay nada que decir cuánto tiempo transcurrió entre bytes particulares en direcciones opuestas. Recuerde que el hecho de que 'n' segundos hayan transcurrido desde que envió la primera solicitud, no significa' n' segundos transcurridos desde que el otro extremo lo leyó. Por lo tanto, el otro extremo podría haber enviado esa respuesta * antes * del tiempo de espera de su POV, pero llegó con usted después del tiempo de espera de su punto de vista. Los tiempos de espera solo podrían funcionar con una conexión fiable sincronizada en el tiempo, que TCP no es. –

¿Cómo evito las respuestas tardías a un socket TCP?

Respuesta

Cuestiones relacionadas