"L'application fonctionne bien depuis des années, la semaine dernière, le réseau a été mis à niveau et nous sommes passés de 100 mbps à gigabit. Maintenant, la dernière moitié des données de certains messages est une poubelle. Les gens du réseau jurent que ce n'est pas le réseau - mais c'est la seule chose qui a changé".
La bonne nouvelle, c'est que la coûteuse mise à niveau du réseau n'a pas interrompu l'application.
La mauvaise nouvelle, c'est que l'application est cassée et l'a toujours été. Ce que *beaucoup* de gens qui écrivent des applications TCP ne réalisent pas, c'est que le TCP est un flux d'octets, pas de messages. Le fait qu'une application envoie deux messages de 1000 octets ne signifie pas que la pile TCP émettrice enverra deux segments TCP de 1000 octets. Les messages d'application peuvent être segmentés en plus petits morceaux en fonction de la taille maximale de segment annoncée par le récepteur ou de certaines limites de configuration de l'émetteur. Les retransmissions peuvent également combiner et fragmenter les messages d'application. Même si la pile TCP émettrice envoie effectivement deux segments TCP de 1000 octets, il n'y a aucune garantie que la pile TCP réceptrice donnera à l'application réceptrice deux messages de 1000 octets. Par exemple, si le tampon de l'application ne fait que 500 octets, c'est tout ce que la pile TCP renverra. Par contre, si le tampon est de 1500 octets et que les deux segments de 1000 octets sont arrivés, la pile TCP retournera 1500 octets lors du premier appel et 500 octets lors du second. C'est à l'application de prendre le flux d'octets et de l'analyser correctement pour en faire des messages.
Quel est le rapport avec la modernisation du réseau ? Eh bien, le serveur OpenVOS et le client Linux se trouvaient sur des sous-réseaux différents, de sorte que le système OpenVos annonçait une taille de segment maximale de 536 octets. Les messages d'application envoyés par le client étaient de 1000 octets, donc les messages étaient segmentés en deux parties. Avant la mise à niveau, il semble que les deux segments arrivaient au serveur OpenVOS avant que l'application n'affiche sa réception, de sorte que les 1000 octets étaient lus en un seul appel à la fonction de réception. Après la mise à niveau, le timing des segments a changé de sorte que, parfois, seul le premier segment était disponible lorsque l'application affichait sa réception. Les 464 (1000 - 536) derniers octets du tampon de l'application n'étaient pas remplis par la pile TCP et contenaient les déchets qui se trouvaient là avant que la réception ne soit envoyée.
Dans ce cas, il y a eu une solution rapide et facile : augmenter la valeur MSS annoncée d'OpenVOS à 1460 (voir Un moyen facile d'améliorer le débit TCP à travers les sous-réseaux). Cependant, il ne s'agit là que d'une solution provisoire. La véritable solution consistera à réécrire le code pour analyser correctement le flux d'octets TCP et le renvoyer dans les messages d'application au lieu de supposer qu'un appel reçu renvoie un message.