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 - soweit ich weiß - die einzige Möglichkeit, mit der ein Server hunderte von TCP-Verbindungen halten kann, ohne dementsprechend auch hunderte von Threads alloziieren zu müssen.

Die Struktur der Anwendung ist bisserl listig, denn ich habe sowohl Server als auch Client-Anwendung im selben Projekt implementiert - und sie benutzen sogar dasselbe Form. Man startet die App, und klickst "be Server", dann hat man einen Server gestartet, und wenn man "be Client" klickst, dann isse halt ein Client.

Diese hohe Wiederverwendbarkeit beruht letztendlich darauf, dass das TCP-Protokoll symmetrisch ist - zwischen den Endpunkten einer Verbindung Server - Client gibt es keinerlei Unterschied - nur beim Server werden viele Endpunkte verwaltet - beim Client nur einer.
Sowohl beim Server als auch beim Client werkeln ein TcpClient-Objekte, und da habe ich gleich einen Wrapper drum geschrieben, der einen String senden kann, und auch empfangen - egal, ob er sich in der Server-Anwendung befindet, oder in der Client-Anwendung.
Beim Empfang löst dieser Client-Wrapper ein Event aus, und es obliegt der Anwendung, wie sie damit umgeht: Eine Client-Anwendung zeigt den empfangenen String halt an, eine Server-Anwendung zeigt ihn an, und ausserdem verschickt sie den String weiter an alle connecteten Clients.

Hiermal der Client:Die Events sind nicht direkt sichtbar, denn sie sind in die Basis-Klasse ausgelagert, und werden in obigem Code über die OnChatMessage/OnStatusMessage-Methoden ausgelöst. Und zwar gleich im Gui-Thread, um den berühmten unzulässigen threadübergreifenden Zugriffen vorzubeugen.

Das mit der Basisklasse ist effizient, denn das Server-Objekt muß dieselben Events auslösen wie der ClientWrapper, und indem beide von TCPBase erben sind es dieselben Events.
Weiters muss der Server auch die nach aussen hin identische Methode Send(Msg As String) bereitstellen, das habe ich als MustOverride implementiert: Sowohl das ClientWrapper-Objekt als auch das Server-Objekt haben die Methode Send(), nur intern unterschiedlich ausprogrammiert (der Server sendet an alle).

Hier die TcpBase:

Das Server-Objekt enthält und verwaltet neben seinem TcpListener auch die Liste der TcpClients, die mit ihm verbunden sind. Von denen empfängt er auch die Events und reagiert entsprechend - zum einen selbst ein Event auslösen, zum anderen die Messages weiterversenden.

Dazu gibts noch das Form sowie 2 Dateien mit Helferlein-Code, auf die ich hier nicht eingehe.

Edit: Auf besonderen Wunsch uppe ich auch eine Version, bei der Server und Client nicht von derselben Basisklasse erben.
Edit2: Beachtet auch den Chat auf WCF-Basis, den man von MS direkt erhält: Mini-Tipp: WCF - Chat (Windows Communication Foundation)
WCF ist viel eleganter, insbesondere was die Implementierung eines Kommunikations-Protokolls angeht

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 KonfigurationsSite unter "PortForwarding" die lokale IP des Zielrechners eingeben (bei mir: 192.168.1.2), denn auf die wird geforwardet. Und den Port, den man benutzen möchte (irgend eine zahl zw. 5001 und 9999)
Ja, wenn man dann so ein feines Port-Forwarding eingerichtet hat, kann man den Versuchschat als Server starten, welcher auf die lokale IP listened (bekommt die Daten auf die lokale IP geforwardet).
Und dem Client am anderen Ende der Welt muß man die globale IP mitteilen, die man etwa auf checkip.dyndns.org angezeigt bekommt. Und natürlich den geöffneten Port, den musser auch wissen, der Client.
Dann kann sich der Client mit dem Server verbinden, und die 2 können chatten.

Router-IP finden (falls die KonfigurationsSite "http:\\192.168.1.1" nicht stimmt)
Also ein Kumpel wusstedas (das vorherige auch):
Falls bei euch die IP-Adresse 192.168.1.1 des Routers nicht stimmt, kann diese wie folgt herausgefunden werden:
1.) Als erstes die Komandozeilen-Konsole öffnen (Start->Ausführen->"cmd" eingeben und mit Enter bestätigen).
2.) In die Konsole den Befehl "ipconfig" eingeben.
Dann muss man in dem vielen Text, derdakommt, was suchen, was mit "StandardGateWay" bezeichnet wird - das ist die IP-Addresse des Routers.

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:

Die Basisklasse kann natürlich nicht mehr TcpBase heißen, und im Grunde müsste sie auch für den VersuchsChat auf "CommunicationBase" umbenannt werden, denn es ist dieselbe Klasse (zeigt sich hier als noch wiederverwendbarer, als ich selbst gedacht hatte).

Jo, und der TcpClient im Client hat sich erübrigt, und im Server gibts jetzt nurnoch den PipeNamen, anstatt eines TcpListeners.
Denn bei NamedPipes gibts keinen Listener, sondern jeder NamedPipeServerStream listens selber, und wird zum Verbindungs-Objekt, wohingegen bei Tcp der TcpListener beim Verbinden einen neuen TcpClient generiert als Verbindungs-Objekt.

Vlt. noch interessant der verwendete Konstruktor des NamedPipeServerStreams:Keine Fragen, oder? Direction.InOut, Byte-Übertragung, asynchron.
Höchstens die "20" erklärt sich nicht selbst, die gibt an, dass maximal 20 PipeStreams auf diesem Namen registriert werden dürfen.

Hier der Konstruktor des Gegenstücks:Hier ist "." erwähnenswert - damit ist der lokale Computer als Server-Computer qualifiziert.

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ü Debuggen-Fenster-Threads): Es sind weniger als 10.

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:
(update in post#1)