Servus, für meinen Mailpproxy hätte ich gerne die Information wieviele sockets noch verfügbar sind. Wie macht man das ? Einfach probieren bis ende dürfte mir das System killen. W7, GNU C++/C
Das dürfte mit der Anzahl der insgesamt noch verfügbaren Filedeskriptoren zusammenfallen. Ganz frühe Linuxe hatten da ein 2^15 Limit.
Joachim D. schrieb: > für meinen Mailpproxy hätte ich gerne die Information wieviele > sockets noch verfügbar Hat normalerweise mit der Anzahl der File Handles im Prozess zu tun, weil ein Socket ein File Handle belegt. Limits hängen leider auch davon ab ob das ein 32-bit oder 64-Bit Prozess ist, sollten aber jenseits von 1000 liegen IMHO. Jedoch sollte man bei einem Mailproxy auch die Gegenseite beachten, die Dich schon bei einer zweistelligen Verbindungszahl auf die "SPAM" Liste setzten und die Mitarbeit verweigern dürfte.
Das Programm lauscht an einem Socket. Kommt da etwas, macht es per OpenSSL die Verbindung zum Provider (mit den Logindaten des Clients, ich denke, da komme ich nicht auf die SPAM-Liste). Die Anzahl filehandles kann ich vorgeben, die Sockets sind auf max 65535 begrenzt (default sind es 256, auch einstellbar).
Joachim D. schrieb: > die Sockets sind auf > max 65535 begrenzt Und das dürfte prinzipbedingt sein, und vor allem für alle Prozesse auf dem System in Summe gelten. Schließlich wird mit jedem Socket eine lokale Portnummer assoziiert, und die wird mit einem uint16_t beschrieben.
Rufus Τ. F. schrieb: > Und das dürfte prinzipbedingt sein, und vor allem für alle Prozesse auf > dem System in Summe gelten. > Schließlich wird mit jedem Socket eine lokale Portnummer assoziiert, und > die wird mit einem uint16_t beschrieben. Ich hoffe doch sehr das heutige Systeme nicht mehr diese naive Implementierung verwenden. Eine Verbindung ist bei TCP durch 2 Ports und 2 IPs gegeben, jeweils eine für die Source und eine für die Destination. Man hat also, sofern man einen Port festlegt, nicht nur 2^16 Ports insgesamt für alle Verbindungen, sondern 2^16 Ports für jedes Source Destionation IP paar. Bei IPv4, wenn man zusätzlich eine der IPs festlegt, hat man immer noch 2^32 Adressen mal 2^16 Ports für alle Verbindungen, also insgesamt 2^48 theoretisch mögliche Verbindungen. Natürlich müsste man da noch den ungültigen Port 0, Broadcast und Multicast Adressen, etc. davon abziehen, aber das Gesamt Limit für Verbindungen, die ein System offen haben kann, ist definitiv nicht wegen dem Wertebereichs von TCP Ports begrenzt.
DPA schrieb: > das Gesamt Limit für > Verbindungen, die ein System offen haben kann, ist definitiv nicht wegen > dem Wertebereichs von TCP Ports begrenzt. Das hat hier auch niemand behauptet. Das Limit waren die max. erlaubten offenen Filehandles.
dh ich kann die erlaubte Anzahl Handles hochsetzen ? Watcom C hat _grow_handles(), das gibt es bei GNU anscheinend nicht ... Ich habe schonmal 100.000 filehandles verwendet, weder der Compiler noch das System hatten gemeckert.
mmm schrieb: > Das hat hier auch niemand behauptet. Lies den von mir zitierten Bereich nochmal, dort wurde es das.
Joachim D. schrieb: > Das Programm lauscht an einem Socket. Kommt da etwas, macht > es per OpenSSL die Verbindung zum Provider (mit den Logindaten > des Clients, ich denke, da komme ich nicht auf die SPAM-Liste). Nö, dann kommt der User auf die "naughty" Liste und wird gebannt/gesperrt. Sowas steht oft in den "Terms of Usage" mit drin. Dann könnte eine zweistellige Anzahl Verbindungen gleichzeitig schon kritisch sein. Mails werden normalerweise hintereinander verschickt.
Jim M. schrieb: > Dann könnte eine zweistellige Anzahl Verbindungen gleichzeitig schon > kritisch sein. Mails werden normalerweise hintereinander verschickt. Der User loggt sich ja "direkt" beim Provider ein. Kein Mailclient macht dazu mehrere Verbindungen auf (nur TB bei IMAP).
Ein 64-Bit Windows scheint ein Limit von 16 Mio Handles zu haben. Jedenfalls hatte ich eine Weile mit einem Server zu tun, der das innerhalb von einigen Monaten schaffte. Wenn man sich auf Sockets bezieht, hinter denen TCP- oder UDP-Ports stehen, dann steckt letztlich das 2^16 Limit dahinter, weshalb man nicht mehr als 64k offene Server-Sockets zustande bekommen dürfte. Bei denen gibts ja nur eine Seite. Verbindungen könnten es mehr sein, weil dann (und erst dann) beide Seiten der Verbindung eine Rolle spielen.
Rufus Τ. F. schrieb: > Joachim D. schrieb: >> die Sockets sind auf >> max 65535 begrenzt > > Und das dürfte prinzipbedingt sein, und vor allem für alle Prozesse auf > dem System in Summe gelten. > Schließlich wird mit jedem Socket eine lokale Portnummer assoziiert, und > die wird mit einem uint16_t beschrieben. Achtung, Klugsch****er voraus! ;) uint16_t ist nicht der Grund für das Limit. Denn eine (TCP-) Verbindung wird durch das Tupel (lokale IP, lokaler Port, remote IP, remote Port) definiert. D.h. du kannst theoretisch weit mehr als 2^16 Verbindungen offen halten, solange sie nicht alle an die gleiche Gegenseite gerichtet sind.
tictactoe (Gast) schrieb: >Achtung, Klugsch****er voraus! ;) >uint16_t ist nicht der Grund für das Limit. Denn eine (TCP-) Verbindung >wird durch das Tupel (lokale IP, lokaler Port, remote IP, remote Port) >definiert. D.h. du kannst theoretisch weit mehr als 2^16 Verbindungen >offen halten, solange sie nicht alle an die gleiche Gegenseite gerichtet >sind. Pro IP-Adresse kannste 64k Ports nutzen, denn mehr paßt ja nicht in den IP-Header pro Richtungen (bei IPv4) Du kannst also bis zu 64k Serverports haben, oder bis zu 64k Clientports (dynamische Ports), oder irgendwas dazwischen. Zusammen eben nur 64k. Haste mehr als eine Adresse auf einem NIC (alte Abkürzung ;-), kannste entsprechend mehr Connections nutzen (theoretisch). Die Filehandles wären dann die nächste Grenze, je nach System.
Jens G. schrieb: > Du kannst also bis zu 64k Serverports haben, oder bis zu 64k Clientports > (dynamische Ports), oder irgendwas dazwischen. Zusammen eben nur 64k. Du kannst aber einen einzelnen Serverport mit praktisch beliebig vielen verschiedenen Client-IP-Adressen anderer Systeme verbinden lassen, so lange pro solcher IP-Adresse nicht mehr als 64k Verbindungen zusammen kommen. Ein effektives Limit stellt das also allenfalls dann dar, wenn beispielsweise ein gut belegtes CG-NAT System mit zentralen Services der Grössenordnung Googles in Spiel kommt.
:
Bearbeitet durch User
@ A. K. (prx) >Jens G. schrieb: >> Du kannst also bis zu 64k Serverports haben, oder bis zu 64k Clientports >> (dynamische Ports), oder irgendwas dazwischen. Zusammen eben nur 64k. >Du kannst aber einen einzelnen Serverport mit praktisch beliebig vielen >verschiedenen Client-IP-Adressen anderer Systeme verbinden lassen, so >lange pro solcher IP-Adresse nicht mehr als 64k Verbindungen zusammen >kommen. Stimmt - jetzt, wo Du es sagst ;-) Also limited by ressources ....
Jim M. schrieb: > Dann könnte eine zweistellige Anzahl Verbindungen gleichzeitig schon > kritisch sein. Mails werden normalerweise hintereinander verschickt. Zweifel! Der SMTP-Server ist eigene Software, Quelle der Mails ist ein Exchange-Server. Beide befinden sich innerhalb der Firma im selben Netzwerk. Der Ziel-SMTP ist down, auf dem Exchange haben sich 150 Mails gesammelt, die er nicht direkt loswerden konnte. Der Exchange-Server versucht nun zwei Tage lang mit zunehmend längeren Zeitintervallen, den Ziel-SMTP zu erreichen. Wenn ich den Ziel-SMTP hochfahre, kann ich beobachten, dass fast beliebig viele parallele Verbindungen aufgemacht werden. Ich habe nicht ermittelt, wie viele, auf jeden Fall deutlich zweistellig. Da das Zielsystem mit SMTP noch mehr zu tun hat und diese Flut nicht ertragen kann, haben wir eine Abweisung implementiert und lassen nur eine niedrig einstellige Anzahl gleichzeitiger Verbindungen zu. Hier wird das dann aber sehr kritisch, welchen Abweisunsgrund man schickt und wie das Quellsystem damit umgeht. Unabhängig davon: War da nicht vor Jahren mal ein XP-Sicherheitsupdate, was die Anzahl gleichzeitiger IP-Verbindungen einschränkt?
Manfred schrieb: > wird das dann aber sehr kritisch, welchen Abweisunsgrund man schickt und > wie das Quellsystem damit umgeht. Mail-Server wie Postfix können die Anzahl eingehender Verbindungen begrenzen. Sowohl insgesamt als auch pro Client als auch pro Zeiteinheit. In einem Server, der Spamassassin integriert und Spams gleich ablehnt, spielt der Ressourcenverbrauch des Spamassassin eine wesentliche Rolle, weshalb ich das entsprechend niedrig fahre, am üblichen Durchsatz orientiert. Deshalb kommt es gelegentlich vor, dass bei geballt eingehenden Verbindungen einige temporär abgelehnt werden. Es sind bisher keine Probleme in der Mailkommunikation aufgefallen, jenseits von ein paar Minuten Verzögerung.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.