Moin,

ich habe ein C#-Programm vor mir, was mit einem TCP-Client arbeitet und mit einem Gerät in Verbindung steht. Da wird für jede einzelne Kommunikation ein TCP-Client erzeugt, verbunden, kommuniziert und dann wieder getrennt und frei gegeben.
Der Abfragezyklus läuft ständig und mit etwa 5 Hz (dahinter jedesmal eine Liste mit 4-6 Aufrufen).
Da sind wir also ca. bei 30 Hz.

Ist das so üblich? Ich bin etwas skeptisch, jedes Mal den Client anzulegen, zu verbinden und ihn danach inklusive disconnect-Abmeldung wegzuwerfen, um dann gleich wieder von vorne zu beginnen. Zumal einige Probleme auftreten, die auch mit Timing begründet werden könnten (bei .NET weiß man das ja nie genau außer dass es laaaangsam ist )
Meine Erfahrungen mit TCP sind marginal, daher die Frage.

Wie seht Ihr das? Ist das ständige Erstellen und Wegwerfen des Clients bei einer so kontinuierlichen Kommunikation sinnvoll? Zumal es eine direkte Leitung ist.

Danke, Messie

Nein, es ist üblich eine TCP/IP-Verbindung zu öffnen und dann permanent offen zu halten.
Entscheidend ist dann aber das Protokoll auf Anwendungsebene (OSI Level 7).

Angenommen dein Gerät ist wäre eine elektronische Wetterstation.
Dein C#-Client würde dann den Befehl 'GETTEMP'#13#10 schicken.
Das Gerät (=Server) antwortet mit '25.8C'#13#10.
Dann schickt dein Client 'GETHUM'#13#10 - Gerät anwortet mit '72%'#13#10.
Wichtig ist dabei das CR/LF, den es ermöglicht dem Server als auch dem Client das Ende eines Befehls zu erkennen.
Ohne diese Vereinbarung, das ein CR/LF das Ende eines Befehls oder einer Antwort ist,
ist es quasi unmöglich die einzelne Befehle und Antworten zu isolieren.
Es gibt natürlich auch andere Protokolle wie z.B. dass Befehle und Antworten eine feste Länge haben.
Aber ohne eine Vereinbarung zwischen Client und Server (diese Vereinbarung ist das Protokoll)
kann es keine vernünftige Kommunikation über TCP/IP geben.

Zusatzinfo:
wenn eine TCP/IP-Verbindung über Stunden oder Tage besteht, aber keine Daten geschickt werden,
dann besteht die Gefahr, dass die Verbindung durch das Betriebsystem oder einen dazwischenliegen Switch
getrennt wird.
Um das zu verhindern wird häufig in bestimmten Abständen ein NOP-Befehl geschickt um die Verbindung offen zuhalten.
Es gibt noch andere Möglichkeiten auf Socket-Ebene, aber die "NOP" Methode ist am sichersten.

Nun es gibt AFAIK durchaus Protokolle bei denen der Server/oder Client die Verbindung nach der Übertragung beenden. Ich hätte die Frage dahingehend verstanden ob es sinnvoll ist hierfür Wegwerfkomponenten zu generieren oder bei der nächsten Anfrage neu zu verbinden.
Was C# angeht bin ich leider völlig unbeleckt ...

Zitat von Bummi:

Nun es gibt AFAIK durchaus Protokolle bei denen der Server/oder Client die Verbindung nach der Übertragung beenden.

Kommt drauf an, wer die Verbindung schliesst. Falls der Client dies tut geht das in Ordnung.
Würde aber der Server (um beim Beispiel der Wetterstation zu bleiben) einfach die Verbindung nach Übertragung von Temperatur und Luftfeuchte beenden würde ich das als Fehlkonstruktion ansehen.
Beispiel FTP: hier schickt der Client dem Server einen QUIT-Befehl und der Server beendet die Verbindung; so ist das eine saubere Sache.
Normalerweise muss der Server die Verbindung aber offenhalten bis der der Client von sich aus trennt oder den Befehl zum Trennen gibt.
FTP-Server trennen aber z.B. nach einen best. Timeout die Verbindung; auch deshalb muss der Client immer wieder NOPs schicken damit das nicht passiert.

