Maximale Anzahl (p)threads?
-
Da es hier vermutlich sowieso um Linux geht eigetlich hinfällig aber:
Windows läßt nur eine bestimmte anzahl gleichzeitiger verbindungen zu solange man es nicht in der Registry ändert.
IMHO bei XP 10.
-
Windows läßt nur eine bestimmte anzahl gleichzeitiger verbindungen zu solange man es nicht in der Registry ändert.
IMHO bei XP 10.Du meinst das Half-Open Connection Limit.
-
Jo das meint er, und das lässt sich gottseidank patchen.
Man guckt im Event-Log nach dem Eintrag, notiert sich die EventID, sucht damit im Google -> findet den Patch -> lädt ihr herunter -> installiert ihn -> hat Ruhe. Oder so ähnlich
@voidpointer:
Wenn du recv nur auf die Sockets versuchst wo select() auch hingehaut hat, dann sollte es gehen. Wenn du bloss vorher select() machst und dann trotzdem auf alle Sockets ein recv machst ist es klar dass es blockieren wird.
-
Hmm die Frage die ich eigentlich hatte war:
-Wenn der Server etwas send()et, aber der Client erst 3 Sekunden später recv()ed... wo werden die zwischengespeichert?
-Könnte es passieren, dass alle Messages, die noch nicht empfangen wurden, aber schon vom Server geschickt wurden, auf irgendeinem Buffer beim Client gespeichert werden, und wenn dieser Buffer voll ist, keine weiteren send()s der Server zugelassen werden?
-
also dein os hat ein-/ausgans-fifo-caches für quasi alle io-operationen. wie groß der ist, ist systemabhängig und dein system regelt bei synchronen zugriffen auch, dass der nicht überlaufen kann, in dem er bspw bei netzwerkclients die empfangsbestätigung verweigert oder aktiv mitteilt, dass es zu schnell geht.
bei async liegt je nach system ein teil der verantwortng bei dir.
-
@vp:
Der Sender-PC puffert es solange bis er vom Empfänger-PC die Bestätigung bekommen hat dass dieser es nun empfangen & gepuffert hat. Der Empfänger-PC puffert es dann solange bis das Empfänger-Programm es abholt.
Wenn das Empfänger-Programm sich zu lange Zeit lässt, oder der Sender-PC zu schnell Daten schickt, dann kann es sein dass die max. Grösse des Empfangspuffers beim Empfänger-PC erreicht wird.
Macht aber nix, weil der Empfänger-PC dem Sender-PC auch ständig mitteilt wie viel von seinem Puffer noch frei ist. Der Sender-PC hört dann, wenn laut seinen Informationen im Empfänger-Puffer nichtmehr genug Platz ist, automatisch auf neue Daten zu schicken bis er wieder vom Empfänger-PC gehört hat dass wieder Platz in dessen Puffer frei ist.
-
Danke hustbaer, das hilft mir!
hustbaer schrieb:
Macht aber nix, weil der Empfänger-PC dem Sender-PC auch ständig mitteilt wie viel von seinem Puffer noch frei ist. Der Sender-PC hört dann, wenn laut seinen Informationen im Empfänger-Puffer nichtmehr genug Platz ist, automatisch auf neue Daten zu schicken bis er wieder vom Empfänger-PC gehört hat dass wieder Platz in dessen Puffer frei ist.
Gilt das auch bei UDP? Und wie lange macht der Sender PC das mit?
-
Vielleicht wäre es angebracht, wenn du dich mal intensiver mit der TCP/IP Protokollfamilie auseinandersetzt um ein besseres Verständnis dafür zu bekommen
Was sind diese half-open Connections?
-
@vp:
Nein, für UDP gilt das nicht.Bei UDP schickst du einfach Pakete, und ob ein Paket durchgeht oder nicht ist einfach "Glückssache". Es sind da zwar AFAIK einige Mechanismen am Werk die versuchen den Verlust zu minimieren, wie die genau funktionieren weiss ich allerdings leider nicht. Allerdings wird bei UDP niemals eine Re-Transmission von bereits gesendeten Paketen gemacht. Der Sender-PC muss also schonmal garnix puffern nachdem er es abgeschickt hat. Der Empfänger PC puffert die Pakete soweit ich weiss eine gewisse Zeitlang bzw. bis der Puffer den er hat eben "voll" ist, weitere Pakete werden dann einfach verworfen wenn das Empfänger-Programm die Daten zu langsam abholt.
-
@Bücherwurm
Eine halb offene Verbindung ist die wo das Telefon noch läutet. D.h. der eine hat ruft grad an, der andere hat aber noch nicht abgehoben.
Diese Phase ist normalerweise recht kurz, daher wirkt sich das Limit von max. 10 halboffenen Verbindungen bei Windows XP auch nicht so tragisch aus.
Wenn der "angerufene" PC allerdings gerade nicht da ist (z.B. nicht läuft oder die Internet-Leitung nen Hänger hat), dann dauert diese Phase ziemlich lange (etliche Sekunden), und endet dann mit einem Fehler.Da solche Fälle (der angerufene PC meldet sich nicht) bei bestimmten Programmen ziemlich oft auftreten werden diese auch stark ausgebremst. z.B. Viren die einfach irgendwelche zufälligen IPs berechnen und versuchen sich dorthin zu connecten, oder auch P2P Programme die versuchen Peers zu connecten die aber grad nicht online sind.
