Modifica ad un protocollo, quale vi piace di piú?

[nicsergio]

Anch'io dal primo post non avevo compreso il "contorno" e le proposte le avevo viste abbastanza equivalenti, se finora è stato fatto uno sforzo implementando con la filosofia descritta e con l'obiettivo dell'information hiding, direi che la cosa più sensata è continuare in questa direzione e, se possibile, evitare di passare informazioni non necessarie.

[luxinterior]

Arrivo tardi la scrivo solo per discuterne assieme
E se si "giocasse" con la ckechsum

Rimane tutto uguale ma i messaggi nuovi hanno checksum calcolata in modo diverso
I dispositivi vecchi ricevono messaggio calcolano checksum che nel caso di messaggio con indirizzo a 16bit sarà sbagliata e scartano il messaggio.
I dispositivi nuovi calcoleranno due checksum per capire se messaggio con indirizzo 8 o 16bit
Rimarrebbero compatibili per eventuale sostituzione anche su impianti con dispositivi che hanno decodifica a 8bit.

Problema, ....forse non da poco, un errore nel messaggio che porta a validare la checksum sbagliata e quindi a considerare il messaggio in modo diverso. Errore che forse potrebbero catturare i controlli dello strato superiore del protocollo

[fairyvilje]

No. Mi permetto di dire che è una pessima idea.
Primo, andrebbero considerate le collisioni sul checksum. Dovresti costruire una funzione hash per la quale dimostri che non sia possibile in nessuna circostanza ottenere un risultato identico alla vecchia in modo da poterli sempre separare. Altrimenti alcune trasmissioni sarebbero ambigue, che è tipo ciò che nessuno vuole.
Secondo. La checksum serve come checksum. Sarebbe come avere la serratura sulla porta ma lasci la chiave appesa davanti. Una checksum ha lo scopo preciso di identificare errori nel canale, alle volte correggerli o per lo meno permettere una risincronizzazione fra i dispositivi. Se tu di design distruggi il checksum per dargli valore informativo esplicito non hai più un checksum.