@sx2008:
Das Gerät ist der Server und damit durchaus mit der Wetterstation vergleichbar. Ich bin deshalb nicht sicher, ob nicht Zeit verschwendet wird für die jeweilige neue Connection. Denn im Gerät sind ja nicht haufenweise multitaskfähige Komponenten incl. einem geeigneten Betriebssystem vorhanden.
Mal eine Grundsatzfrage: wenn ich einen TCP- Client erzeuge und connecte, belegt er denn die Leitung und bremst andere Kommunikation aus? Kommuniziert er ständig oder ist nur die Kommunikation in so fern aufgebaut, dass der Server reagiert, falls eine Anfrage kommt?
@ Bummi: genau so habe ich es gemeint. Nur, dass bei mir derzeit nicht nur die connection unterbrochen wird, sondern der Client jedesmal erzeugt und anschließend neu erzeugt wird.

Grüße, Messie

Zitat von messie:

wenn ich einen TCP- Client erzeuge und connecte, belegt er denn die Leitung und bremst andere Kommunikation aus?

Eine offene TCP/IP Verbindung belegt wenig Resourcen (ein paar 100 Bytes im Betriebssystem).
Solange nichts gesendet wird ist auch das darunterliegende Ethernet frei.
Erst wenn die TCP/IP-Verbindungen in die Tausende gehen wie z.B. bei einem Webserver muss man sich darum Gedanken machen.

Zitat von sx2008:

Zitat von messie:

wenn ich einen TCP- Client erzeuge und connecte, belegt er denn die Leitung und bremst andere Kommunikation aus?

Eine offene TCP/IP Verbindung belegt wenig Resourcen (ein paar 100 Bytes im Betriebssystem).
Solange nichts gesendet wird ist auch das darunterliegende Ethernet frei.
Erst wenn die TCP/IP-Verbindungen in die Tausende gehen wie z.B. bei einem Webserver muss man sich darum Gedanken machen.

Danke, dann werde ich das mal umbauen.

Grüße, Messie

Zitat von messie:

Da wird für jede einzelne Kommunikation ein TCP-Client erzeugt, verbunden, kommuniziert und dann wieder getrennt und frei gegeben.

Das kann im Sinne eines "defensiven" Programmierstils sehr sinnvoll sein. Denn so wird sichergestellt, dass der TCP-Client mit einem definierten Anfangszustand vorliegt. Wenn der Client nacheinander von Prozedur A, B und C benutzt wird, und in Prozedur A eine der Voreinstellungen des Clients auf einen neuen Wert geändert wird (zum Beispiel das Default-Timeout herauf- oder herabgesetzt wird), wirkt sich diese Änderung auch auf Prozedur B und C aus, was zu Fehlfunktionen führen kann. Anders gesagt: nach Änderungen in Prozedur A muss man immer auch noch die korrekte Funktion von Prozedur B und C testen, da sie von A indirekt abhängig sind.

Zitat von mjustin:

Zitat von messie:

Da wird für jede einzelne Kommunikation ein TCP-Client erzeugt, verbunden, kommuniziert und dann wieder getrennt und frei gegeben.

Das kann im Sinne eines "defensiven" Programmierstils sehr sinnvoll sein. Denn so wird sichergestellt, dass der TCP-Client mit einem definierten Anfangszustand vorliegt. Wenn der Client nacheinander von Prozedur A, B und C benutzt wird, und in Prozedur A eine der Voreinstellungen des Clients auf einen neuen Wert geändert wird (zum Beispiel das Default-Timeout herauf- oder herabgesetzt wird), wirkt sich diese Änderung auch auf Prozedur B und C aus, was zu Fehlfunktionen führen kann. Anders gesagt: nach Änderungen in Prozedur A muss man immer auch noch die korrekte Funktion von Prozedur B und C testen, da sie von A indirekt abhängig sind.

Ja, zwischen zwei Windows-Systemen kann ich mir das vorstellen. Aber ich bin nicht sicher, dass meine Wetterstation sich genau wie ein Windows-PC verhält und nach dem Beenden der Verbindung den Speicher korrekt frei gibt, um ihn dann neu zu belegen.