Suchergebnisse

Vorbemerkung: Inzwischen habe ich diesen Ansatz wesentlich weiterentwickelt, inklusive einer Art Standard für ein BefehlsProtokoll, sowie auch Datei-Übertragungen: siehe TcpKommunikation + Networkstream Hier täte ich mal meinen Versuchschat vorstellen. Das Verständnis des Codes setzt gute Kenntnisse in OOP vorraus, nämlich die Vererbungslehre. Weiters kommt Threading nach dem asynchronen Entwurfsmusters in Anschlag. Die Verwendung der asynchronen Read-Methode insbesondere des TcpClients ist - so…

Soweit schomaschön, damit hat man also eine Anwendung, die sich als Server oder Client betätigen kann, sogar beides gleichzeitig (wenn man mehrere Forms öffnet), und dann können diese Forms untereinander chatten - via TCP. Beim ins Internet chatten kann sich der Router einem in den Weg stellen, weil der verwaltet ja eine IP, die vom INet ihm zugeteilt wurde. Also muß man beim Router über die KonfigurationsSite "http:\\192.168.1.1" ein PortForwarding konfigurieren. Dazu muß man auf genannter Konf…

Der Thread [Allgemein] Daten an andere .exe übergeben hat mich drauf gebracht, dass dieselbe Programm-Struktur ebenso verwendbar sein müsste, wenn man die Kommunikation per NamedPipes abwickelt statt per Tcp. NamedPipes sind im Netzwerk verfügbar, und ist natürlich wesentlich schneller und resourcenschonender als Tcp. Intern ticken die NamedPipes schon sehr anders als TcpListener und TcpClient, aber an der Architektur von Server und Client hat sich tatsächlich nix geändert, vergleiche: vb-paradi…

