TCP IP - FIFO ?

Nur ganz kurz ne Nachfrage:

Ist bei TCP IP (in Labview sowohl für Empfänger als auch Sender) sichergestellt, dass First in First out gilt?

Konkret geht es darum:
Ich habe eine Kommunikation realisiert die auf beiden Rechnern jeweils sendet und anschließend auf Empfang der Antwort wartet (soweit ja kein Problem, da bekannt ist worauf sich die Antwort bezieht). Das krankt natürlich im Zweifel daran, dass in der Zeit bis die Antwort kommt nichts anderes gesendet (daher vom Target angefragt werden) kann. Entsprechend wollte ich zu einer asynchronen Kommunikation übergehen wollen in der ich beliebig viele Anfragen versende (ohne quasi durch den Ping festgelegte Wartezeit dazwischen) und auch die Antworten entsprechend Empfange. Dann muss ich nur noch zuordnen welche Antwort zu welcher Anfrage gehört.

Wenn FIFO sichergestellt ist (wichtig dabei: auf beiden Seiten existiert nur ein Datenproduzent), dann brauche ich dafür ja nur eine Liste mit "pending requests" in der Reihenfolge wie die rausgegangen sind (da das der Abarbeitungsreihenfolge und damit auch der Antwortreihenfolge auf der Gegenseite entspricht).

Falls nein müsste ich die Messages noch um unique IDs etc. ausbauen.

Gruß Kiesch

P.S: Schönes Wochenende ^^

Anzeige

(08.02.2013 15:21 )Kiesch schrieb:  Falls nein müsste ich die Messages noch um unique IDs etc. ausbauen.

FiFo: Grundsätzlich ja.

Unique IDs: Das würde ich in jedem Fall tun. Es kann ja Unterbrechungen der Verbindung geben. Dann kann man rekonstruieren, was erneut gesendet werden muss, und welche Antworten schon bearbeitet wurden.

Gruß Holger

TCP garantiert korrekte Reihenfolge, im Gegensatz zu UDP. Aber eine unique ID ist oft eine gute Idee wenn Du asynchron arbeiten willst. Dann brauchst Du nicht mühsam eine bestimmte Reihenfolge der Requests irgendwo zwischenzuspeichern sondern kannst im Empfänger direkt die Antwort auf Basis der ID an die entsprechende Komponente liefern.

Was für mich gegen die Unique ID spricht ist, dass die irgendwann überläuft (was ich entsprechend abfangen muss ^^ na ja...) Aber joah werd ich dann wohl so machen. Immerhin gut zu wissen, dass TCP / IP auch FIFO garantiert.

@Rolf
Im Prinzip kommuniziere ich mit einer Messsoftware an nem anderen Rechner (die nur da vorhandene Hardware ausliest). Und ja ich weiss dass man den Zweck im wesentlichen wahrscheinlich sogar über shared network variables erreichen könnte, nur habe ich nicht die Möglichkeit beide Rechner auf der gleichen LV Version zu halten (der eine ist und bleibt 8.2 der andere soll möglichst aktuell sein, damit man anständig dran programmieren kann; keine Ahnung ob Labview das dann überhaupt kann).


Wie auch immer; heist also:

Ich brauche auf beiden Rechnern jeweils genau eine Schnittstelle die die eigentliche Kommunikation verwaltet (mindestens um sicherzustellen, dass die ID auch einzigartig ist) - zumindest jedenfalls eine pro Port den ich nutze.

Für die Verteilung würde man dann quasi sowas speichern wie: Cluster aus Unique ID (der ausgehenden Nachricht) + wo die Nachricht hinmuss (wenn man die dann weiter verteilt).

Stelle mir vor, da könnte am günstigsten eine Queue für sein. Bei jedem Senden schmeiße ich da einen weiteren Cluster ans Ende. Für Fehlersuche bei Verbindungsabbruch würde man beim Auslesen dann entsprechend die IDs vergleichen, wenn die übereinstimmen senden, wenn nicht die Fehlerbehandlung einleiten.


Wie sieht das eigentlich bei Verbindungsabbruch aus, werden da Teile gesendet oder wird entweder komplett oder garnicht gesendet (eine Send Operation)? Und wie ist das mit dem Timeout? Ich habe schon gesehen, dass das Verhalten bei Timeout konfigurierbar ist, aber schlau geworden bin ich daraus nicht wirklich (aus der LV Hilfe):
Behalte ich dann "schon angekommene" Daten im Buffer oder muss ich die nach dem Timeout aufheben, feststellen wie viele bytes weniger ich lesen muss etc. zur Fehlerbehandlung?

Achja, nochwas: Reicht es wenn ich eine datenintensive Verbindung auf eine separate Verbindung lege um sicherzustellen, dass die Funktionen mit höherer Priorität auch relativ sicher und schnell übertragen werden werden (ich muss quasi einen Videostream übermitteln - habe auf einem Rechner ne Kamera die ich über IMAQdx auslese, brauche das Bild aber auf dem anderen - die zur Verfügung stehende Bandbreite würde ich dann im wesentlichen über einstellbare FPS berücksichtigen (sprich: Je langsamer die Verbindung, desto weiter muss ich die FPS drosseln).

Gruß Kiesch

P.S: Danke schonmal für die bisherigen Infos.

Hi

Sie Dir doch mal das Beispiel LabVIEW 2012\examples\general\queue.llb\Network Queue Example\Network Queue.lvproj an.

Da wird gezeigt, wie Du auf Applikationsebene mit Queues arbeiten und den Netzwerktransfer kapseln kannst. Dort kannst Du auch das Wiederverbinden bei Unterbrechung etc. einbauen.

Gruß Holger

Hab mir das mal grade angeschaut. Die Verwendung von Dienstenamen war mir vorher so noch nicht ganz klar.

Ansonsten ist das grob das woran ich auch gedacht hatte. Einzig die Racing Condition die man bei den Schleifen im Client VI eingebaut hat verwirrt mich (es ist nicht direkt klar welche Schleife zuerst aus der Queue liest und wer dann wann wie die Daten kriegt etc; ist für ein Beispiel vielleicht nicht optimal gewählt; es sei denn man würde explizit auf Parrallelverarbeitung gleichartiger Dinge hinauswollen).

Die Bezeichnung ist für mich auch nicht ganz intuitiv (für mich sollte der Server Listener sein, da der Client ja normal erst gestartet wird wenn der Server schon läuft (und das Verbindung aufbauen ja im Gegensatz zum Listener nach glaube 60s spätestens immer nen Timeout kriegt (egal was eingestellt ist).

Na ja, danke für den Tipp :-)

Werd mal deinen Beitrag als Lösung markieren, da das Beispiel grundsätzlich echt hilfreich ist.

Gruß Kiesch

P.S: Wer noch weiteres beizutragen hat kann das immer noch gerne tun :-)

Anzeige

Hier ist auch was, was in dem Zusammenhang vielleicht interessant sein könnte (Bsp. "Network Streaming"):
http://www.labviewforum.de/Thread-Networ...#pid122454

Gruß Markus

Hatte ich bewusst nicht benutzt und erwähnt da erst seit LV 2011 verfügbar. Außerdem würde ich mich auf solche Funktionen nicht zwingend verlassen wollen, wenn ich auf beiden Rechnern unterschiedliche LV versionen habe (wäre zumindest skeptisch ob das auch langfristig funktioniert wenn man die eine Version regelmäßig updatet und die andere nicht).

Ansonsten aber ein sehr gutes Feature finde ich (fasst ja quasi die Funktion einer gerichteten [sic!] Queue übers Netzwerk zusammen).