UDP Write Timeout

Hallo zusammen und frohes neues Jahr

Mich quält derzeit eine banale Frage, auf die mir keine eindeutig Antwort einfallen will. Was konkret wird mit dem Timeout Anschluss beim UDP Write bezweckt und wie funktioniert er?
Die Labview Hilfe sagt dazu: timeout ms specifies the time, in milliseconds, that the function waits before the function completes and returns an error. The default value is 25,000 ms or 25 seconds. A value of -1 indicates to wait indefinitely.

Kann man damit ohne Umwege feststellen, ob der Zielhost erreichbar ist indem man die Errorleitung prüft? Falls nein, bleibt mir die Timeoutfunktion schleierhaft.
Das Vi kann auch ausgeführt werden, wenn keine Transmitdaten anliegen. Darf ich davon ausgehen, dass dies keinen Einfluss auf eine Fehlererzeugung hat?

Es sind diese Details, die mir gerade etwas Kopfzerbrechen bereiten und die Hilfe liest sich da etwas schwammig, für mein derzeitiges Verständnis. Es gibt hier sicher den einen oder anderen, der mir das etwas präziser erläutern kann.

Gruß
NoWay

Anzeige

Hallo NoWay,

Zitat:Kann man damit ohne Umwege feststellen, ob der Zielhost erreichbar ist indem man die Errorleitung prüft?

UDP arbeitet ohne Rückmeldung des Zielhosts, also ist es dem Sender egal, ob seine Botschaft auch wirklich ankommt…

Was genau der TimeOut macht, kann ich dir auch nicht genau sagen. Wenn das OS länger als 25s benötigt, um eine UDP-Botschaft entgegenzunehmen und abzuschicken, hast du wahrscheinlich andere Probleme als nur fehleerhaften UDP-Versand…

(05.01.2015 10:47 )GerdW schrieb:  Was genau der TimeOut macht, kann ich dir auch nicht genau sagen. Wenn das OS länger als 25s benötigt, um eine UDP-Botschaft entgegenzunehmen und abzuschicken, hast du wahrscheinlich andere Probleme als nur fehleerhaften UDP-Versand…

Absolut
Das ist aber nicht mein Problem. Die Nachrichtenübermittlung funktioniert ziemlich tadellos. Die Frage kam auf, weil ich eine Timeout Erkennung für die Netzwerkteilnehmer programmieren will. Das ist für mich eine Premiere, weswegen mich dann solche Dinge aus dem Kozept werfen und ich darauf bedacht bin, ALLES zu verstehen, was ich vor mir habe. Eventuell frage ich mal direkt bei NI an. Die Antwort würde ich dann hier posten.

Gruß
NoWay

Ich habe eine Antwort vom Support erhalten.
Sinngemäß schrieb man mir folgendes. Der Timeout Parameter würde greifen, wenn das VI für die Ausführung länger braucht als dort angegeben. Da das VI aber ziemlich fix abgearbeitet wird, kommt diesem Parameter keine nennenswerte Bedeutung bei. Es sei gängig, dass bei Netzwerkfunktionen mit Timeout Parametern gearbeitet wird, weshalb man diesen Parameter im konkreten Fall vermutlich trotzdem inkludiert, obwohl im offenbar keine essentielle Bedeutung zukommt.

Gruß
NoWay

Juchhu: Dann hatte ich ja richtig geraten…

(06.01.2015 08:30 )NoWay schrieb:  Ich habe eine Antwort vom Support erhalten.
Sinngemäß schrieb man mir folgendes. Der Timeout Parameter würde greifen, wenn das VI für die Ausführung länger braucht als dort angegeben. Da das VI aber ziemlich fix abgearbeitet wird, kommt diesem Parameter keine nennenswerte Bedeutung bei. Es sei gängig, dass bei Netzwerkfunktionen mit Timeout Parametern gearbeitet wird, weshalb man diesen Parameter im konkreten Fall vermutlich trotzdem inkludiert, obwohl im offenbar keine essentielle Bedeutung zukommt.

Gruß
NoWay

Er ist für UDP Write (und TCP Write) zumindest auf Desktopsystemen tatsächlich eher von akademischer Bedeutung. Aber der Netzwerktreiber hat eindeutig Beschränkungen wieviel Bufferspeicher er anlagen darf um Daten die von Applikationen über Netzwerk gesendet warden sollen zwischenzuspeichern. Daher ist es theoretisch denkbar dass bei sehr grossen Datenmengen die gewünschten Daten nicht innerhalb von Sekundenbruchteilen an den Netzwerktreiber übergeben werden kann. Bei embedded Systemen wie myRIO und dergleichen ist die verfügbare Performance wesentlich kleiner und wird der Timeout auch für Write Funktionen nicht mehr rein theoretisch.

Und wie richtig angemerkt, Rückkehr von Write ohne Fehler gibt nur an dass die Daten erforlgreich an den Netzwerktreiber übergeben wurden. Das heisst, dass das Socket über das die Netzwerkverbindung gemanaged wird, gültig ist und zumindest eine Netzwerkinfrastruktur vorhanden ist über die diese Verbinding VIELLEICHT erforlgreich abgewickelt warden kann. Meist ist zu dem Zeitpunkt wenn die Write Funktion zurückkehrt erst ein sehr kleiner Teil der Daten oder selbst gar nichts über die Netzwerkkarte verschickt.