Unendlichen Timeouts oder „nicht bestanden schnell“ in den kundenspezifischen Netzwerkprotokoll?

Question

Betrachten Sie benutzerdefinierte Netzwerkprotokoll. Dieses kundenspezifische Protokoll verwendet werden könnte Roboter-Peripheriegeräte über LAN zur Steuerung von zentraler .NET basierter Workstation. (Wenn es wichtig ist, ist der Roboter beschäftigt sich bewegende Fabs in der Chip-Produktionsumgebung).

• gibt es nur zwei Parteien im Gespräch: .NET-Station und Roboterperipheriekarte
• die Roboter-Seite kann nur Anfragen empfangen und senden Antworten
• die .NET-Seite kann nur Anfragen initiieren und erhalten Antworten
• Es sollte immer genau eine Antwort pro Anfrage
• können die daraus resultierenden Anfragen folgen unmittelbar nacheinander, ohne die Antwort abzuwarten, aber nie die feste Grenze von gleichzeitig bedient Anfragen (zum Beispiel 5) nicht überschreiten

Ich hatte erschöpfende Diskussion mit meinem Freund (wer das Design besitzt, ich das Ding als Bystander besprochen habe) über alle schöne Details und Ideen. Am Ende der Diskussion hatten wir starke Uneinigkeit über fehlende Timeouts. Mein Freund Argument ist, dass die Software auf beiden Seiten auf unbestimmte Zeit warten soll. Mein Argument war, dass Timeouts wird immer von jedem Netzwerk-Protokoll benötigt. Wir konnten einfach nie zustimmen.

Einer meiner Argumentation ist, dass im Fall eines Fehlers sollten Sie „fail fast“ jeden Preis, denn wenn der Fehler bereits ohnehin aufgetreten ist, Kosten für die Wiederherstellung proportional wachsen weiter zu Zeit eine Info über das Scheitern erhalten verbracht. Sagen Sie nach 1 Minute auf LAN Sie sollten auf jeden Fall aufhören warten und nur einige Alarm aufrufen.

Aber sein Argument war, dass die Erholung sollte auch genau die Reparatur von dem, was fehlgeschlagen ist (in diesem Fall Wiederherstellung der Netzverbindung) und auch wenn es dauert Stunden verbringen dieses Netzwerk, um herauszufinden, war verloren und fixiert ist, sollte die Software auch weiterhin nur transparent ausgeführt wird, unmittelbar nach dem die LAN-Kabel anschließen.

Ich würde denken, nie ernsthaft über zeitlose Protokolle, bis dieser Diskussion.

Welche Seite der Argumentation ist richtig? Das "fail schnell" oder "never fail"?

Edit: Beispiel des Scheiterns ist der Verlust der Kommunikation, in der Regel durch TCP-Schicht festgestellt. Dieser Teil wurde ebenfalls diskutiert. Im Fall eines TCP-Schicht Fehler zurückgegeben, desto höher benutzerdefinierte Protokollschicht wird erneut versuchen sendet und es gibt kein Argument darüber. Die Frage ist: wie lange die untere Ebene zu ermöglichen, zu halten versuchen,

Bearbeiten für akzeptierte Antwort: Antwort ist komplexer als 2 Möglichkeiten: „ Der gängigste Ansatz gibt nie Verbindung bis tatsächlicher Versuch mit solider Bestätigung nicht zu senden, dass die Verbindung verloren geht lange, dass die Verbindung zu berechnen, lange Nutzung Herzschläge verloren, aber haltes Alter von. Verlust für diese Bestätigung nur, nicht für den sofortigen Alarm “.

. Beispiel: Wenn Telnet-Sitzung, so können Sie Ihren Terminal halten ewig und man weiß nie, ob zwischen hitting dort eingeben waren Ausfälle nachweisbar durch niedrigere Level-Routinen

Answer 1

ich es vorziehen, Ihre „schnell fail“ Methode, aber, wie ich glaube, Sie haben entdeckt, ist dies sehr bevorzugt.

Cisco-Geräte, die ich mit der Arbeit arbeiten sehr ähnlich - Sie eine Anfrage schicken, sie reagieren. (. Über Telnet) Das Problem ist, wenn das Netzwerk ausfällt: Ich löse die TCP-Verbindung. keine der beiden Seiten werden jedoch schließen, dass die Verbindung, bis ein Datens versucht wird, und da die cisco Seite selten tut, es ist nie geschlossen. Schlimmer noch, können Sie nur 1 Verbindung zu einem Zeitpunkt, also, wenn es Netzwerkfehler ist, sind Sie gesperrt. (Sie können zurückgesetzt werden, aber es ist ein nur ein Streit.)

, nun eine Netzwerkverbindung zu testen, müssen Sie irgendeine Art von Ping, nur ein „Sie sind immer noch da?“ - viele Protokolle tun dies, wie AIM und IRC. Aber diese Pings kosten Bandbreite, je nachdem, wie oft sie Sie senden.

So ist die Fehlererkennung der Kosten der Bandbreite wert? Wie groß muss ein Ping wirklich sein? Ich würde sagen, man sollte es in der Lage sein, sich auf <50 Oktetts / ping, und man konnte wie einmal alle 10s, 30s, 1m, so etwas wie das ping, ich würde sagen, es lohnt sich. Je früher Sie wissen, Sie haben ein Problem, desto besser. Wenn die Software selbst dann diese Pings können wissen, verloren sie die Verbindung und wieder Kontakt automatisch, würde ich sagen, das ist toll, nach dem Vorbild der „Computer, heile dich selbst“, und sorgt für weniger Aufwand für den Betreiber.

Wenn Sie TCP / IP verwenden, können sie dies automatisch für Sie tun - siehe TCP Keep Alive. Alternativ können Sie es innerhalb Protokoll Ihrer Anwendung, wie AIM & IRC tun.

Answer 2

In dem Szenario, wo ...

• Controller hat eine Anforderung
gesendet
• Robot hat die Anforderung nicht empfangen
• Netzwerk ausfällt

... dann hat die Anfrage gesendet wurde, aber verloren gegangen ist und wird nie ankommen.

Wenn daher das Netz wiederhergestellt wird, muss der Controller die Anforderung erneut senden. Kann der Controller einfach nicht ewig warten auf die Antwort