Freundeslisten bei Instant messaging, wer ist online?
-
Warum sollte die Masse nicht bewältigt werden können? Die Server(Plural!) sind dementsprechend darauf ausgelegt.
Mit den IP Adressen der User kannst du nicht viel machen als Client. Es sei denn, du hast es so vor wie ich es verstehe, dass der Server lediglich dazu dient dem Clienten die IP Adresse der User zuschicken, damit diese eine P2P Verbindung aufbauen können? Aber da kommst du mit der IP nicht weit,da benötigst du dann dynamische DNS.
Und was macht der Server, wenn die Person offline ist?
Und was ist wenn der Chat 3 Stunden nicht genutzt wird, vorher aber alle Verbindungen aktiv waren. Jetzt denkt der Server, alle seien Verbunden?
Erklär mal ein bisschen genauer was du möchtest
-
zuckerlie schrieb:
Warum sollte die Masse nicht bewältigt werden können? Die Server(Plural!) sind dementsprechend darauf ausgelegt.
Das ist imo Resourcenverschwendung.
zuckerlie schrieb:
Mit den IP Adressen der User kannst du nicht viel machen als Client. Es sei denn, du hast es so vor wie ich es verstehe, dass der Server lediglich dazu dient dem Clienten die IP Adresse der User zuschicken, damit diese eine P2P Verbindung aufbauen können? Aber da kommst du mit der IP nicht weit,da benötigst du dann dynamische DNS.
Warum sollte man dynDNS benötigen? Was redest Du da?
Ok. Nochmal: Ein typisches Im-Netzwerk bei dem jeder Benutzer Freunde hat, deren Onlinestatus nach Starten des Clients angezeigt wird und er dann entsprechend mit ihnen chatten kann.
Hier ein Szenario:
Ein User startet das Client-Programm und nimmt dazu Verbindung mit einem Server auf. Der Server speichert erstens die IP-Adresse des Users und sendet ihm zweitens die IP-Adressen seiner Freunde. Daraufhin kann der Client die Verbindung zum Server trennen, Verbindungen mit seinen Freunden aufbauen und chatten.
Sobals ein User das Client-Programm beendet nimmt dieses wieder Verbindung zum Server auf, die IP-Adresse wird ausgetragen (Status ist damit Offline) und die Freunde werden darüber benachrichtigt.Die Frage bezieht sich auf den Sonderfall, dass Verbindungen nicht sauber getrennt werden und der Server weiterhin die IP des Users vorhält und verteilt, obwohl dieser nicht mehr online ist.
Eine sehr einfache Lösung wäre es, wenn der Server alle (sagen wir) 15 min. eine Verbindung zu allen Usern aufbaut und prüft ob sie tatsächlich noch den Status "online" im Netzwerk haben. Ich habe mich nur gefragt, ob es elegantere Möglichkeiten gibt als ein solches Polling und wie man einen Fehlerhaften Status sowohl möglichst schnell entdeckt als auch mit möglichst wenig Traffic entdeckt. Stets die Verbindung offen zu halten zwischen Usern und Servern sieht mir wie gesagt nach Resourcenverschwendung auf, die ganze Kommunikation soll nämlich nicht über den Server laufen sondern durch Direktverbindungen der User. Also tatsächlich eher wie ein P2P-Netzwerk und dem Server fällt zentral die Aufgabe zu, IP-Listen der eingeloggten Freunde zu verteilen.
-
So ein P2P Dings klingt zwar nett, kann jedoch nie gut funktionieren, weil sich immer irgendwelche User hinter irgendwelchen Firewalls befinden, die aus irgendwelchen Gründen irgendwelche Ports blockieren.
-
Natürlich muss immer eine Verbindung zum Server bestehen, da praktisch alle Chatprotokolle den ganzen Chat über den Server routen und eigentlich jeder Client NUR mit dem Server verbunden ist.
-
Ethon schrieb:
Natürlich muss immer eine Verbindung zum Server bestehen, da praktisch alle Chatprotokolle den ganzen Chat über den Server routen und eigentlich jeder Client NUR mit dem Server verbunden ist.
Kannst Du bitte begründen, warum das so sein muss? Aus prinzipiellen, nicht aus traditionellen Gründen.
314159265358979 schrieb:
So ein P2P Dings klingt zwar nett, kann jedoch nie gut funktionieren, weil sich immer irgendwelche User hinter irgendwelchen Firewalls befinden, die aus irgendwelchen Gründen irgendwelche Ports blockieren.
Hmmm. Warum ist das in Anbetracht aller Netzwerke die man tagtäglich benutzt und für die man jeweil einen Port freischalten muss, ein Problem? Ernstgemeinte Frage. Dein Einwurf ist der erste ernst zu nehmende in diesem Thread.
-
Ignobel schrieb:
Ethon schrieb:
Natürlich muss immer eine Verbindung zum Server bestehen, da praktisch alle Chatprotokolle den ganzen Chat über den Server routen und eigentlich jeder Client NUR mit dem Server verbunden ist.
Kannst Du bitte begründen, warum das so sein muss? Aus prinzipiellen, nicht aus traditionellen Gründen.
Solange IPv6 noch nicht allgemein verbreitet ist und NAT immer noch eingesetzt wird, ist das ein Problem. Kein Mensch möchte zur Nutzung eines Chat-Programms erst umständlich in seinem Router eine Port-Weiterleitung einrichten.
-
Ignobel schrieb:
Eine sehr einfache Lösung wäre es, wenn der Server alle (sagen wir) 15 min. eine Verbindung zu allen Usern aufbaut und prüft ob sie tatsächlich noch den Status "online" im Netzwerk haben. Ich habe mich nur gefragt, ob es elegantere Möglichkeiten gibt als ein solches Polling und wie man einen Fehlerhaften Status sowohl möglichst schnell entdeckt als auch mit möglichst wenig Traffic entdeckt. Stets die Verbindung offen zu halten zwischen Usern und Servern sieht mir wie gesagt nach Resourcenverschwendung auf, die ganze Kommunikation soll nämlich nicht über den Server laufen sondern durch Direktverbindungen der User. Also tatsächlich eher wie ein P2P-Netzwerk und dem Server fällt zentral die Aufgabe zu, IP-Listen der eingeloggten Freunde zu verteilen.
Die Instant-Messanger die ich kenne machen aber genau das: immer eine Verbindung zum Server offenhalten.
Damit der Server mitbekommt wenn ein Client "verschwindet" ohne die Verbindung sauber zu trennen, hat der Server einfach ein Timeout. Wenn ein Client sich N Minuten nimmer gemeldet hat trennt der Server selbst die Verbindung.
Die Bandbreite die man dazu braucht ist auch nicht wirklich sehr hoch. Für die "bin noch da" Pakete die zwecks Keep-Alive versendet würden sollte eine 10 Mbit Leitung für ne Million gleichzeitig verbundener User reichen. Mit Logon/Logoff und Benachrichtigung anderer Clients wird man etwas mehr brauchen - vielleicht das 3-4 fache? Kommt drauf an wie viele Kontakte der durchschnittliche User eingetragen hat, und wie lange ein User so durchschnittlich eingeloggt ist. (Ich hab' keine Zahlen dazu, kann diesbezüglich also auch nur raten)Bei P2P kann man da auch nicht viel optimieren. Natürlich können die Clients Nachrichten direkt untereinander verschicken (sofern sie durch die Firewall des anderen kommen). Sobald man aber "... ist jetzt Online" Benachrichtigungen will, braucht man irgendeine Zentrale Stelle. Können auch mehrere sein, und die Funktion der "Server" kann auch dynamisch an Clients verteilt werden die eingehende Verbindungen akzeptieren können. Das macht die Sache aber wesentlich komplizierter.
Das kann allerdings auch nur dann gut funktionieren, wenn immer genug Clients online sind. Und so lange der P2P-Swarm nicht sehr gross ist, wird man trotzdem einen "Master-Server" brauchen, von dem neu hinzukommende Clients erfragen können welche "Slave-Server" es im Moment gerade gibt.Es wäre natürlich auch möglich, dass die Clients untereinander Verbindungen aufrecht halten. Der Server müsste dann wirklich nur pro User die letzten paar IPs speichern von denen sich dieser gemeldet hat.
Jeder Client könnte dann beim Login eine Liste seiner Kontakt-IPs erfragen, und dann selbst eine Verbindung zu jedem Kontakt aufbauen. Wenn man nicht will dass diese Verbindungn von diversen Firewalls mit SPI irgendwann einfach getrennt werden muss man hier allerdings auch wieder Keep-Alives verschicken.Dadurch entlastet man also den Server, dafür belastet man das Netz als ganzes mehr - man muss ja jetzt auch einmal an N Kontakte Keep-Alives verschicken statt nur an einen Server.
-
Ignobel schrieb:
Hmmm. Warum ist das in Anbetracht aller Netzwerke die man tagtäglich benutzt und für die man jeweil einen Port freischalten muss, ein Problem? Ernstgemeinte Frage. Dein Einwurf ist der erste ernst zu nehmende in diesem Thread.
Du kannst natürlich deinen Userkreis auf Personen einschränken, die die Möglichkeit und die nötigen Kenntnisse haben einen Port freizuschalten.
Gib dich aber nicht der Illusion hin, dass es für die meisten User kein Problem wäre. Es ist für genug User ein Problem.Ich kenne - berufsbedingt - viele Leute die auch professionell mit Computern zu tun haben. Darunter sind wirklich viele, die keine Ahnung haben wie man das macht, bzw. die es vielleicht hinbekommen würden wenn sie sich damit befassen, aber es einfach nicht wollen. D.h. es nur im äussersten Notfall tun würden.
-
Das macht man in der Installationsroutine, im Winwowsbereich mit
netsh firewall set portopening UDP <Nummer> "<Bezeichnung>"Interagiert der User nicht im Client, gibts ein Time out. Nachrichten werden dann zwichengespeichert. Connectet der User wieder, z.B. durch Interaction mit dem Client, werden die Nachrichten abgerufen.
Alternativ könnte man eine fast serverlose Variation, ähnlich einem Routingprotokoll verwenden. So eine Art Broadcasting zwischen den Clients die sich kennen. Einer kennt 5, der nächste kennt auch 5 andere usw. Soll eine Nachricht an einen gehen werden die anderen Clients gefragt wer den kennt.
-
Dean schrieb:
Das macht man in der Installationsroutine, im Winwowsbereich mit
netsh firewall set portopening UDP <Nummer> "<Bezeichnung>"Nur lässt sich davon ein eventueller Router wenig beeindrucken.
-
ipsec schrieb:
Dean schrieb:
Das macht man in der Installationsroutine, im Winwowsbereich mit
netsh firewall set portopening UDP <Nummer> "<Bezeichnung>"Nur lässt sich davon ein eventueller Router wenig beeindrucken.
Stimmt du hast recht, man sollte erst einen Kaffee trinken und dann posten ^^.
Wie machen das nicht serverbasierende Filesharingprogramme? Da gibts meist die Möglichkeit mit Lowspeed ohne Routerkonfiguration zu sharen, der Speed würde ausreichen.Ein wenig off Topic, stellt sich mir die Frage zum UMTS Netz, Firewals und Sicherheit bei Smartphones spielen bisher keine Rolle. Von Serviceprovidern habe ich die Auskunft bekommen, dass SMartphones ohne beauftragtes IPSec kein eigene IP Adresse haben. Was absoluter Nonsens ist, bei IPsec hat der Einwahlpunkt eine statische Adresse, dass Zertifikat wird nicht vom Provider gestellt. Jedes Gerät hat eine zumindest nicht statische Adresse. Passieren scheint jedoch bisher nichts.
-
ipsec schrieb:
Nur lässt sich davon ein eventueller Router wenig beeindrucken.
Der Router ist nicht wirklich ein Problem. Des Routers Funktionalität ist es schließlich, Pakete weiterzuleiten.
Der Kasten, den wir Zuhause stehen haben und fälschlicherweise als Router bezeichnen, ist eine Eierlegende Wollmilchsau. (kurz: EWMS) Die EWMS besteht aus Modem, Router, Firewall, Switch und evtl einem WLAN Accesspoint. Das Problem ist hier, wie oben schon gesagt, die Firewall und nicht der Router selbst. Die Firewall blockiert meist eingehende Verbindungen völlig, weshalb hier ggf. ein Port freigeschaltet werden müsste.
-
@314159265358979
Du verweigerst dich mal wieder der Realität gegenüber.Ein Router der NAT macht (und zwar die Art von NAT die in allen "Home-Routern" gemacht wird, also mit IP-sharing), ist notwendigerweise ein Problem, weil er keine eingehenden Verbindungen annehmen kann, wenn er nicht weiss, wohin er sie weiterleiten soll.
Man muss also ein Port-Mapping eintragen, damit der Router die Verbindung durchlassen kann.
Der "Firewall-Effekt" der sich daraus ergibt ist ein Artefakt des NAT.Zu sagen der Router wäre kein Problem, ist daher mindestens reichlich naiv bis komplett falsch - je nachdem wie man es sehen will.
-
Das ist jetzt ein wenig Harspalterei.
Die eierlegende Wollmichsau des Providers wird im Volksmund halt Router genannt und das obwohl die meisten werder Rip noch andere Routingprotokolle können. Aber jeder weiß worum es geht.
Die die eine Astaro oder ähnliches Gerät stehen haben sind in der Lage die entsprechend Ports freizugeben oder halt zu sperren.
