Suchergebnisse

Hi, ich habe mal ein einfaches Beispiel - oder eher eine Grundlage - für einen stabilen TCP-MultiServer programmiert, jeder Client bekommt dabei einen eigenen Thread zugewiesen. Hoffentlich lehrreich und ausreichend kommentiert. Download: vb-paradise.de/index.php/Attac…dbe32725d4a8e23ee5015b9b1 Im folgenden der Code noch einmal direkt gepostet. Der MultiServer (Konsolenanwendung) VB.NET-Quellcode (69 Zeilen) Ein einfacher Beispiel-Client (Windows-Forms-Anwendung) - Eine Listbox für die Auflistun…

Theoretisch schon, wenn der Client auf die richtige IP (die IP des Servers) und den richtigen Port eingestellt ist. Das mit dem Nickname sollte man dann aber entweder beim Server rausnehmen oder beim anderen Client noch einbauen.

Der Client ist eine Windows-Forms-Anwendung... System.Windows.Forms.MessageBox und und System.Windows.Forms.Application sollten also zur Verfügung stehen.

Hi, die Konsolenanwendung habe ich einfach aus dem Grund gewählt, weil der Server ja grundsätzlich kein GUI braucht. Natürlich kannst du den Server auch in eine Windows-Forms-Anwendung packen. Das Grundproblem ist nicht die Endlosschleife (die sich übrigens nur nach jeder neuen Verbindung in der Ausführung wiederholt), sondern die Stelle, wo so lange mit der Ausführung gewartet wird, bis eine neue Verbindung eingeht. Resultat ist eine Form ohne Reaktion, die also "einfriert". Die Stelle mit dem …

Hallo Thomas, ja - so ungefähr. "Der Hammer" wäre es trotzdem nicht, denn der Server führt wirklich nur Code aus, wenn sich entweder ein Client verbindet, trennt, oder etwas sendet. Insofern ist der Server die meiste Zeit in einem "Schlaf-Zustand" und verbraucht damit praktisch keine Systemresourcen. Hier ein Beispiel: VB.NET-Quellcode (1 Zeile) VB.NET-Quellcode (23 Zeilen) VB.NET-Quellcode (3 Zeilen) Du siehst: Das einzige was ich zusätzlich geschrieben habe beträgt gerade mal 2 Zeilen und die …

Verwendet werden darf er natürlich. War vielleicht etwas unglücklich formuliert, gemeint war Kopieren nur im Bezug auf anderweitige Publizierung.

Nunja, sauber ist die Methode nicht, sie blockiert nur die Fehlermeldung, behandelt aber nicht den Fehler selbst. Hier bietet sich Delegaten an (siehe dazu u.a. MSDN). Wenn sich ein Client disconnected, wird das vom Server behandelt: VB.NET-Quellcode (4 Zeilen)

Jop, Verbindung schließen ist im Code gar nicht vorhanden. Um erst einmal grundsätzlich zu verstehen, um was es sich bei .NET-Delegaten handelt und wie sie funktionieren empfehle ich dir diesen Wikipedia-Artikel. In der MSDN gibt es anschließend schöne & lehrreiche Beispiele zur Verwendung. LG

Mono hast du schon probiert?

Probier erstmal die Loopback-IP (127.0.0.1).

- Der Server braucht einen freien Port - Der Client braucht keinen freien Port, Port muss aber mit Server-Port übereinstimmen - und IP mit Server-IP Ist das der Fall?

Hi, alle Verbindungen befinden sich ja in der Private list As New List(Of Connection). Im Prinzip kannst du den Server einfach um die folgende Prozedur erweitern: VB.NET-Quellcode (4 Zeilen) Der jeweilige Client lässt sich ja z.B. durch den Nick identifizieren. Da dieser allerdings nicht eindeutig ist, empfiehlt sich z.B. die Verwendung der IP. Dementsprechend wäre eine kleine Anpassung notwendig. LG

