ich würde gerne ein Programm schreiben welches über TCP Daten empfangen soll diese dann in eine Datenbank abspeichern soll. Der Aufbau ist folgendermaßen aufgebaut.

Server mit TCP Listener (empfängt die Daten)
Client welches einen String sendet (ca. 2000 Clients)

Jetzt sollen die Daten empfangen und abgespeichert werden. Das system muss schnell und Stabil laufen. Wie sollte ich das Programm am besten Programieren. Vorgenommen hatte ich es in c++ zu programieren unter Windows. Was muss ich verwenden was brauchen ich ? Threads? Sockets?

Ein paar Tipps würden mir gut tun. Vielen Dank schonmal.

Threads? Sockets?

Klingt passend. Hast du denn schon Erfahrung? Das ist nämlich nicht trivial.

Welches ist den Richtig. Es soll nämlich auch zum Beispiel mehrere Clients gleichzeitig handeln können.

beides ist richtig,
aber es ist schwer, ohne genaue Anforderung, was dazu zu sagen.

Ich würde versuchen die Anzahl Threads einzuschränken:

z.B.
Der Main Thread behandelt alle Clients und pushed die Daten in eine Queue (FIFO).
Ein Datenkbank Thread transportiert die Daten von der Queue in die Datenbank.

Gruß Frank

aber ich habe gelesen das wenn ich Threads benutze es Probleme geben kann.

z.b.
Wenn Client1 einen String sendet wird ein neuer Thread eröffnet. Dann sendet aber gleichzeitig auch Client2 und Client3 zum gleichen Zeitpunkt einen Thread. So werden 3 Threads eröffnet und der Client1 wird doch zuletzt abgearbeitet oder ?

Wenn du für jeden Client einen Thread verwendest,
dann ist die Abarbeitungsreihenfolge bei bis zu 2000 threads willkürlich
und nicht vorhersehbar.
Es ist korrekt was du gelesen hast.

Das genau würde ich nicht machen:
Über TCP wird die Datenrate geringer sein,
als die maximale Schreibgeschwindigkeit mit der man die Daten einen FIFO (RAM) schreiben kann.
Deswegen alleine braucht man also an dieser Stelle nicht mit Threads zu arbeiten.

Das Schreiben in die Datenbank ist da schon aufwändiger
und könnte ohne Threads die Clients unnötig ausbremsen.

Gruß Frank

danke für deine Antwort. Also soll ich für das empfangen keine Threads aber für das eintragen in die DB Threads verwenden ???

Soll ich also z.B. für jede Client anfrage einen Socket eröffnen die Daten in einen BUF schreiben einen Thread eröffnen welche dann die Daten in die DB einspeichert?

Oder hast du eine bessere Idee welche mir auf die Sprünge hilft.

Welches ist den Richtig. Es soll nämlich auch zum Beispiel mehrere Clients gleichzeitig handeln können.

Viele Wege fuehren nach Rom, manche via Threads, andere ueber Prozesse und wieder andere ueber select.

Also soll ich für das empfangen keine Threads aber für das eintragen in die DB Threads verwenden?? Soll ich also ...

Es gibt kein soll, nur ein guenstig oder unguenstig. Klar kannst du 2000 Threads benutzen, aber ob es unguenstig, kann pauschal nicht gesagt werden.

aber ich habe gelesen das wenn ich Threads benutze es Probleme geben kann.

Was meinst du? Mit einem Brotmesser kann es auch Probleme geben.

> das kann man ja auf einen beliebigen Wert setzen.

Nein, die fd_sets sind AFAIK intern Bitfelder, die du nicht willkürlich verändern kannst.

> ist kein wirkliches Argument, man kann ja select mehrfach aufrufen.

Wenn sie nicht blockieren, ja. Non-blocking-selects sind aber nun wirklich nicht die Bombe was Leistung angeht.

http://www.fefe.de/scalable-networking.pdf

