Kleine Socket Frage / Maximale offenen Verbindungen
-
Nanyuki schrieb:
Es gibt bei TCP 65536 Ports, spätestens da ist also Schluss.
Nicht unbedingt.
Wenn er es schafft dem System abzuringen dass lokale Adressen wiederverwendet werden, dann ist selbst da nicht Schluss. Genau dazu ist die SO_REUSEADDR Option da, bloss wie ich schon geschrieben habe bin ich mir nicht 100% sicher ob es unter Windows hinhaut wenn die Verbindungen angenommen werden sollen.
Und wie ich auch schon geschrieben habe: da kommen schon viel früher andere limitierende Faktoren ins Spiel.
-
Dieser Thread wurde von Moderator/in pumuckl aus dem Forum C++ in das Forum Rund um die Programmierung verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Nanyuki schrieb:
Es gibt bei TCP 65536 Ports, spätestens da ist also Schluss.
naja, z.b. bei immer dem gleichen port und verschiedenen portnummern nur eines anderen rechners oder netzwerk-interfaces. ansonsten ist die rein protokollbedingte beschränkung 2^16 * 2^32 - 1 verbindungen (von einem lokalen port zu allen anderen adressen/ports im ip-adressraum). bzw. von allen lokalen ports zu allen rechnern/ports 2^16 * (2^32 - 1) * 2^16.
-
hustbaer schrieb:
Wenn er es schafft dem System abzuringen dass lokale Adressen wiederverwendet werden, dann ist selbst da nicht Schluss. Genau dazu ist die SO_REUSEADDR Option da
bezogen auf TCP ist ein socket ein '4-tupel' (lokaler port/lokale ip-adresse/anderer port/andere ip-adresse). SO_REAUSEADDR kann das nicht umgehen, sondern ist dazu da, bestehende sockets schnell wiederzuverwenden, deren verbindung soeben geschlossen wurde (also den TIME-WAIT state abzubrechen).
-
wenn es dir auf maximale verbindungen ankommt, kannst du mit sendto/recvfrom via udp soviele verbindungen verwalten wie es der speicher deines rechners zulaesst. wenn du z.b. 4byte pro "client" hast, bei 4GB ram, kannst du mehr als ne Mrd clients haben, sollte doch reichen, oder?
-
;fricky schrieb:
hustbaer schrieb:
Wenn er es schafft dem System abzuringen dass lokale Adressen wiederverwendet werden, dann ist selbst da nicht Schluss. Genau dazu ist die SO_REUSEADDR Option da
bezogen auf TCP ist ein socket ein '4-tupel' (lokaler port/lokale ip-adresse/anderer port/andere ip-adresse). SO_REAUSEADDR kann das nicht umgehen, sondern ist dazu da, bestehende sockets schnell wiederzuverwenden, deren verbindung soeben geschlossen wurde (also den TIME-WAIT state abzubrechen).
Nein fricky. Der TCP/IP Standard sagt vielleicht dass es so sein sollte, aber es ist halt nicht so. Nicht unter Windows.
Unter Windows kannst du mit SO_REAUSEADDR z.B. zwei Ports auf die selbe lokale Adresse binden. Das sollte nicht gehen, geht aber trotzdem.
Und wenn ich mich recht erinnere, vergibt Windows für ephemeral Ports Adressen nicht doppelt, auch wenn es das dürfte.
-
sendto/recvfrom via udp soviele verbindungen
UDP kennt keine Verbindungen und nützt nur etwas wenn der Server zum Client senden kann. Dann bräuchte man aber auch mit TCP keine stehen Verbindung.
-
hustbaer schrieb:
Der TCP/IP Standard sagt vielleicht dass es so sein sollte, aber es ist halt nicht so. Nicht unter Windows.
Unter Windows kannst du mit SO_REAUSEADDR z.B. zwei Ports auf die selbe lokale Adresse binden. Das sollte nicht gehen, geht aber trotzdem.ok, da kocht ms wieder sein eigenes süppchen oder hat was missverstanden. diese option scheint unter windosen nur für multicast sinnvoll zu sein, ansonsten kann man auf anderen verbindungen mitlauschen, bzw. von dort daten abzwacken.
--> http://msdn.microsoft.com/en-us/library/ms740621(VS.85).aspx
witzigerweise:No special privileges are required to use this option
d.h. jeder gastprozess könnte admin- und systemprozesse beeinflussen, nicht schlecht *fg*
-
hustbaer schrieb:
Und wenn ich mich recht erinnere, vergibt Windows für ephemeral Ports Adressen nicht doppelt, auch wenn es das dürfte.
das würde auch so nicht gehen. die kombination aus ip adresse und portnummer muss für jeden 'endpoint' eindeutig sein.
-
;fricky schrieb:
das würde auch so nicht gehen. die kombination aus ip adresse und portnummer muss für jeden 'endpoint' eindeutig sein.
Sagt wer?
Es würde doch reichen, daß pro Connection die Kombination aus beiden Adressen und beiden Ports, also die Kombination aller vier Zahlen eindeutig sein muß.
-
und das kann auch noch dazu kommen http://www.nwlab.net/art/event-4226.html
-
wersagwas schrieb:
und das kann auch noch dazu kommen http://www.nwlab.net/art/event-4226.html
Für Server total uninteressant, da Server keine ausgehenden Verbindungen machen.
Für Clients verzögert es nur alles ein Wenig.
-
;fricky schrieb:
hustbaer schrieb:
Und wenn ich mich recht erinnere, vergibt Windows für ephemeral Ports Adressen nicht doppelt, auch wenn es das dürfte.
das würde auch so nicht gehen. die kombination aus ip adresse und portnummer muss für jeden 'endpoint' eindeutig sein.
Das ist Definitionssache.
Wer sagt das jede Connection ihren eigenen lokalen "Endpoint" haben muss?Es kann mehr Connections als lokale Ports * lokale IPs geben, das ist Fakt. Alles andere ist bloss eine Frage der Nomenklatur.
-
volkard schrieb:
;fricky schrieb:
das würde auch so nicht gehen. die kombination aus ip adresse und portnummer muss für jeden 'endpoint' eindeutig sein.
Es würde doch reichen, daß pro Connection die Kombination aus beiden Adressen und beiden Ports, also die Kombination aller vier Zahlen eindeutig sein muß.
ist ja auch so, aber aus einer richtung betrachtet (der richtung des senders) müssen ip_adresse und portnummer eindeutig sein, damit die nachricht auch da ankommt, wo sie soll. und weil tcp bidirektional arbeitet, trifft das auch für die gegenrichtung zu.
hustbaer schrieb:
Es kann mehr Connections als lokale Ports * lokale IPs geben, das ist Fakt.
ja, natürlich, nämlich pro netzwerk-interface (vorausgesetzt es hat eine eindeutige ip-adresse, was in sonderfällen auch nicht immer zutrifft) theoretisch 216*232*2^16 = 2^64 gleichzeitige verbindungen.
-
@;fricky:
und was soll dann dein üblich-hirnfreier einwurf?
-
wersagwas schrieb:
und das kann auch noch dazu kommen http://www.nwlab.net/art/event-4226.html
'ne halboffene verbindung ist aber, nach rfc793, anders defininert. das ist eigentlich ein verindungsabbruch, von dem ein teilnehmer nix mitbekommt.
hustbaer schrieb:
@;fricky:
und was soll dann dein üblich-hirnfreier einwurf?der vollständigkeit halber und damit z.b. du auch mal mitkriegst, um was es geht, mein asthmatisches kuschelbärchen.
-
;fricky schrieb:
hustbaer schrieb:
@;fricky:
und was soll dann dein üblich-hirnfreier einwurf?der vollständigkeit halber und damit z.b. du auch mal mitkriegst, um was es geht, mein asthmatisches kuschelbärchen.
aber wie soll es mir helfen wenn du unsinn postest?
-
hustbaer schrieb:
aber wie soll es mir helfen wenn du unsinn postest?
wenn du mir z.b. erzählen würdest, welches deiner postings ich falsch verstanden, bzw. wo ich zuviel hineininterpretiert habe.
-
nein
-
hustbaer schrieb:
nein
ok - ich hab sowieso nicht damit gerechnet.
