On Sun, 27 Oct 2002 10:54:29 +0200, Konrad Rosenbaum wrote:
Solche Low-Traffic-"Verbindungen" für wahnsinnig viele, eher sporadisch kommunizierende Clients würde man vermutlich mit UDP + Bestätigungsnachrichten besser realisieren können, so in Richtung Message Queuing. Der Overhead durch TCP wäre sonst größer als der Payload, von den verschwendeten Ressourcen fürs Verwalten der TCP-Verbindungen auf dem Server ganz zu schweigen.
Um die Schwächen von UDP (verbindungslos, keine Garantie für Paketlieferung, keine Garantie der Reihenfolge, etc.) willst Du in einer Produktionsumgebung definitiv nicht herumarbeiten! In Produktion lässt Dir niemand die notwendige Zeit, um solche Protokolle auszutesten.
Hier im Thread ging es vermutlich erstmal nur um die technische Machbarkeit. Bei den von Joseph gewünschen 100k clients kommt man nicht umhin, neue Wege zu gehen und etwas neues zu bauen. Es ist wenig sinnvoll über mangelde Zeit bei der Produktentwicklung zu reden, wenn noch nichtmal die fürs Produkt nötige Technologie vorhanden ist. Wirtschaftlich zu denken ist ja nett, dazu gehört aber auch eine F+E-Phase. Sowas kostet Zeit und Geld (Echte Zeit, nicht nur beliebig parallelisierbare Mannjahre)
Andererseits sind Ressourcen dort nicht das primäre Problem (Du musst nur oft genug betonen, dass es um Produktion geht).
Ich kann 10 mal laut schreien "Es geht um Produktion". Davon wird die gewünschte Anwendung trotzdem nicht einfacher realisierbar. Bei 100k clients muß man sich sehr genau überlegen, wohin man die CPU-Power steckt. Von der CPU mit 2 GHz im Server bleibt bei (idealistischer) Aufteilung auf 100k pro clients eine 20 KHz-CPU, die einen Client zu versorgen hat. Da mußt du den CPUs so viel wie möglich Arbeit abnehmen.
Overhead hast Du bei diesen Systemen sowieso,
Wie meinst du das? Du meinst, der Rest des Systems ist sowieso Schei*e implemntiert, weshalb man sich bei der Netzanbindung auch keine Mühe mehr geben muß?
da stört der TCP-Anteil nicht mehr.
TCP ist nicht so easy. Für jede Verbindung fällt einiges an Aufwand für die virtuellen 20 kHz-CPUs an.
Bei der Lösung brauch man für den Netzwerkteil der Serveranwendung gar keine Threads oder irgendwelches Multiplexen von Verbindungen. Das Serverprogramm schaut sich nur grob an, wozu das eintreffende Paket dient und reicht es dann zur eigentlichen Verarbeitung an einen von mehreren langlaufenden Prozessen weiter.
Also muss das Serverprogramm die Ressourcen (=Verbindungen) intern verwalten, entsprechende Timeouts verwalten, Nachrichten per Message Passing weiterleiten etc.pp.
Genau. Nur so kann man sich daraf beschränken, lediglich das zu tun, was unbedingt nötig ist. Das Serverprogramm wird beispielsweise sowieso intern eine tabelle aller zur zeit Verbunden Clients halten müssen. Warum sollte ich so eine Info nochmal redundant in der Netzwerkschicht mitführen? Dinge wie die Flußkontrolle von TCP sind völlig sinnlos, wenn nur ab und zu mal ein paar Pakete über die Leitung gehen. Die Checksummen im Header sind ebenfalls unsinnig. Die wird zwar bei GB-Ethernet zum Glück in Hardware gemacht, vergrößert aber unnötigerweise die Übertragungszeit und die nötigen Pufferspeicher.
Zusätzlich müssen Client und Server noch Packet-Repeat (inclusive Erkennung von repeated Packets) und diverse andere Algorithmen implementieren, die eigentlich TCP übernehmen könnte - und das alles zusätzlich zu ihrer eigentlichen Aufgabe.
Ja. Und all die für den Einsatzfall sinnlosen Dinge an TCP kann man weglassen. Es gibt übrigens fertige Bibliotheken für Message Passing, die zumindest auf clientseite eingesetzt werden können.
Das Entwicklungsbudget für dieses PPS will ich genehmigt sehen!
Zeig mir das PPS-System, was zentral 100k clients versorgt. Sowas gibts nicht für 3 Mark 80 beim Händler um die Ecke
Bei PPS sprechen wir über 500-5000 gleichzeitige Verbindungen zum Server,
Du hast (aus Versehen?) einfach die Clientzahl um Faktor 20-200 reduziert. Was machen die anderen 95000 Nutzer, die bei deiner Fertiglösung unter den Tisch fallen? Du willst 20-200 Server statt nur einen hinstellen? Schön, mach das. Nur hast du damit nicht zur Lösung vom Josephs Problem beigetragen. Er wollte eben mit einer Kiste *möglichst* *effektiv* massenhaft clients bedienen, statt massenhaft Rechner hinzustellen, die mit alter Software arbeiten.
integriertem Failover, Transaktionssicherung (nein, das hat diesmal nix mit Datenbanken zu tun) und erheblichen Kosten, wenn auch nur einige Kleinigkeiten schiefgehen.
... buzzwords, die nichts mit der Realisierung der Netzwerkgeschichte zu tun haben.
Ich denke, daß Server mit 100k clients erst dann Verbreitung finden, wenn ein Großteil des IP-Stacks in Silizium relisiert wird. Wenn man sich aber auf heute üblicher Hardware daran versuchen will, 100k clients zu bedienen, würde ich keinesfalls anfangen, mit TCP rumzu- spielen.
Reinhard