Étranges rares données hors de la commande reçus en utilisant Indy

Question

Nous allons avoir un problème bizarre avec Indy10 où deux grandes chaînes (quelques centaines de caractères) que nous envoyons un après l'autre en utilisant TCP font leur apparition à l'autre extrémité étrangement entremêlées. Cela se produit très rarement.

Chaque chaîne est un message XML complet terminé par un LF et en général le processus READ lit un message XML entier, de retour quand il voit le LF.

L'appel à envoyer réellement le message est protégé par une section critique autour de l'appel à la méthode writeln du IOHandler et il est donc impossible pour deux threads pour envoyer en même temps. (Nous sommes certain que la section critique est mise en œuvre / fonctionne correctement). Ce problème se produit très rarement. Les symptômes sont bizarres ... quand nous envoyons chaîne A suivi par la chaîne B ce que nous avons reçu à l'autre bout (dans les rares occasions où nous avons l'échec) est la partie arrière de la chaîne A par lui-même ( soit , il y a un LF à la fin de celui-ci), suivie par la section principale de la chaîne a, puis l'ensemble de la chaîne B suivie d'une seule LF. Nous avons vérifié que le « a expiré » la propriété est pas vrai après la lecture partielle - nous enregistrons cette propriété après chaque lecture qui retourne le contenu. En outre, nous savons qu'il n'y a pas de caractères LF incorporés dans la chaîne, comme nous remplaçons explicitement tous les caractères non alphanumériques dans la chaîne avec des espaces avant d'ajouter la LF et l'envoyer.

Nous avons des mécanismes de journaux à l'intérieur des sections critiques à la fois sur la transmission et de réception extrémités et que nous puissions voir ce comportement au « fil ».

Nous sommes complètement dérouté et je me demandais (bien que toujours la possibilité la plus basse) s'il pourrait y avoir des problèmes Indy de bas niveau qui pourrait causer ce problème, par exemple , des tampons étant envoyé dans le mauvais ordre. ... très difficile de croire que cela pourrait être le problème, mais nous saisir à pailles.

Est-ce que quelqu'un a des idées claires?

Answer 1

Avez-vous plusieurs threads de lecture à partir de la même prise en même temps sur la fin de réception? Même juste pour interroger l'état Connecté () provoque une lecture de se produire. Cela pourrait causer à vos multiples threads de lire les données entrantes et le stocker dans le IOHandler.InputBuffer dans un ordre aléatoire si vous ne faites pas attention.

Answer 2

Vous pouvez essayer Wireshark pour savoir comment les données sont tranferred. De cette façon, vous pouvez savoir si le problème est dans le serveur ou le client. Rappelez-vous aussi d'utiliser TCP pour obtenir « garantie » des données valides dans le bon ordre.

Answer 3

Utilisez-vous TCP ou UDP? Si vous utilisez UDP, il est possible (et attendu) que les paquets UDP peuvent être reçus dans un ordre différent de celui qu'ils ont été transmis en raison de l'acheminement à travers le réseau. Si tel est le cas, vous aurez besoin d'ajouter une sorte d'ID de paquet à chaque paquet UDP de sorte que le récepteur peut bien commander les paquets.

Answer 4

Avez-vous vérifié paramètres de Nagle du IOHandler? Nous avons eu un problème similaire que nous avons fixé en réglant UseNagle false. Dans notre cas envoyer et recevoir de grandes quantités de données en rafales a été lente en raison de Nagle coalescent, il est donc pas tout à fait la même chose que votre situation.