Timeout infiniti o "fail fast" nel protocollo di rete personalizzato?

Question

Considera il protocollo di rete personalizzato. Questo protocollo personalizzato può essere utilizzato per controllare le periferiche robotizzate su LAN dalla workstation basata su .NET centrale. (Se è importante, il robot è impegnato a spostare fab nell'ambiente di produzione di chip).

• ci sono solo 2 parti in conversazione: stazione .NET e scheda periferica robotica
• il lato robot può solo ricevere richieste e inviare risposte
• il lato .NET può solo avviare richieste e ricevere risposte
• dovrebbe sempre esserci esattamente una risposta per richiesta
• le richieste conseguenti possono seguire immediatamente una dopo l'altra senza attendere la risposta, ma non superare mai il limite fisso di richieste simultaneamente servite (ad esempio 5)

Ho avuto un'esaustiva discussione con il mio amico (che possiede il progetto, ho discusso della cosa come spettatore) su tutti i dettagli e le idee carine. Alla fine della discussione abbiamo avuto un forte disaccordo sui timeout mancanti. L'argomento del mio amico è che il software su entrambi i lati dovrebbe attendere indefinitamente. La mia tesi era che i timeout sono sempre necessari per qualsiasi protocollo di rete. Semplicemente non potremmo mai essere d'accordo.

Uno dei miei ragionamenti è che in caso di guasti dovresti "fallire velocemente". qualunque sia il costo, perché se si sono già verificati guasti, i costi di recupero continuano a crescere proporzionalmente al tempo impiegato per ricevere informazioni sui guasti. Di 'che dopo 1 minuto su LAN dovresti assolutamente smettere di aspettare e solo invocare un allarme.

Ma la sua argomentazione era che il recupero dovrebbe includere esattamente la riparazione di ciò che non ha funzionato (in questo caso il ripristino della connessione di rete) e anche se ci vogliono ore per capire che la rete è stata persa e riparata, il software dovrebbe semplicemente continuare in modo trasparente in esecuzione, immediatamente dopo aver ricollegato i cavi LAN.

Non avrei mai pensato seriamente a protocolli senza tempo, fino a questa discussione.

Quale lato dell'argomento è giusto? Il " fail veloce " o " mai fallire " ?

Modifica: un esempio di errore è la perdita di comunicazione, normalmente rilevata dal livello TCP. Anche questa parte è stata discussa. In caso di errore di restituzione del livello TCP, il livello di protocollo personalizzato superiore riproverà a inviare e non vi è alcun argomento al riguardo. La domanda è: per quanto tempo consentire al livello inferiore di continuare a provare?

Modifica per risposta accettata: La risposta è più complessa di 2 scelte: " L'approccio più comune non è mai rinunciare alla connessione fino a quando il tentativo effettivo di invio fallisce con una solida conferma che la connessione è persa da tempo. Per calcolare che la connessione viene persa da tempo, utilizza i battiti del cuore, ma mantieni l'età della perdita solo per questa conferma, non per un allarme immediato " ;.

Esempio: quando si ha una sessione telnet, è possibile mantenere il proprio terminale per sempre e non si sa mai se tra il colpire Enter si sono verificati guasti rilevabili da routine di livello inferiore.

Answer 1

Preferisco il tuo " fallimento veloce " metodo, ma come penso che tu abbia scoperto, questo è altamente preferenziale.

Le apparecchiature Cisco con cui lavoro funzionano in modo molto simile: invii una richiesta e rispondono. (Su telnet.) Il problema è quando la rete non funziona: perdo la connessione TCP. Tuttavia, nessuna delle due parti chiuderà quella connessione fino a quando non viene tentato un invio di dati e poiché raramente il lato Cisco lo fa, non si chiude mai. Peggio ancora, puoi avere solo 1 connessione alla volta, quindi se c'è un errore di rete, sei bloccato. (Possono essere ripristinati, ma è solo una seccatura.)

Ora, per testare una connessione di rete, hai bisogno di una sorta di ping, solo un " sei ancora lì? " - molti protocolli lo fanno, come AIM e IRC. Ma questi ping costano larghezza di banda, a seconda della frequenza con cui li invii.

Quindi, il rilevamento degli errori vale il costo in termini di larghezza di banda? Quanto deve essere grande un ping? Direi che dovresti riuscire a portarlo a & 50 lt; 50 ottetti / ping, e potresti fare il ping una volta ogni 10, 30, 1 m, qualcosa del genere, direi che ne vale la pena. Prima sai di avere un problema, meglio è. Se il software stesso può quindi utilizzare questi ping per sapere che ha perso la connessione e ristabilire automaticamente il contatto, direi che è fantastico, sulla falsariga di "Computer, guarire te stesso" e rende meno fastidi per l'operatore.

Se stai usando TCP / IP, può farlo automaticamente per te - vedi TCP Keepalives. In alternativa, puoi farlo all'interno del protocollo della tua applicazione, come AIM & amp; IRC do.

Answer 2

Nello scenario in cui ...

• Il controller ha inviato una richiesta
• Il robot non ha ricevuto la richiesta
• Errore di rete

... quindi la richiesta è stata inviata, ma è andata persa e non arriverà mai.

Pertanto, quando la rete viene ripristinata, il controller deve inviare nuovamente la richiesta: il controller non può semplicemente attendere per sempre la risposta.