|
| |
VB.NET - Ein- und Umsteiger| tcpClient Stream hängt?!? | |  | | Autor: Daddaaff | | Datum: 17.07.11 23:38 |
| Hallo, nach circa 35 Stunden ohne Schlaf habe ich nun einen Fehler ausfindig gemacht, weis jedoch nicht wie ich ihn beheben soll. Der Fehler entsteht, wenn ich Nachrichten weiterleiten will.
Sub Forward(ByVal MSG As String)
SyncLock PClients
For Each c As Connection In PClients
Try
c.streamw.WriteLine(MSG)
c.streamw.Flush()
Catch ex As Exception
TXT(ex.ToString)
End Try
Next
End SyncLock
End SubBei "c.streamw.WriteLine(MSG)" oder "c.streamw.Flush()" bleibt mein Programm stehen. Und das bei mehreren Threads beim gleichen Client. Ich nehme an das sicher jener Client aufgehängt hat und durch den ganzen TCP-Kontrollmechanismus bleibt hier mein Programm stehen. Gibt es eine andere Möglichkeit als auf UDP zu wechseln? Kann ich Forward() in einem eigenen Thread starten wenn dieser ca. 10 - 15 mal pro Sekunde gestartet wird - oder vielleicht einen Threadpool? Oder wäre das ständige erstellen dieser Threads mit zu hohen Performance Einbussen verbunden? | |
| Re: tcpClient Stream hängt?!? | | | | Autor: Preisser | | Datum: 18.07.11 00:12 |
| Hallo,
es kann natürlich passieren, dass die Write-Methoden blockieren, wenn keine Daten mehr gesendet werden können, da der Client diese nicht abholt, oder die Netzwerkverbindung zu langsam ist usw.
Eine Möglichkeit wäre, z.B., für jeden Client einen Thread erstellen, der nur das Senden erledigt (und evtl. beim Überschreiten einer bestimmten Menge an Daten, die noch nicht gesendet werden konnten, den Client trennt). Man könnte beispielsweise eine BlockingCollection<T> über eine ConcurrentQueue<t> verwenden, der man immer Sendeaufträge gibt, und der Sendethread holt diese dann ab und arbeitet sie sequentiell ab (bin mir aber nicht sicher, ob es in .Net auch andere/bessere Methoden dafür gibt).
Bei der Verwendung eines Threadpools bin ich mir nicht so sicher, da man dafür sicherstellen müsste, dass die Aufrufe der Write-Methoden threadsicher sind, da es ja passieren kann, dass 2 Threads des Threadpools gleichzeitig Write() aufrufen wollen. Vermutlich könnte es dann aber auch zu Race Conditions kommen und die Schreibreihenfolge wäre nicht mehr sichergestellt.
Beitrag wurde zuletzt am 18.07.11 um 00:33:23 editiert. | |
| Re: tcpClient Stream hängt?!? | | | | Autor: Daddaaff | | Datum: 19.07.11 12:26 |
| | Ich habe entweder ein weiteres Problem gefunden oder das aktuelle genauer spezifiziert. Mir ist aufgefallen das wenn ein Client hängt (schlechte Netzwerkverbindung, Prozess hängt, etc ...) und dann wieder alles in Ordnung ist, wird der Client plötzlich mit teilweise 10 Minuten alten Nachrichten geflodded. Und da der Client dies wiederum an alle anderen weiterschickt, denn nun kommt es dem Client so vor als wären es neue Nachrichten, wird jeder einzelne Chat-Client plötzlich mit Nachrichten von vor 10 Minuten zugespammt. Wie könnt ich diese problem lösen? Buffer im Streamreader der den tcpClient schließt wenn zu viele Nachrichten im Puffer sind. Zeitangabe bei den Nachrichten und Nachrichten die älter als z.B. 30 Sekunden sind verwerfen? | |
| Re: tcpClient Stream hängt?!? | | | | Autor: Preisser | | Datum: 19.07.11 13:25 |
| Hallo,
das verstehe ich jetzt nicht ganz. Es kann schon sein, dass vorübergehend die Netzwerkverbindung "steht" und hinterher alle vorher gesendeten Daten mit Verspätung ankommen. Aber warum willst du dann ältere Nachrichten verwerfen, bzw. warum ist es wichtig, ob eine Nachricht alt oder neu ist? Bei Netzwerkverbindungen kann man ja nicht so genau auf die Zeit gehen, da es ja, wie bereits festgestellt, Verzögerungen geben kann. Wobei ich eine 10-minutige Verzögerung noch nie gesehen habe, normalerweise gibt es Unterbrechungen von höchstens einigen Sekunden (ok, wenn die Netzwerk-/Internetverbindung komplett ausgelastet ist, kann es schon längere Verzögerungen geben).
Wenn es dir wichtig ist, dass verbunden Clients eine schnelle Reaktionszeit haben, könntest du ja vom Server aus in bestimmten Intervallen jeden Client "anpingen" (also bestimmte Daten schicken, die dieser beantworten muss) und wenn er innerhalb einer bestimmten Zeit nicht reagiert, ihn trennen.
Oder, wie im anderen Beitrag schon gesagt, wenn der Sendethread zwar neue Sendeaufträge bekommt, diese aber nicht abarbeiten kann (da die Verbindung grade langsam ist/steht), den Client ebenfalls trennen.
Beitrag wurde zuletzt am 19.07.11 um 13:27:06 editiert. | |
| Re: tcpClient Stream hängt?!? | | | | Autor: Daddaaff | | Datum: 19.07.11 13:41 |
| | Scheinbar soll bei TCP die verzögerung bis zu 15 Minuten betragen können. Da ich nicht gesendete Nachrichten sowieso schon in einer Generic List hatte habe ich nun gerade eine Überprüfung eingefügt, die den Aktuellen tcpClient beendet wenn in der Liste mehr als 20 Nachrichten stehen. Sieht bisher ganz gut aus. | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
vb@rchiv CD Vol.6 vb@rchiv  Vol.6
Geballtes Wissen aus mehr als 8 Jahren vb@rchiv!
Online-Update-Funktion
Entwickler-Vollversionen
u.v.m.Jetzt zugreifen Tipp des Monats sevZIP40 Pro DLL 
Zippen und Unzippen wie die Profis!
Mit nur wenigen Zeilen Code statten Sie Ihre Anwendungen ab sofort mit schnellen Zip- und Unzip-Funktionen aus. Hierbei lassen sich entweder einzelnen Dateien oder auch gesamte Ordner zippen bzw. entpacken. Weitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.