Vernünftige Client Server Kommunikation?

[Smagjus]

Ich habe derzeit ein VB.net Programm, das nach folgendem Schema aufgebaut ist: Der Client baut eine Verbindung zum Server auf und sendet diesem einen Befehl mit Parametern (z.B. 'GET;2012.09.07') zu. Der Server verarbeitet den Befehl und sendet dem Client das Ergebnis. Die Verbindung wird beendet.

Das ist recht einfach und funktioniert auch. Jetzt habe ich aber das Problem, dass mir die Möglichkeit fehlt, Ergebnisse in mehreren Schritten zurückzusenden
Beispiel: 'RESTART' und als Antworten 'Fahre herunter', 'Fahre hoch' und 'Bin fertig'
Der Client würde die letzten beiden Antworten schlicht und ergreifend ignorieren.

Ein Versuch meinerseits ist es, das Ganze so abzuändern, dass ich eine permanente Server - Cient Verbindung aufbaue und nach der Eingabe eines Befehls solange auf Ergebnisse warte, bis ich meine Endzeichen erhalte. Damit ich die Ergebnisse weiterhin zuordnen kann, muss der Server den Namen des Befehls ebenfalls zurücksenden.
Beispiel: 'RESTART' und als Antworten 'RESTART;Fahre herunter', 'RESTART;Fahre hoch' und 'RESTART;Bin fertig[END]'
Kurzgefasst brauche ich eine Lösung für folgenden Ablauf:

1. Client schickt Anfrage
2. Server schickt beliebig viele Antworten bis die Anfrage vollständig abgearbeitet ist

Meine bisherige Lösung gefällt mir überhaupt nicht, auch wenn's irgendwie funktioniert. Gibt es sauberere Möglichkeiten z.B. mit Protokollen? Ich habe davon keine Ahnung, aber vielleicht kennt ja jemand Quellen, wo ich mich schlau machen kann. Oder hat jemand sonst noch hilreiche Tipps? Ich wäre jedenfalls dankbar für alle Bemühungen

 

[Erdmännchen]

worüber sprechen die beiden? WCF oder pure TCP-Socket Verbindung?

 

[MacGyver]

Der Client muss einfach die Verbindung so lange aufrechterhalten und Antworten empfangen bis der Server die Kommunikation beendet. Ich vermute mal, dass jetzt der Client die Verbindung beendet. Mußt du einfach nur umkehren.

Falls du mit "Fahre herunter" und "Fahre wieder hoch" das System oder den Kommunikationsdienst an sich meinst, dann funktioniert das natürlich nicht.
Für sowas könnte mann dann den MSMQ-Dienst von Windows verwenden.

 

[Smagjus]

worüber sprechen die beiden? WCF oder pure TCP-Socket Verbindung?

Letzteres ist der Fall.

Falls du mit "Fahre herunter" und "Fahre wieder hoch" das System oder den Kommunikationsdienst an sich meinst, dann funktioniert das natürlich nicht.

Da hab ich ein blödes Beispiel gewählt. Der Kommunikationsdienst bleibt immer online also bleibt die Verbindung bestehen.

Zum MSMQ-Dienst: Empfängt der anstelle meines Servers die Befehle und lässt den Server diese bei Bedarf abholen? Das klingt gut, aber ich glaube nicht, dass der mein grundlegendes Designproblem löst.

 

[Erdmännchen]

Naja, von den Nachrichten ist das Halten der Verbindung ja erst mal völlig losgelöst.
D.h. erst mal schauen, dass die Verbindung nicht geschlossen wird. Bist du synchron unterwegs oder schon asynchron?
Es gibt einige Beispiele auf codeprojekts:
http://www.codeproject.com/Articles/16916/A-Chat-Application-Using-Asynchronous-TCP-Sockets
http://www.codeproject.com/Articles/1608/Asynchronous-socket-communication

Also erstmal schauen, dass das läuft und wenn, dann kannst du dir überlegen, was du schicken willst.
XML:
+ Schön zu lesen
+ Leicht zu erweitern
+ Leicht zu parsen
- kann schnell sehr groß werden (also die Nachricht)

Plain Binary:
+ winzig
+ nur du weißt, was wofür steht
- schwer zu bauen und zu parsen

Hier findest du auch noch einen Artikel über TCP-Message-Design:
http://www.codeproject.com/Articles/37496/TCP-IP-Protocol-Design-Message-Framing

Ich würde XML nehmen, da es nicht nur einfacher zu lesen ist für dich als Entwickler (ich mein man kann es ja noch verschlüsseln bevor du es sendest, falls es sensible Daten sind), aber du weißt einfach ganz einfach, wenn eine Nachricht falsch ankommt bzw. kaputt ist, weil xml in sich immer geschlossen ist...

EDIT:
Generell musst du bei TCP verstehen, dass es eher ein Stream ist, als ein definiertes senden von Nachricht und Antwort.

 

[MacGyver]

Das klingt gut, aber ich glaube nicht, dass der mein grundlegendes Designproblem löst.

Ich dachte dein Designproblem ist, dass die Verbindung nach der Antwort des Servers beendet wird, du aber gerne mehrere Antworten in variablen zeitlichen ABständen haben möchtest.

Die Lösung wäre also, dass der Client die Verbindung so lange offen hält bis der Server die Verbindung von sich aus beendet.

Dein Beispiel:

C: Connect -> Server
S: Akzeptiert die Verbindung
C: RESTART
S: Fahre herunter
S: Bin fertig
S: Beendet die Verbindung

würde so funktionieren. Das "Bin Fertig" bräuchtet du da nicht mal, denn der Verbindungsabbau wäre das Ende-Signal.

MSMQ ist eine Nachrichtenwarteschlange die auf dem Server läuft. Der Server schmeißt dort Nachrichten rein und der Client kann sie abfragen wann er will. Der Client kann sich auch informieren lassen wenn eine neue Nachricht reingeworfen wird um sie dann gleich abzuholen.

 

[Smagjus]

Die Lösung wäre also, dass der Client die Verbindung so lange offen hält bis der Server die Verbindung von sich aus beendet.

Das ist eine gute Idee, die ich auf jeden Fall mal näher in Augenschein nehmen werde.

Ihr beiden habt mir jetzt relativ Input gegeben, womit ich ne Weile arbeiten kann. Vielen Dank dafür. Wenn sich von meiner Seite aus noch Fragen ergeben, dann meld ich nochmal.