Autsch. Es gibt keinen TCP/IP-Server (bezogen auf Hardware)... hoste die Server-Anwendung einfach auf einem PC und verbinde mit diesem.

Zitat: „Hat jemand das "Spam" Problem schon in den Griff bekommen?“ Was meinst du? @ Zinsrechner: Was sollte das bei der Serverapplikation für einen Sinn machen? Aber geht natürlich...

Nein. Skype, Teamviewer, ICQ & Co laufen über einen (bzw. mehrere) globale Multiserver die die Daten nur von Client zu Client "durchleiten". Daher sind keine Freigaben von Ports auf der Seite der Clients nötig. Und um so einen Multiserver geht es in diesem Thread. Jede Seite bekommt zur Kommunikation einen Client, sodass die Verbindung so abläuft: vb-paradise.de/index.php/Attac…dbe32725d4a8e23ee5015b9b1 Du aber hast es jetzt so gemacht: vb-paradise.de/index.php/Attac…dbe32725d4a8e23ee5015b9b1 So…

DynDNS? Und mein Server hätte z.B. sowieso eine feste...

ListenToConnection läuft ja in einem eigenen Thread -> ist doch logisch... die Verwendung eines Delegaten sollte das Problem lösen.

Wie gesagt gehst du falsch vor. Du kannst die Form nicht aus einem anderen Thread aufrufen. Das geht NUR aus dem Formthread. Um solche Vorgänge doch machen zu können, gibt es Delegate. Guckst du hier...

Wenn du nicht in der Lage bist einen Delegaten zu verwenden dann such doch im Internet, es gibt genug Beispiele... und ein Beispiel hast du von mir bereits bekommen. Die Form schließt sich weil du eben keinen Delegaten verwendest. Muss am Ende ungefähr so aussehen: VB.NET-Quellcode (1 Zeile) VB.NET-Quellcode (3 Zeilen) Aufruf VB.NET-Quellcode (1 Zeile)

Der Server läuft bereits so wie er ist problemlos auf Mac und Linux (bei mir auch aktiv als Lizenzserver auf Debian Lenny am laufen), genauso wie der Client. Die Online-Liste kannst du doch ganz einfach selbst realisieren, du musst nur bei Veränderungen (neuer Client oder Client weg) an alle Clients die neuen Daten senden.

VB.NET-Quellcode (9 Zeilen) Hast du wohl nicht in deiner Klasse.

Irgendeinen, solange frei und unbenutzt...

Her mit dem Code (senden & empfangen).

Zitat: „Her mit dem Code (senden & empfangen).“ Code zum kodieren & senden sowie empfangen & dekodieren, sonst wird das nichts werden...

InsertLineBreaks ist wohl das Problem... Probier's mit FormattingOption None (Standard).

Direkt binär, dazu Binaryreader & writer aufsetzen. Vllt. löst du das ganze auch direkt mit binärer Serialisierung des Image-Objektes.

Leute, die Übertragung ist so schnell wie die Anbindung hergibt... nur etwas Zeit und Traffic sparen könnte man, indem man gänzlich auf Base64-kodierung verzichtet, die eigentlich nicht nötig ist und über einen Binaryreader/writer blockweise direkt binär sendet.

Den Server lässt du so, wie er ist. Beim Client trägst du deine externe IP ein (aber denk daran, dass diese sich öfters ändert). @ Speziflasche: Da es sich um ein Gerüst handelt, wird die Verbindung in diesem Beispiel nicht geschlossen. Einfach Streams und Client schließen.

Einfach erst Thread (sauber) beenden, dann Stream und dann Client schließen. LG

Unsauber aber funktioniert: Thread aborten und ThreadAbortException abfangen (und danach ggf. Exit Sub). Sauberer: Modulweit deklarierte Boolean-Variable (ggf. Abfrage in SyncLock), falls False -> Sub verlassen, andernfalls fortsetzen. LG