> FD_SIZE ist ein Makro, das dann wohl die Feldgröße bestimmt.

Exakt, aber AFAIK ist das read-only gedacht, wegen Bitfeldern. Mit Linux könnte man es tatsächlich ändern, danach muss aber der ganze Kernel neu kompiliert werden, was bei Windows schwierig werden könnte. Du könntest mehrere fd_sets nutzen und mit mehreren selects() und mit timeouts evtl. was werkeln, aber 32 selects mit timeouts finde ich nicht skalierbar, dann warten sie letzten fd's alle timeouts ab, bis sie drankommen. Threads verschlimmbessern das m.E. dann auch nur noch.

Ach ja, um mal http://support.microsoft.com/?scid=kb%3Ben-us%3B111855&x=6&y=12 zu zitieren:

The maximum number of sockets that a Windows Sockets application can use is determined at compile time by the manifest constant FD_SETSIZE. To do this, [...]

Wie ernst man das nehmen kann, weiß ich nicht, da die Aussage sowieso schon Unfug ist. Die Maximalzahl Sockets in einem Programm hat rein gar nichts mit FD_SETSIZE zu tun.

es waere mal interessant zu wissen, ob die 2000 clients alle mit dem server verbunden bleiben oder ob er 2000 clients hat die sich nur dann verbinden, wenn sie paar zeichen rueber senden wollen.

ein kleiner ueberblick was performance angeht:
http://technixlab.de/net_performance.jpg

ob die datenbank ein flaschenhals ist oder nicht kann man bis dato nicht beurteilen.

meep meep

also 2000 Clients senden alle 30 sec. einen String.
So läuft es ungefähr ab:

Client meldet sich Verbindung herstellen
Sendet String Daten empfangen
Client geht (weis aber nicht ob er selber die Verbindung trennt)

Die müssen nicht dauerhaft verbunden sein nur dan wen ein string empfangen werden soll. Kann aber auch vorkommen das sich mehrer Clients gleichzeitig melden.

ein einzelner thread schiebt dann die daten aus der queue in die datenbank

meep meep

Das heist es könnten zu gleicher Zeit 50 clients gleichzeitig Connecten. Die senden die Message wird sofort in eine queue geschoben und thread geschlossen.

und eine Andere Funktion schreibt den Queue Inhalt in die Datenbank.

Richtig?

Hallo Meep Meep,

Das heist es könnten zu gleicher Zeit 50 clients gleichzeitig Connecten. Die senden die Message wird sofort in eine queue geschoben und thread geschlossen.

und eine Andere Funktion schreibt den Queue Inhalt in die Datenbank.

Richtig?

ein anderer thread schreibt den inhalt in die DB.
der thread wird nicht geschlossen, sondern die verbindung zum client.
ansonsten ja

Meep Meep

Wenn es richtig performant werden soll (für Windows): Thread-Pools und IO-Completion Ports. Ob das im Gegensatz zu Linux performant ist? Eher nicht.

Wie kommst du zu dem Fazit "Eher nicht."?

Gemessen oder einfach mal so daher geraten?

BR

http://www.fefe.de/scalable-networking.pdf">
Auch Microsoft hat das Problem, daß sie skalierbare Netzwerkprogrammierung
anbieten wollen. Die Microsoft-Lösung hierbei ist, daß man einen Thread
Pool aufmacht, und dann in jedem Thread mit einem SIGIO-ähnlichen Verfahren
die Events benachrichtigt bekommt.
Hier werden also die Nachteile von Threads mit den Nachteilen von SIGIO
verbunden. Es ist beeindruckend, was Microsofts Marketing-Maschine aus diesem
Schrumpelküken für ein Monster aufgeblasen hat.
Immerhin gibt es da auch lustige Zitate in der Dokumentation:

"First of all,
threads are system resources that are neither unlimited nor cheap." Äh, nicht
cheap? Ich dachte, das sei ihre Existenzberechtigung!