Konfiguration

Die zusätzlichen Parameter befinden sich in den Netzwerkeinstellungen der COM-Ports.

WEBconfig: LCOS-Menübaum / Setup / COM-Ports / COM-Port-Server / Netzwerk-Einstellungen

• Nehme-Binaermodus-anManche Netzwerkgeräte, die an einem seriellen COM-Port angeschlossen sind, versenden Datenstrukturen, die als Steuerzeichen (CR/LF – Carriage Return / Line Feed) interpretiert werden können. In der Standardeinstellung werten die COM-Ports in den Geräten diese Informationen aus, um den Datenfluss zu steuern. Mit dem “Binärmodus” kann ein COM-Port angewiesen werden, alle Daten binär weiterzuleiten und keine Anpas­sungen dieser Steuerzeichen vorzunehmen. Mögliche Werte:
  • Ja, nein.
  Default:
  • Nein.
• Newline-KonversionWählen Sie hier aus, welches Zeichen auf dem seriellen Port ausgegeben wird, wenn der Binär-Modus aktiviert ist. Die Einstellung ist abhängig von der Anwendung, die über den seriellen Port kommunizieren wird. Wenn an den Port ein weiteres Gerät angeschlossen ist, können Sie hier entweder CRLF oder nur CR wählen, da die Outband-Schnittstelle dieser Geräte ein “Carriage Return” zur automatischen Bestimmung der Datenübertrag­ungsgeschwindigkeit erwartet. Manche Unix-Anwendungen würden CRLF allerdings als unerlaubte doppelte Zeilenschaltung interpretieren, in diesem Fall wählen Sie CR oder LF. Mögliche Werte:
  • CRLF, CR, LF
  Default:
  • CRLF
  Anmerkung: Diese Einstellung wird nur ausgewertet, wenn für diesen seriellen Port der Binär-Modus deaktiviert ist.
• TCP-KeepaliveDer RFC 1122 definiert ein Verfahren, mit dem die Verfügbarkeit von TCP-Verbindungen geprüft werden kann (TCP-Keepalive). Ein inaktiver Transmitter sendet nach diesem Verfahren Anfragen nach dem Empfängerstatus an die Gegenstelle. Wenn die TCP-Sitzung zur Gegenstelle verfügbar ist, antwortet diese mit ihrem Empfängers­tatus. Wenn die TCP-Sitzung zur Gegenstelle nicht verfügbar ist, wird die Anfrage in einem kürzeren Intervall solange wiederholt, bis die Gegenstelle mit ihrem Empfängerstatus antwortet (danach wird wieder ein längeres Intervall verwendet). Sofern die zugrunde liegende Verbindung funktioniert, die TCP-Sitzung zur Gegenstelle allerdings nicht verfügbar ist, sendet die Gegenstelle ein RST-Paket und löst so den Abbau der TCP-Sitzung bei der anfragenden Applikation aus. Mögliche Werte:
  • inaktiv: Der TCP-Keepalive wird nicht verwendet.
  • aktiv: Der TCP-Keepalive ist aktiv, nur RST-Pakete führen zum Abbau von TCP-Sitzungen.
  • proaktiv: Der TCP-Keepalive ist aktiv, wiederholt die Anfrage nach dem Empfängerstatus der Gegenstelle aber nur für den als “TCP-Wdh.-Zahl” eingestellten Wert. Sofern nach dieser Anzahl von Anfragen keine Ant­wort mit dem Empfängerstatus vorliegt, wird die TCP-Sitzung als “nicht verfügbar” eingestuft und an die Applikation gemeldet. Wird während der Wartezeit ein RST-Paket empfangen, so löst dieses vorzeitig den Abbau der TCP-Sitzung aus.
  Default:
  • inaktiv
  Anmerkung: Für Serverapplikationen wird die Einstellung “aktiv” empfohlen.
• TCP-Keepalive-IntervallDieser Wert gibt an, in welchen Intervallen die Anfragen nach dem Empfängerstatus versendet werden, wenn die erste Anfrage nicht erfolgreich beantwortet wurde. Der dazu gehörende Timeout wird gebildet als Intervall / 3 (maximal 75 Sekunden). Mögliche Werte:
  • maximal 10 Ziffern
  Default:
  • 0
  Besondere Werte:
  • 0: verwendet den Standardwert nach RFC 1122 (Intervall 7200 Sekunden, Timeout 75 Sekunden).
• TCP-Wdh.-TimeoutMaximale Zeit für den Retransmission-Timeout. Dieser Timeout gibt an, in welchen Intervallen der Zustand einer TCP-Verbindung geprüft und das Ergebnis an die Applikation gemeldet wird, welche die entsprechende TCP-Ver­bindung nutzt. Mögliche Werte:
  • 0 bis 99 Sekunden.
  Besondere Werte:
  • 0 verwendet den Standardwert nach RFC 1122 (60 Sekunden).
  Default:
  • 0
  Anmerkung: Die maximale Dauer der TCP-Verbindungsprüfung wird aus dem Produkt von TCP-Wdh.-Timeout und TCP-Wdh.-Zahl gebildet. Erst wenn der Timeout für alle Versuche abgelaufen ist, wird die entsprechende TCP-Anwendung informiert. Mit den Standardwerten von 60 Sekunden Timeout und maximal 5 Versuchen kann es bis zu 300 Sekunden dauern, bis eine nicht aktive TCP-Verbindung von der Applikation erkannt wird.
• TCP-Wdh.-ZahlMaximale Anzahl der Versuche, mit denen der Zustand einer TCP-Verbindung geprüft und das Ergebnis an die Applikation gemeldet wird, welche die entsprechende TCP-Verbindung nutzt. Mögliche Werte:
  • 0 bis 9
  Besondere Werte:
  • 0 verwendet den Standardwert nach RFC 1122 (5 Versuche).
  Default:
  • 0
  Anmerkung: Die maximale Dauer der TCP-Verbindungsprüfung wird aus dem Produkt von TCP-Wdh.-Timeout und TCP-Wdh.-Zahl gebildet. Erst wenn der Timeout für alle Versuche abgelaufen ist, wird die entsprechende TCP-Anwendung informiert. Mit den Standardwerten von 60 Sekunden Timeout und maximal 5 Versuchen kann es bis zu 300 Sekunden dauern, bis eine nicht aktive TCP-Verbindung von der Applikation erkannt wird.