La connexion client telnet cesse de recevoir des données, le serveur envoie toujours

Question

Je travaille dans un environnement linux intégré.

il lance un démon telnet au démarrage qui surveille un port particulier et lance un programme lors de la réception d'une connexion.

à savoir

telnetd -l /usr/local/bin/PROGA -p 1234 

ProgA - affichera quelques données à intervalles irréguliers. Quand il ne produit pas de données, il envoie une chaîne de type 'heartbeat' toutes les X fois pour informer le client que nous sommes toujours actifs, ie "heartbeat \ r \ n"

Après un temps aléatoire, le client (utilisez une version linux de telnet, lancé par: telnet xxx.xxx.xxx.xxx 1234) ne parviendra pas à recevoir le 'rythme cardiaque \ r \ n'

les données du client voit:

heartbeat 
heartbeat 
heartbeat 
... 
heartbeat 
[nothing, should have received heartbeat] 
[nothing forever] 

rythme cardiaque est envoyé:

result = printf("%s", heartbeat); 

résultat de vérification, il est toujours la longueur de heartbeat. Syslog nous montre que le printf() est l'exécution d'un succès à intervalles appropriés

Je l'ai depuis ajouté dans un tcdrain et fflush qui renvoient toutes les deux succès, mais ne semblent pas aider la situation.

Toute aide serait appréciée.

** UDPATE: obtenu une capture wireshark du côté serveur. Très clairement, le rythme cardiaque est envoyé en continu. Pas de Hicups, pas de retards. J'ai trouvé quelque chose d'intéressant sur le client. Le client dans ce cas de test (telnet sur Ubuntu 9.04) semble soudainement cesser de recevoir le rythme cardiaque (comme décrit ci-dessus). Wireshark le confirme, une grosse pause dans les paquets. Eh bien, une fois que le client a cessé de recevoir la pulsation, appuyer sur n'importe quelle touche (sur le client) semble déclencher un spew de données à partir du tampon du client (toutes les pulsations). Wireshark sur le client montre également cette quantité massive de données tout dans un paquet.

Malheureusement, je ne sais pas vraiment ce que cela signifie. C'est un mode ligne on/off chose? Les fins de ligne (\ r \ n) arrivent très clairement. ** Mise à jour 2: en cours d'exécution netcat au lieu de telnetd, le problème n'est pas reproductible.

Answer 1

La première chose que je ferais est de sortir Wireshark et essayer de savoir si le serveur envoie vraiment le message. Il serait instructif d'exécuter Wireshark sur le serveur ainsi que sur un PC tiers. Y a-t-il quelque chose de différent à propos du dernier battement de cœur?

---

Modifier. Eh bien, c'était une découverte intéressante sur votre client.

Il semble qu'il y ait une sorte de chose terminale dans le chemin. Vous souhaiterez peut-être utiliser le programme netcat plutôt que telnetd. netcat est conçu pour envoyer des données arbitraires sur une session TCP en mode brut, sans aucune mise en forme particulière, et il a la capacité de connecter un processus arbitraire à un socket. Sur une machine Windows, vous pouvez utiliser PuTTY en mode brut pour accomplir la même chose.

Il peut être intéressant d'examiner le trafic avec un tiers entre votre client et votre serveur. Le noyau optimise peut-être les écritures sur le réseau et met en mémoire tampon les données. C'est la seule façon de s'assurer que ce qui se passe est ce qui se passe vraiment sur le fil.