La connessione client telnet smette di ricevere dati, il server sta ancora trasmettendo

Question

Sto lavorando in un ambiente Linux incorporato.

avvia un daemon telnet all'avvio che controlla una determinata porta e avvia un programma quando viene ricevuta una connessione.

cioè

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

proga - stamperà alcuni dati a intervalli irregolari. Quando non emette dati, ogni X periodo di tempo invia una stringa di tipo "heartbeat" per far sapere al client che siamo ancora attivi cioè "heartbeat \ r \ n"

Dopo un periodo di tempo casuale, il client (utilizzare una versione Linux di telnet, lanciato da: telnet xxx.xxx.xxx.xxx 1234) non riuscirà a ricevere il 'battito cardiaco \ r \ n'

I dati del cliente vede:

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

battito cardiaco viene inviato:

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

il risultato del controllo, è sempre la lunghezza di heartbeat. Accesso a syslog ci mostra che il printf() è l'esecuzione con successo secondo gli intervalli

allora ho aggiunto in un tcdrain e fflush cui entrambi tornare successo, ma non sembrano aiutare la situazione.

Qualsiasi aiuto sarebbe apprezzato.

** UDPATE: ha ottenuto un'acquisizione di wireshark dal lato server. Molto chiaramente il battito cardiaco viene inviato continuamente. No Hicups, nessun ritardo. Trovato qualcosa di interessante sul client però. Il client in questo test case (telnet su Ubuntu 9.04) sembra smettere improvvisamente di ricevere heartbeat (come descritto sopra). Wireshark lo conferma, grande pausa nei pacchetti. Bene, una volta che il client ha smesso di ricevere l'heartbeat, la pressione di un tasto qualsiasi (sul client) sembra far scattare una serie di dati dal buffer del client (tutti i heartbeat). Wireshark sul client mostra anche questa enorme quantità di dati in un unico pacchetto.

Purtroppo non so davvero cosa significhi. E 'una cosa di linea on/off? Le terminazioni di riga (\ r \ n) stanno attraversando molto chiaramente.

** Aggiornamento 2: netcat in esecuzione anziché telnetd, il problema non è riproducibile.

Answer 1

La prima cosa che vorrei fare è uscire da Wireshark e cercare di scoprire se il server sta veramente inviando il messaggio. Sarebbe istruttivo eseguire Wireshark sul server e su PC di terze parti. C'è qualcosa di diverso nell'ultimo battito cardiaco?

---

Modifica. Beh, questa è stata una scoperta interessante sul tuo cliente.

Sembra che ci sia una specie di terminale nel modo. È possibile utilizzare il programma netcat anziché telnetd. netcat è progettato per inviare dati arbitrari su una sessione TCP in modalità raw, senza alcuna formattazione speciale, e ha la capacità di collegare un processo arbitrario a un socket. Su un computer Windows è possibile utilizzare PuTTY in modalità raw per ottenere la stessa funzionalità.

Si può essere ancora la pena di esaminare il traffico con un terzo tra il client e il server. È possibile che il kernel stia ottimizzando le operazioni di scrittura sulla rete e il buffering interno dei dati. Questo è l'unico modo per garantire che ciò che vedono è ciò che sta realmente accadendo sul filo.