Per il nostro progetto, viene specificato un protocollo per la comunicazione tra un dispositivo Linux incorporato e un PLC / HMI. Questo protocollo include il controllo CRC.
Tuttavia, la comunicazione viene ora eseguita su TCP (il protocollo TCP include CRC), quindi la mia domanda è se un CRC in cima al TCP abbia qualche significato?
TCP fornisce un servizio di trasporto affidabile e con verifica degli errori. Il controllo degli errori è doppio:
Poiché entrambi i calcoli utilizzano algoritmi indipendenti, le probabilità che un errore rimanga non rilevato sono inferiori a 1/2 ^ 48. Questo calcolo si basa sulle probabilità per il CRC32 e sul checksum e sul fatto che CRC32 rileva il 100% degli errori di trasmissione più probabili.
Quindi, a meno che il tuo CRC legacy sia lungo più di 48 bit (ad esempio CRC-64), il mantenimento di esso non avrebbe alcun vantaggio rispetto alla vecchia situazione senza TCP.
La stratificazione del modello OSI può essere utilizzata per guidare il progetto, senza dover necessariamente entrare in situazioni probabilistiche dibattiti. Il principio è che ogni livello è responsabile di qualcosa e fa affidamento sulle garanzie offerte dai livelli inferiori.
Quindi, se l'applicazione non deve più gestire i livelli inferiori del trasporto (rete, datalink), è possibile eliminare i controlli degli errori già eseguiti in questi livelli.
Il controllo dei livelli superiori dello stack del protocollo potrebbe aggiungere valore. Quindi verificare il corretto formato dei dati e la codifica (livello di presentazione), assicurando l'integrità usando mezzi crittografici (livello di presentazione) o eseguendo verifiche specifiche del dominio dell'applicazione sarebbero comunque rilevanti.
Il checksum TCP non cattura tutti gli errori perché è troppo piccolo. Riuscirà a catturare la maggior parte degli errori e ogni pochi GB o TB di dati inviati potrebbero essere corretti non rilevati. La corruzione porterà a dati diversi che mappano allo stesso CRC per coincidenza.
I dati TCP interrotti si verificano di tanto in tanto. Immagino che sia notato raramente perché la gente si aspetta che le cose della rete vengano casualmente fallire qualche volta Inoltre, la corruzione casuale è sempre una tantum e una causa difficile da raggiungere.
Secondo me questo è un difetto di progettazione in TCP. Fa in modo che tutti i livelli superiori accettino la corruzione molto rara o eseguano il proprio controllo.
Alcune persone saranno sorprese da questo fatto perché il protocollo TCP viene spesso propagandato come privo di corruzione. Non è il caso.
Il tuo CRC aggiuntivo potrebbe benissimo prevenire alcuni errori. Se vuoi davvero nessun errore, hai ancora bisogno di un checksum più strong (probabilmente un hash crittografico).
Leggi altre domande sui tag tcp