-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday 27 October 2002 08:06, Reinhard Foerster wrote:
On Sat, 26 Oct 2002 12:28:03 +0200, Eric Schaefer wrote:
Denk mal in eine andere Richtung als HTTP, IRC und Co. Stichwort Flugbuchungssysteme, PPS in sehr großen Firmen etc. Da sind zwar sehr viele Verbindungen offen, aber die greifen nicht alle gleichzeitig Daten ab.
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. Andererseits sind Ressourcen dort nicht das primäre Problem (Du musst nur oft genug betonen, dass es um Produktion geht).
Overhead hast Du bei diesen Systemen sowieso, da stört der TCP-Anteil nicht mehr.
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. 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.
Das Entwicklungsbudget für dieses PPS will ich genehmigt sehen!
Bei PPS sprechen wir über 500-5000 gleichzeitige Verbindungen zum Server, integriertem Failover, Transaktionssicherung (nein, das hat diesmal nix mit Datenbanken zu tun) und erheblichen Kosten, wenn auch nur einige Kleinigkeiten schiefgehen. Da will man so wenig wie möglich selbst implementieren (schon weil die zusätzlichen Tests ein Vielfaches der Entwicklungszeit verschlingen).
Konrad