Passa al contenuto principale
"L'applicazione funziona bene da anni, la scorsa settimana la rete è stata aggiornata e siamo passati da 100 mbps a gigabit. Ora l'ultima metà dei dati in alcuni messaggi è spazzatura. La gente della rete giura che non è la rete - ma è l'unica cosa che è cambiata".

 

La buona notizia è che il costoso aggiornamento della rete non ha interrotto l'applicazione.

 

La cattiva notizia è che l'applicazione è rotta e lo è sempre stata. Quello che *molti* che scrivono applicazioni TCP non si rendono conto è che il TCP è un flusso di byte, non di messaggi. Il fatto che un'applicazione invii due messaggi da 1000 byte non significa che lo stack TCP di invio invierà due segmenti TCP da 1000 byte. I messaggi dell'applicazione possono essere segmentati in pezzi più piccoli in base alla dimensione massima del segmento del destinatario o a qualche limitazione di configurazione sul mittente. Le ritrasmissioni possono anche combinare e frammentare i messaggi dell'applicazione. Anche se lo stack TCP di invio invia effettivamente due segmenti TCP da 1000 byte non c'è garanzia che lo stack TCP di ricezione dia all'applicazione ricevente due messaggi da 1000 byte. Per esempio, se il buffer dell'applicazione è di soli 500 byte che è tutto lo stack TCP restituirà. D'altra parte se il buffer è di 1500 byte ed entrambi i segmenti da 1000 byte sono arrivati, lo stack TCP restituirà 1500 byte nella prima chiamata e 500 nella seconda. Spetta all'applicazione prendere il flusso di byte e analizzarlo correttamente in messaggi.

 

Che cosa ha a che fare questo con l'aggiornamento della rete? Beh, il server OpenVOS e il client Linux erano su diverse sottoreti, quindi il sistema OpenVos stava pubblicizzando una dimensione massima del segmento di 536 byte. I messaggi dell'applicazione inviati dal client erano 1000 byte quindi i messaggi erano segmentati in 2 pezzi. Prima dell'aggiornamento sembra che entrambi i segmenti arrivassero al server OpenVOS prima che l'applicazione pubblicasse la sua ricezione, quindi tutti i 1000 byte venivano letti con una sola chiamata alla funzione di ricezione. Dopo l'aggiornamento la tempistica dei segmenti è cambiata in modo che in alcuni casi solo il primo segmento era disponibile quando l'applicazione ha inviato la sua ricezione. Gli ultimi 464 (1000 - 536) byte del buffer dell'applicazione non sono stati riempiti dallo stack TCP e contenevano la spazzatura che c'era prima della ricezione.

 

In questo caso c'è stata una facile soluzione rapida, aumentare il valore MSS pubblicizzato da OpenVOS a 1460 (vedi Un modo semplice per migliorare il throughput TCP attraverso le sottoreti). Questo però è in realtà solo un gap di stop. La vera soluzione sarà quella di riscrivere il codice per analizzare correttamente il flusso di byte TCP nei messaggi dell'applicazione invece di supporre che 1 chiamata in ricezione restituisca 1 messaggio.

© 2024 Stratus Technologies.