Was? Hunderte von Threads alloziieren? Nein - machtes nicht. Intern wird da glaub iwas mittm ThreadPool gehext. Keine Ahnung wies funktioniert, aber es wird bei Benutzung der asynchronen Methoden nicht für jede Tcp-Verbindung ein eigener Thread alloziiert. Sondern nur bei Aktivität wird ein Thread aus dem Pool entnommen, und anschließend wieder zurückgegeben. Man kanns übrigens auch überprüfen, indem man zb 10 Clients an einen Server hängt, und dann die Threads debugt (Codestop, und dann Menü De…

ich verwende in Clientklasse nun BinraryReader/-Writer zum Lesen/Schreiben in den NetworkStream. Nicht nur wird der Code dadurch noch bisserl übersichtlicher, v.a. eröffnet das die Möglichkeit, auch andere Daten als nur Strings zu übertragen. Statt der asynchronen TcpClient.BeginRead() - Methode wird nun von der BinaryReader.Read()-Methode ein Func(Of String)-Delegat gebildet, der per .BeginInvoke() ebensogut asynchron aufgerufen werden kann:VB.NET-Quellcode (35 Zeilen) (update in post#1)

Tja, leider habich technische Probleme mitte Forum-Software und kann ich grad keine Uploads machen, also schick ichs dir per Mail Ich denke aber, dir sind die Vorzüge von Vererbung noch nicht ganz klar. Weil sowohl Server als auch Client müssen disposable sein, ein Disposed-Event werfen und müssen Statusmeldungen ausgeben können - das ist jetzt redundant gecodet. Ja, und dieses lustige Form, was sowohl Server als auch Client sein konnte, hab ich natürlich auch aufteilen müssen - das ist jetzt au…

mit der BinaryReader.Read-Methode.

du musst dir die .Read - Methode schon auch mal angucken im ObjectBrowser. Sonst kannst du sie natürlich nicht richtig verwenden.

nö, hatternich, der BinaryWriter/Reader. Man könnte aber eine Extension schreiben, die diese Funktionalität dranpatcht. Beim Schreiben eines Arrays würde die Extension erstmal die Länge desselben reinschreiben. Und beim Lesen könnte das dann ausgelesen werden, sodass das Array richtig dimensioniert wern kann.

Es empfiehlt sich wahrscheinlich, die Programme modular aufzubauen, also ein Helpers-Projekt coden, was in beiden Projekten eingebunden ist. Dort hinein gehören Basisklassen von Klassen, die sowohl im Server als auch im Client existieren. Aber dort gehören bestimmt auch die Protokoll-Definitionen hinein. Ich zB. habe sehr umfangreiche HelpersProjekte, also eigentlich Bibliotheken, die ich in alles einbinde, was zB mit Winforms arbeitet, und eine annere, für überhaupt alles annere. Ohne meine Hel…

ich versteh die Frage nicht: Wenn das Server-Objekt, oder das Client-Objekt das StatusMessage-Event raist, dann isses eine Status-Meldung. guck doch einfach in den Code, wo und wann das stattfindet.

Hee! - grad dir hab ich doch eine Version ohne Basisklassen geschickt. Aber jetzt hab ich die auch in post#1 eingestellt.

Zitat von Daniel Baumert: „Und zwar füge ich die Clients einem ListView Item hinzu.“Kann nicht sein. Einem Listview kannst du nur Strings zufügen. Ich weiß nicht, welchen Datentyp deine Clients haben aber ich gehe mal davon aus: nicht String. (Meinst du übrigens ListView oder ListViewItem?)

im Server-Objekt gibts eine Liste von Client-Objekten. Deren IndividRemove-Events haste wohl zu behandeln vergessen.

Zitat von Daniel Baumert: „Ich habs mit einem Client und einem Server getestet“Das ändert nix daran, dass im Server-Objekt eine Liste von Client-Objekten ist. Zeig mal den Code, wie du deren RemoveIndiv-Event behandelst. Falls du nur mit einem Client testest ist in der Liste eben nur ein Client-Objekt drin.

Befindet sich das im Code der Server-Klasse? wenn nicht, meine ichs wohl nicht.

Du kannst in der Client-Klasse, und auch in der Tcp-Klasse und sonstwo - kannst du dich auf den Kopf stellen und mitte Zehen wackeln. Wenn du im Server die Client-Events nicht behandelst, dann werden die Client-Events der Clients im Server halt nicht behandelt Zitat von Daniel Baumert: „Der Server stellt doch grundlegend auch einen Client dar, nur dass er halt nebenbei noch andere Clients annehmen kann und somit Server ist.“Der Server ist kein Client. Der Server ist im Wesentlichen ein TcpListen…

also es ist ganz ausgeschlosssen, dass du die Server-Klasse mal in den Blick nimmst? Ansonsten - also falls doch irgendwann einmal - poste doch den Code derselben.

betrachte mal #13 - #15 - da werden offenbar die Events des grad frisch neu erstellten Clients abonniert, odr? Deines ist aber nicht dabei.

Das ist jetzt aber ein Themawechsel. Bisher hattest du ein Problem, dein Event zu empfangen, nun, es zu senden? Zitat von Daniel Baumert: „Wie bereits erwähnt möchte ich das mein Event ausgelöst wird, wenn der Client disposed wird.“(wo hastn das erwähnt?) Also dann löse es doch im Dispose-Override des Client aus. Zitat von Daniel Baumert: „Sag mir bitte wie das gehen soll.“mittm RaiseEvent - Schlüsselwort.

ich verstehe nicht, was du meinst was ich meine. ah - jetzt sehe ich: Ich schreibZitat von ErfinderDesRades: „Also dann löse es doch im Dispose-Override des Client aus.“und promt fügste du es im Server ein. Weil ich ja sag "Client" Aber vlt. erklärst du, was dieses IndivRe-Event ühaupt soll. Höchst-Wahrscheinlich gehört es nämlich nicht in die TcpBase-Klasse, und evtl. ists sogar komplett üflüssig.

weil sie eine Basisklasse ist. Als Basisklasse macht sie allen Erben denselben wiederverwendbaren Code verfügbar. Ein Interface hingegen muss jeweils komplett neu implementiert werden.

Das hatten wir doch schonmal - das war doch das Problem, dass ein ZippStream den letzten Block nicht verschickt, oder? Und da hatteste doch auch eine Lösung für ? Zitat von Daniel Baumert: „Wollte nur nochmal Fragen wegen des Problems aus Post 66..“Wollte nur nochmal erinnern an die Frage an dich aus post#65