Server entlasten
-
allo,
also das ist mehr so eine theoretische Frage (ich habe es bis jetzt auch nur theoretisch in der Schule überlegt). Falls notwendig bitte in Rund um... oder so verschieben (es ist aber ne Frage zu TClientSocket und TServerSocket dabei, darum BCB).
Ich würde das Problem gerne z.B. am Beispiel von einem Chat umsetzen.
Problem:
Wenn es jetzt nur einen Server gibt, dann hauts den ja ab einer bestimmten Benutzerzahl zusammen (zuviel Traffic, zuviel Verarbeitungsaufwand).Lösungsansatz:
Ich habe mir dann überlegt, man könnte es auf mehrere Server verteilen, die dann auch noch untereindander miteinander verbunden sind (Clients müssen sich halt dann einen freien Server suchen). Also einer schreibt eine Nachricht, diese wird an seinen Server gesendet dieser Server sendet sie weiter an die Clients, die mit ihm verbunden sind und an die Server, mit denen er verbunden ist (u.s.w.).Da ist mir allerdings ein Problem aufgefallen:
Wenn sich Server A mit Server B, Server B mit Server C und Server C mit Server A verbindet, dann habe ich sozusagen einen "Kreis" und die Nachricht wird bis in alle Ewigkeit umhergeschickt.Eine Möglichkeit wäre es jeder Nachricht eine eindeutige ID (IP + Datum + Uhrzeit) zu geben. Dann würde sich bei einem Chat aber der Traffic verhältnismäßig hoch erhöhen. Außerdem müsste dann jeder Server die IDs eine bestimmte Zeit lang speichern (und wenn die Nachricht theoretisch zehn mal um die Welt und dann erst zu einem Server geschickt wird, kann das ja etwas dauern).
Eine weitere Möglichkeit wäre es, dass sich Server B, sobald er die Verbindung zu Server A hergestellt hat, sich von A eine Liste mit den IPs der Server geben lässt, mit denen A verbunden ist und der IPs mit denen die Server verbunden sind, mit denen A verbunden ist; also die gesamten Server IPs des derzeitigen Netzwerkes. B darf sich dann mit keiner der IPs verbinden (kann sie aber speichern, falls A mal offline ist). Wenn B sich jetzt mit einer neuen IP verbindet, schickt er diese IP an A und A reicht sie an alle anderen Server weiter. So kann (glaube ich) so ein "Kreis" nicht enstehen.
Wie arbeiten aber die TServer und TClientSocket Komponenten. Was ist wenn Server A jetzt über eine lahme Verbindung eine Liste mit tausenden (nur theoretisch) IPs von Server B bekommen würde und zur gleichen Zeit eine Nachricht von einem seiner Clients. Kommen dann erst die IPs und dann die Nachricht an oder wird das vermischt? So müsste man ein Protokoll definieren (dürfte ja noch schaffbar sein) allerdings ist der Server, der gerade tausende von IPs verschickt, außer Gefecht gesetzt.
Ich hoffe ihr konntet mir folgen und vielleicht einige Tipps oder neue Vorschläge dazu geben (oder Probleme aufzeigen).
Robert[ Dieser Beitrag wurde am 07.07.2003 um 18:09 Uhr von Jansen editiert. ]
-
Boah
da haste aber was vor. Solltest vielleicht mal das netz durchstöbern auf der Suche nach SKALIERBARKEIT so nennt man das was du da machen möchtest, denke ich
Viel Spass dabei
-
Original erstellt von <Robert>:
Wenn sich Server A mit Server B, Server B mit Server C und Server C mit Server A verbindet, dann habe ich sozusagen einen "Kreis" und die Nachricht wird bis in alle Ewigkeit umhergeschickt.Dann verhindere doch einfach, dass sich ein Server mit mehr als einem anderen Server verbindet, und/oder führe einen Masterserver ein, der nur die Unterserver verwaltet.
Was die "Tausende von IPs" betrifft, schick sie halt "bündelweise" und sieh zwischendurch nach, ob noch andere Nachrichten zu verarbeiten sind.
Das ist aber alles äusserst abstrakt und hat nicht wirklich mit den BCB-Komponenten zu tun, deshalb verschoben nach "Rund um".
-
Hallo,
das mit einem Masterserver habe ich mir auch schon überlegt (ist auch wohl am einfachsten). Das einzige was mich daran stört ist:
Masterserver tot => Netzwerk (fast) tot.Robert
-
Die Server könnten so arbeiten, dass es einen Master Server gibt, der managed eben die Server. Wenn dieser ausfällt, dann übernimmt der nächste Server die Aufgaben des Master Servers und so weiter (bis eben kein Server mehr über ist).
-
Hallo,
Die Server könnten so arbeiten, dass es einen Master Server gibt, der managed eben die Server. Wenn dieser ausfällt, dann übernimmt der nächste Server die Aufgaben des Master Servers und so weiter (bis eben kein Server mehr über ist).
da gibt es nur 2 neue Probleme:
1. Woher wissen die Server dann voneinander? Man müsste dann wohl vom Masterserver beim Herstellen der Verbindung die IPs der Server an alle Server schicken...
2. Wie einigen sich die Server auf einen neuen Masterserver? Man könnte den ganz oben auf der Liste der IPs nehmen. Ob da jemand aber so glücklich ist, falls sein Server plötzlich Masterserver ist?
Aber man muss es wahrscheinlich so machen. Denn wenn jetzt z.B. Server A mit Server B und Server B mit Server C verbunden ist und B ausfällt, dann wissen A und B nichts voneinander.
Wenn allerdings der Masterserver zusammenbricht, dann bricht auch das Netzwerk kurzzeitig zusammen. Außerdem ist auch die Kapazität von so einem Server irgendwann erschöpft (man könnte mehrere Masterserver machen, die untereinander miteinander verbuden sind. Nur dürfte dabei kein "Kreis" entstehen
und so beginnt alles wieder von vorne).
Robert
-
Aber man muss es wahrscheinlich so machen. Denn wenn jetzt z.B. Server A mit Server B und Server B mit Server C verbunden ist und B ausfällt, dann wissen A und B nichts voneinander.
ich meine natürlich A und C wissen nichts voneinander.
und noch was: falls ein Server die IP Liste nicht vollständig bekommen hat, verlässt sich dieser auf einen Masterserver, der gar keiner ist.
Robert
-
Vielleicht solltest du mal bei einem etablierten System "Anschauungsunterricht" nehmen. Auf Anhieb fällt mir dabei das SMB/CIFS-Protokoll der Windows-Dateifreigabe ein, dort wird u.a. auch die Rolle des Masterservers dynamisch vergeben. Informationen darüber solltest du der Dokumentation der OpenSource-Implementierung Samba entnehmen können.
-
ich würde das System so designen, dass sich der Master Server direkt um einen potentiellen Nachfolger kümmert.
Meine Idee sieht so aus, dass der Master Server eben eine Liste an Slaves (die anderen Server an die die Aufgaben verteilt werden), besitzt. Die Slaves sortiert er nach Leistungsstärke, damit er weiss, wie viele Clients jeder Slave ungefähr verwalten kann. Diese Liste, ist aber genauso auf den Slaves vorhanden. Wenn der Master Server n Sekunden lang keine Daten mehr gesendet hat, dann schickt er eben eine Art "PING" an die Slaves, damit diese wissen, der Master existiert noch. Wenn nun nach n Sekunden kein "PING" gekommen ist, übernimmt der als Ersatz makierte Slave die Aufgaben des Masters (und schickt eine Warnmeldung an den Admin).
Das zu implementieren sollte nicht schwer sein IMHO
-
Schau doch mal, wie das die IRC Server machen, ist ja ziemlich ähnlich...
-
ich würd mit supernodes arbeiten
SuperNode1 - - - 10 Clients MASTER < SuperNode2 - - - 10 Clients
und so weiter.
damit sparst du dir connections, das einzige problem bleibt weiterhin der master server. aber dafür könnte man sich leicht was basteln (dass einer automatisch das übernimmt)
Warum das connections spart? von supernode > masterserver wird über eine verbindung der chat von 10 geführt. retour kommt vom master server jeweils die globale änderung. gepolt mit nem trigger für die rücksendung (beim master einfach nen trigger einbauen a lá "wenn was kommt, dann send ich zurück") dürfste das system funktionieren
-
Hallo,
ich glaube, man muss sowieso alles über einen zentralen Masterserver machen. Zu dem verbinden sich alle Server und der leitet die Nachrichten an alle Server weiter. Falls der offline geht muss einer der Server neuer Masterserver werden und alle verbinden sich mit ihm.
Das ist die einzige Schwachstelle. Es sollte natürlich so ziemlich der Leistungsfähigste vom Rest sein. Wie kann ich das herausbekommen? Dann schickt der Masterserver jedem Server einfach so drei "Ausweichips" und dann probieren die restlichen Server sich zu dem ganz oben in dieser topthree zu verbinden.Robert
-
Wie kann ich das herausbekommen?
Du könntest ein kleines Benchmark Script schreiben, was das System bewertet mit einer Punkteskala, die Punkte werden dann ebenfalls abgeglichen.