TCP Chat jeder Client hat ein Server?

  • VB.NET

Es gibt 16 Antworten in diesem Thema. Der letzte Beitrag () ist von Kangaroo.

    TCP Chat jeder Client hat ein Server?

    Hallo,

    Ich möchte für unsere Schule einen Chat machen, ich habe dabei an TCP schon gedacht nun hab ich aber das proplem das das ineternet manchmal gespeert is(Lan geht aber alles).

    Nun zu meiner Frage:
    Meine frage wäres ob es möglich ist das nicht nur eine Person den Server hat sondern vil. in jedem Client der Server unsichtbar intigriert ist so das nicht auf einen externen Server zugegriffen werden muss oder es immer von bestimmten Personen abhängt ob der Chat geht!



    DANKE!!

    MFG
    chrissinator
    Für LAN wäre das sicher machbar.

    Ich könnte es mir so vorstellen:

    Jeder Client kann auch der Server sein. D.h., es ist überall ein Listener implementiert.
    Beim Programmstart wird im lokalen Netz nach einem Server gesucht.
    Die Suche könnte man im einfachsten Fall so gestalten das
    1. Das komplette Subnetz angepingt wird.
    2. Die durch 1. gefundenen PC's sind nun ja potenzielle Server, es wird daher versucht zu verbinden, und abzufragen, ob Sie dein "Chatserver" sind.

    Kann so kein Chatserver gefunden werden, wird dieser Client zum Server.
    Die nächsten Clients im Subnet suchen dann wieder den Server, und werden den ersten Client finden und connecten.

    Somit wird automatisch immer der 1. Client im Subnetz zum Server.
    Der Serverport, den du im Programm festlegst muss natürlich Verbindungen zulassen (also bei jedem PC)
    Das ist meine Signatur und sie wird wunderbar sein!
    Ich würde es anders machen, ähnlich wie es schon seit Jahren gang und gebe in Windows Spielen wie Hearts ist.

    1. Man startet das Programm und wählt aus ob man Server oder Client ist.
    2. Ist man Client trägt man die IP/DNS von dem Rechner ein der Server is
    3. Ist man selbst Server wird die IP angezeigt die man den anderen mitteilen kann, diese eben sie bei sich im Programm ein und können Conncten

    Der Vorteil liegt für mich darin das damit beliebig viele Chatnetze innerhalb eines LANs aufgebaut werden können und Joinen können nur welche die auch deren IPs haben (natürlich kann man durch IP durchpingen und Testen und so die Server ausfindig machen).
    @Mono sieht irgendwie aus wie das Protokoll zum Aushandeln eines zentalen WinS Servers im Netzwerk. Die Nachteile sehe ich dort in der Dynamik in dem Netzwerk , wo permanent Clients hinzukommen bzw wieder verschwinden. Es wird halt immer aktuell genau 1 zentralen Server geben müssen. Bei Ausfall des gerade aktuellen Servers muss dann wieder umständlich ein neuer zentraler Server ausgehandelt werden müssen, genauso würde ich auch nicht gerade einen Ping auf alle Netzwerkadressen durchführen.

    @Dodo Die IP-Adresse ist vermutlich nicht das beste Mittel, schliesslich wäre es sinnvoll irgendwo sinnvolle Namen von den Teilnehmern zu sehen , die einen entsprechenden Client besitzen. Auch ein Hostname ist in einem Klassen Chatroom vielleicht nicht unbedingt das richtige Kriterium.

    Eine generelle Lösung vorzuschlagen ist schwieirig , da wir nicht wissen welche Art Chats der TE implementieren will (Chatrooms, A---> All, TN -> TN), auf jeden Fall würde ich mir mal das sessionlose UDP Protokoll anschauen. Hier könnte zum Beispiel per UDP Broadcast die Bekanntgabe / Abmeldung von Teilnehmern erfolgen, wenn man es besonders gründlich machen möchte sogar per regelmässigem Heartbeat. Vorteil wäre hier der Verzicht auf einen zentralen Server.

    Ob man dann für die Chats auf das TCP Protokoll wechselt sei jedem selber überlassen, obwohl ich in einem kleinen Netzwerk ohne hohe Sicherheitsanforderungen hier auch UDP für die einfachste Lösung halte.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Kangaroo“ ()

    Hey Kangaroo,

    ja, genau an das Prinzip eines WINS hatte ich gedacht ^^
    Es stimmt natürlich, das bei Ausfall des aktuellen Servers, ein neuer ausgehandelt werden muss. Dies ist sicher der schwierigste Teil.
    Von einer allzuhohen Fluktuation der Clients geh ich nicht wirklich aus, wenns halt ein Computerkabinet in der Schule ist.

    Wieso würdest du keinen Ping ausführen um vorab zu prüfen, welche Clients überhaupt im Netz sind ?
    Das ist meine Signatur und sie wird wunderbar sein!

    Mono schrieb:

    Wieso würdest du keinen Ping ausführen um vorab zu prüfen, welche Clients überhaupt im Netz sind ?

    Damit stellst Du zwar fest welche Computer im Netzwerk sind , aber nicht ob diese denn am Chat teilnehmen wollen, sprich den speziellen Client am Laufen haben. Ausserdem ist ein UDP Broadcast "Ich bin hier" sehr einfach mit 1 Zeile zu lösen und ich brauche keinen zentralen Server, weil jeder Client die aktuellen Teilnehmer in einer eigenen Liste führen kann. Genauso kann man dann das Abmelden / Pause usw. implementieren. Einen Heartbeat ( alle xx Sekunden ) habe ich nur erwähnt, um Leichen beim harten Ausschalten/Reboot des Rechners ermitteln zu können.

    Aber ich bin auf Alternativ-Vorschläge gespannt.

    Kangaroo schrieb:

    @Dodo Die IP-Adresse ist vermutlich nicht das beste Mittel, schliesslich wäre es sinnvoll irgendwo sinnvolle Namen von den Teilnehmern zu sehen , die einen entsprechenden Client besitzen. Auch ein Hostname ist in einem Klassen Chatroom vielleicht nicht unbedingt das richtige Kriterium.

    Nun dann hast du mich falsch verstanden =)
    Die Clients oder auch der User der sich als Server macht gibt natürlich seinen Nicknamen ein der im Chat dann dargestellt wird, die IP lediglich zum Connecten.
    So ists bei Hearts z.b. auch, zumindest früher als ich das manchma gespielt habe, dort hat einer Spiel gestartet und der mit spielen wollte musste die IP des Pcs eingeben der das Spiel gestartet hatte. Für einen Namen den man eingeben kann benötigt man ja zunächst ein DNS.
    Für so ein kleinen LAN Chat reicht das völlig aus. Alternativ könnte man statt der IP im Oktetten Format übers Decimal Format nachdenken als eine art Server ID die man eingeben muss zum Connecten.
    Man könnte es ja implementieren nach Server suchen zu können, aber es sollte dennoch die Möglichkeit bestehen, einen neuen, eigenen server zu starten und nicht das es nur einen gibt, wer das programm zuerst startet.

    Vielleicht beim start einfach ne Listbox

    Verfügbare Server:
    192.168.x.12 (User: 5)
    192.168.x.24 (User: 1)
    192.168.x.72 (User: 32)

    und darunter eben "Neuen Server starten" oder sowas.
    Natürlich, beim Scannen des Netzwerkes übermitteln die Server die gefunden werden einfach ihre Namen und die IP wird versteckt mit gespeichert. Wenn jemand ein Server erstellt könnte er z.B. einen Namen angeben und eine Beschreibung, wird dieser Server dann angepingt gibt er diese Informationen heraus und du speicherst sie einfach ab. am einfachsten in einer eigenen Klasse die dann dem ListBox Items hinzufügst.
    Wenn du den Chat hinbekommst, bekommste das auch hin, aber da kann dir hier nur bedingt geholfen werden, das meiste muss von dir kommen das dich eben erstmal damit auseinander setzt und verstehst was du da tun willst.
    Was dir helfen wird ist das TCP Tutorial in Sourcecode Austausch.

    Dodo schrieb:

    Nun dann hast du mich falsch verstanden =)

    Ich denke ich habe Dich genau verstanden Dodo, die von Dir vorgeschlagene Lösung ist ja auch nicht gerade schwierig zu verstehen.

    Nur eine ganz triviale Frage: wozu brauchst man eigentlich deiner Meinung nach für einen einfachen Netzwerk-Chat überhaupt Server ?
    Weil ich TCP besser finde als UDP =) zum einen die Reihenfolge und dann noch die Fehlerresistenz ist bei TCP ja bekanntlich besser.

    Und wegen des nicht verstanden weil du von Teilnehmernamen gesprochen hast, das diese besser wären, aber das es Teilnehmernamen geben soll habe ich ja gar nicht ausgeschlossen, die IP dient lediglich zum Connecten und jeder Server ist dann quasie eine art Chatroom.
    Ich hatte eigentlich nicht vorgehabt den UDP Ansatz vehement zu verteidigen, er war nur als zusätzliche Alternative gedacht. Jeder kann / soll dann für sich selber entscheiden.

    Kangaroo schrieb:

    Nur eine ganz triviale Frage: wozu brauchst man eigentlich deiner Meinung nach für einen einfachen Netzwerk-Chat überhaupt Server ?

    Das war die Frage und bisher habe ich keine Antwort darauf erhalten. Ein Chat ist eben kein Hearts Game, welches eine Art Gameserver benötigt. Ein Chat-Room sollte bitte so lange existieren bis der letzte Teilnehmer den Raum verlassen hat und nicht wenn der aktuelle Server sich verabschiedet.

    Dodo schrieb:

    Weil ich TCP besser finde als UDP =)

    UDP ist nicht generell schlechter / besser als TCP, sondern nur für bestimmte Zwecke geeigneter oder auch nicht.

    Dodo schrieb:

    zum einen die Reihenfolge

    Welche Reihenfolge meinst Du bei einem verbindungslosem Protokoll ?

    Dodo schrieb:

    und dann noch die Fehlerresistenz ist bei TCP ja bekanntlich besser.

    Zweifellos, nur inwieweit ist das bei einem Chat ein KO- Kriterium ? Zusätzlich kann man die Robustheit durch mehrfaches Senden der Nachricht bzw. einfache Quittungsmechanismen erheblich verbessern.

    Ob nun UDP oder TCP, implementieren kann man einen simplen Chat sicher über beide Protokolle. Ich hatte nur UDP als Alternative ins Spiel gebracht, weil es meiner persönlichen Meinung hier einfacher ist. Bekanntgabe der Teilnehmer erfolgt durch MultiCast, Teilnahme an Chat-Rooms über die von der UDPClient Klasse zur Verfügung gestellten Methoden JoinMultiCastGroup / DropMultiCastGroup. Das wars mehr oder weniger.