TCP / IP gleichzeitig Lesen und Schreiben

Hallo liebe LFVler,

bin mir grade etwas unsicher, deswegen Frage ich mal nach:

Bei TCP / IP hat man ja immer quasi einen getrennten Upstream (ausgehende Kommunikation) und Downstream (eingehende Kommunikation) zur Verfügung die Sauber getrennt werden (im Gegensatz zur Queue kann man was man selbst geschrieben hat nicht wieder lesen, das kann nur die Gegenseite).

Heist dass auch, dass ich im gleichen Programm von der gleichen Netzwerkreferenz auch gleichzeitig Lesen und Schreiben kann?

Konkretes Problem: Ich will ne Camera das IMAQ Bild zu nem anderen Rechner Streamen lassen. Eine Schleife handhabt ausschließlich ausgehende Kommunikation und abgreifen der Camera. Die andere Schleife handhabt die eingehende Kommunikation und die daraus resultierende Programmsteuerung (sprich: Setzt optionen nach denen sich die erste Schleife richtet etc., sowas wie kontinuierlich stream, ein einzelbild streamen etc.).

Muss ich da mit Semaphoren sicherstellen, dass keine der beiden Schleifen genau dann zugreifen kann, wenn die andere grade sendet (bzw. empfängt) oder kann ich das getrost ignorieren, da mir das LV / Windows ohne weiteren Aufwand schon sicherstellen?

Gruß Kiesch

(27.02.2013 15:59 )Kiesch schrieb:  Heist dass auch, dass ich im gleichen Programm von der gleichen Netzwerkreferenz auch gleichzeitig Lesen und Schreiben kann?

Ja, die selbe Referenz kannst Du in 2 Schleifen benutzen.

(27.02.2013 15:59 )Kiesch schrieb:  Muss ich da mit Semaphoren sicherstellen, dass keine der beiden Schleifen genau dann zugreifen kann, wenn die andere grade sendet (bzw. empfängt) oder kann ich das getrost ignorieren, da mir das LV / Windows ohne weiteren Aufwand schon sicherstellen?

Wenn es wirklich jeweils 2 rein unidirektionale Kanäle sind, kannst Du ohne eigene Zusatzlogik arbeiten.
Liefern denn die Kommandos keine Statusanworten zurück? Die würden dann möglicherweise plötzlich zwischen den Bildern/im Stream auftauchen und diese Seite dann Softwaremäßig verkomplizieren.

Ich sollte so oder so asynchron arbeiten oder doch zwei Kanäle benutzen, da sonst die Netzwerkverbindung im Zweifel ausbremst (schon 25 Bilder pro Sekunde gehen nur flüssig bei 20ms Ping wenn man jeweils auf Antwort wartet).

Werde entweder auf Rückmeldung verzichten (es geht ja "nur" um einen Bilderstream der von einem Benutzer angeschaut wird - im zweifel merkt der Benutzer also wenn der weg ist und kann was gegen tun).

Wahrscheinlicher werde ich aber wohl einfach vor jedes gesendete Kommando noch einen Typ einfügen, der genauer bezeichnet was da kommt ("image", "status" und sowas) so dass auf der Gegenseite daraus einfach nur fortlaufend gelesen und entsprechend Typ verarbeitet werden muss. Die Rückmeldungen dienen ja wenn überhaupt nur dazu den Gerätestatus zu aktualisieren.

Gruß Kiesch