los datos fuera de orden raros extraños recibidos a través de Indy

Question

Vamos a tener un extraño problema con Indy10 donde dos cadenas grandes (unos pocos cientos de caracteres cada una) que enviamos uno tras otro a través de TCP están apareciendo en el otro extremo entrelazan de manera extraña. Esto ocurre muy poca frecuencia.

Cada cadena es un mensaje XML completo terminado con un LF y en general el proceso de lectura lee un mensaje XML completo, regresando cuando se ve la LF.

La llamada a enviar realmente el mensaje está protegido por una sección crítica en torno a la llamada al método writeln del IOHandler y lo que no es posible que dos hilos para enviar al mismo tiempo. (Estamos seguros de la sección crítica se implementa / funcionando correctamente). Este problema ocurre muy rara vez. Los síntomas son extraño ... cuando enviamos cadena A, seguido por la cadena B lo que recibimos en el otro extremo (en las raras ocasiones en las que tenemos fracaso) es la sección de salida de la cadena A por sí mismo ( es decir, , hay un LF al final de la misma), seguida de la sección inicial de la cadena a y luego toda la cadena B seguido de un único LF. Hemos verificado que la "cronometrados a cabo" la propiedad no es cierto después de la lectura parcial - registramos que la propiedad después de cada lectura que devuelve el contenido. Además, sabemos que no hay caracteres de LF incrustados en la cadena, ya que sustituyen de manera explícita todos los caracteres no alfanuméricos en la cadena con espacios antes de añadir la LF y enviarlo.

Tenemos mecanismos de registro dentro de las secciones críticas en los extremos tanto de la transmisión y recepción y para que podamos ver este comportamiento en el "alambre".

Estamos completamente desconcertado y preguntándose (aunque siempre existe la posibilidad más baja) si podría haber algunos problemas de Indy de bajo nivel que podría causar este problema, por ejemplo, , tampones de ser enviado en el orden equivocado. ... muy difícil creer que este podría ser el problema, pero estamos agarrando a un clavo ardiendo.

¿Alguien tiene alguna idea brillante?

Answer 1

¿Tiene múltiples hilos de lectura de la misma toma al mismo tiempo, en el extremo receptor? Aunque sólo sea para consultar el estado conectado () hace una lectura que se produzca. Esto podría causar que sus múltiples hilos para leer los datos de entrada y almacenarlo en el IOHandler.InputBuffer en orden aleatorio si no se tiene cuidado.

Answer 2

Usted podría intentar Wireshark para averiguar cómo se tranferred los datos. De esta manera usted puede averiguar si el problema está en el servidor o en el cliente. También recuerde usar TCP para conseguir "garantizado" datos válidos en el orden correcto.

Answer 3

¿Está utilizando TCP o UDP? Si está utilizando UDP, es posible (y esperada) que los paquetes UDP pueden ser recibidos en un orden diferente al que se transmitieron debido al enrutamiento a través de la red. Si este es el caso, tendrá que añadir algún tipo de ID de paquete para cada paquete UDP para que el receptor puede ordenar adecuadamente los paquetes.

Answer 4

¿Ha comprobado la ajustes del IOHandler Nagle ? Hemos tenido un problema similar que hemos fijado mediante el establecimiento de UseNagle a falso. En nuestro caso, enviar y recibir grandes cantidades de datos en ráfagas era lento debido a la coalescencia de Nagle, así que no es exactamente lo mismo que su situación.