Kleine Socket Frage / Maximale offenen Verbindungen
-
Guten Abend,
nur eine kleine Frage.
Ich möchte eine Client/ Server Applikation programmieren. Ich beschreibe einfach mal aus Server Sicht was das Ziel ist. Beim Server soll ähnlich wie bei ICQ, eine Online Liste erstellt werden, wenn sich ein Client anmeldet, soll der Computer Name angezeigt werden, geht dieser offline, soll er aus der Liste genommen werden, soweit so gut. Ich möchte aber vom Server die Anweisung schicken können, das mir ein spezieller Client Daten/ Informationen übermittelt, dafür müsste die Client/ Server Verbindung ja ständig bestehen, da der Server in dem Fall ja nicht mehr die Informationen vom Client anforden kann. Sehe ich das richtig, wenn ja, wie viele offenen Verbindungen sind möglich?Vielen Dank für eure Hilfe
-
ja, dazu sollte es eine ständige verbindung geben, da der neuaufbau bedingt durch firewalls/... vom server zum client eher schwer ist ;o)
verbindungen: kommt aufs system an, da wirds vrmtl irgendwo in den tiefen der api ne konstante geben - die aber fürs gesamte system gilt - sollte dich aber nicht stören, da wohl mehr als paar Dutzend für dich abfallen^^
bb
-
Soweit ich die MSDN richtig interpretiert habe, gibt es nur mit 1.1 Sockets ein "Limit", ab Winsock 2.0 kann man erstellen was man möchte.
-
Es gibt bei TCP 65536 Ports, spätestens da ist also Schluss.
-
stfu1337 schrieb:
Sehe ich das richtig
Eu das riechst schon wieder verdächtig nach jemandem der ne Backdoor/ein Bot-Netz/... programmieren will.
Grundsätzlich: ja, da der Server normalerweise nicht zum Client connecten kann, muss der Client eine Verbindung aufbauen, und diese Verbindung muss natürlich zu dem Zeitpunkt bestehen, wo der Server dem Client irgendwas mitteilen möchte.
Ob der Client dazu die Verbindung permanent aufrecht erhält, oder z.B. alle paar Minuten/Stunden mal nachfragt, ist egal. Das kommt darauf an wie lang die maximale Verzögerung sein darf.wenn ja, wie viele offenen Verbindungen sind möglich?
Der erste limitierende Faktor ist normalerweise dein Router (DSL-Router, HSDPA-Router, ...), vorausgesetzt dein PC soll Server spielen. Wenn ich mich recht erinnere schaffen die meisten keine 1000 gleichzeitigen Verbindungen. Wenn der Server hinter einem "ausgewachsenen" Router steht, oder sich alles im LAN abspielt, fällt der Faktor natürlich weg. Ansonsten muss ein besserer Router her, und der kostet gleich mal ein paar Hundert €. (Der DFL-210 von D-Link schafft z.B. 12000 gleichzeitige Verbindungen -- kostet knapp über 200€ + etliche Stunden Einarbeitungszeit + ca. 300-400 graue Haare)
Der nächste limitierende Faktor ist die Ephemeral Port Range. Diese ist unter Windows (vor Windows Vista) per default nicht sehr gross (< 4000 Ports). Inwieweit man das mit SO_REUSEADDR "umgehen" kann weiss ich nicht (keine Ahnung ob SO_REUSEADDR für eingehende Verbindungen funktioniert). Ansonsten kann man die Ephemeral Port Range über die Registry vergrössern (MaxUserPort).
http://www.ncftp.com/ncftpd/doc/misc/ephemeral_ports.html#Windows
-
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?
