Socket und Port, Verbindungen unterscheiden?



  • Unix-Tom schrieb:

    Falsch.
    Ein Server kann nur eine Verbindung gleichzeitig auf Port 80 annehmen.

    falsch.
    er kann theoretisch 2^48 verbindungen (anzahl aller möglichen ipv4-adressen * anzahl aller möglichen client-ports) gleichzeitig auf port 80 annehmen.
    🙂



  • Zitat WIKI

    http://de.wikipedia.org/wiki/Transmission_Control_Protocol

    Jede TCP-Verbindung wird eindeutig durch zwei Endpunkte identifiziert. Ein Endpunkt stellt ein geordnetes Paar dar, bestehend aus IP-Adresse und Port. Ein solches Paar bildet eine bi-direktionale Software-Schnittstelle und wird auch als Socket bezeichnet. Mit Hilfe der IP-Adressen werden die an der Verbindung beteiligten Rechner identifiziert; mit Hilfe der Ports werden dann auf den beiden beteiligten Rechnern die beiden miteinander kommunizierenden Programme identifiziert.

    Durch die Verwendung von Portnummern auf beiden Seiten der Verbindung ist es beispielsweise möglich, dass ein Webserver auf einem Port (normalerweise Port 80) gleichzeitig mehrere Verbindungen zu einem anderen Rechner geöffnet haben kann (Dienst, Server macht "listen" auf Port 80 und setzt bei "accept" für jeden Client die Verbindung auf anderem Port fort. Mehrmals "listen" auf dem gleichen Port ist nicht möglich -> "port in use". Client benutzt beliebige Portnummer).

    Hat auch nichts mit HTTP zu tun.
    Dies sind Grundlagen von TCP und Sockets.
    HTTP ist nur ein Protokoll welches auf TCP aufbaut.



  • fricky schrieb:

    Unix-Tom schrieb:

    Falsch.
    Ein Server kann nur eine Verbindung gleichzeitig auf Port 80 annehmen.

    falsch.
    er kann theoretisch 2^48 verbindungen (anzahl aller möglichen ipv4-adressen * anzahl aller möglichen client-ports) gleichzeitig auf port 80 annehmen.
    🙂

    Falsch.
    Ein Server kann maximal etwas weniger als 65535 Verbindung gleichzeitig halten.
    Mehr Ports gibt es nicht.
    Und es spielt keine Rolle wieviele IP-Adressen ihm zugewiesen wurden.
    Es gibt nur max. 65535 Ports auf einem Rechner egal wieviele IP-Adressen er noch hat.



  • Unix-Tom schrieb:

    fricky schrieb:

    Unix-Tom schrieb:

    Falsch.
    Ein Server kann nur eine Verbindung gleichzeitig auf Port 80 annehmen.

    falsch.
    er kann theoretisch 2^48 verbindungen (anzahl aller möglichen ipv4-adressen * anzahl aller möglichen client-ports) gleichzeitig auf port 80 annehmen.
    🙂

    Falsch.
    Ein Server kann maximal etwas weniger als 65535 Verbindung gleichzeitig halten.
    Mehr Ports gibt es nicht.
    Und es spielt keine Rolle wieviele IP-Adressen ihm zugewiesen wurden.
    Es gibt nur max. 65535 Ports auf einem Rechner egal wieviele IP-Adressen er noch hat.

    falsch!
    eine tcp-verbindung setzt sich zusammen aus lokaler ip-adresse und lokaler portnummer und remote ip-adresse und remote portnummer (4-tupel). d.h. ein server, welcher auf einer portnummer lauscht, kann (theoretisch, nicht alle kombinationen sind immer möglich) zu je 4294967296 clients 65536 verbindungen haben.
    🙂



  • Wenn ich einen Socket an eine lokale Adresse binde, wird mir das mit "Address already in use" bereits abgewiesen, wenn auf diesem Interface und diesem Port bereits ein offener Socket vorhanden ist. Komischerweise passiert dies bevor ich dem Netzwerkstack überhaupt mitteile, wie die Remote-Adresse lautet. Von daher kann an dieser Angabe irgendwas nicht stimmen...



  • Na egal. Glaube was Du möchtest.
    Vielleicht vesetzt dein Glaube mal Berge und Dein Rechner kann das.
    Könntest dann teuer an Ebay, und ähnliche verkaufen den die würden dadurch sehr sparen.
    Bräuchten dann nicht tausende Rechner um alle User bedienen zu können.



  • LordJaxom schrieb:

    Wenn ich einen Socket an eine lokale Adresse binde, wird mir das mit "Address already in use" bereits abgewiesen, wenn auf diesem Interface und diesem Port bereits ein offener Socket vorhanden ist. Komischerweise passiert dies bevor ich dem Netzwerkstack überhaupt mitteile, wie die Remote-Adresse lautet. Von daher kann an dieser Angabe irgendwas nicht stimmen...

    ja, das ist beim 'listen' so. wenn du zwei sockets auf dem gleichen port in den listen-modus schalten könntest, wüsste das socket-interface nicht, welchen davon es beim verbindungsversuch nehmen soll. aber wenn es einen gibt, der lauscht, dann können sich viele-viele rechner, und jeder davon 2^16 * simultan mit diesem port verbinden. natürlich nur rein theoretisch, weil durch rechen- und speicherkapazität grenzen gesetzt sind.
    🙂



  • fricky schrieb:

    ja, das ist beim 'listen' so. wenn du zwei sockets auf dem gleichen port in den listen-modus schalten könntest, wüsste das socket-interface nicht, welchen davon es beim verbindungsversuch nehmen soll. aber wenn es einen gibt, der lauscht, dann können sich viele-viele rechner, und jeder davon 2^16 * simultan mit diesem port verbinden. natürlich nur rein theoretisch, weil durch rechen- und speicherkapazität grenzen gesetzt sind.
    🙂

    Der Socket, den accept zurückliefert, hat aber als Localport nicht denjenigen, auf dem gehorcht wird, sondern einen freien Highport (nachzuprüfen mittels getsockaddr()). Es gibt nach mehreren Accepts nicht mehrere Sockets mit demselben Localport auf diesem Rechner.



  • LordJaxom schrieb:

    Der Socket, den accept zurückliefert, hat aber als Localport nicht denjenigen, auf dem gehorcht wird, sondern einen freien Highport (nachzuprüfen mittels getsockaddr()). Es gibt nach mehreren Accepts nicht mehrere Sockets mit demselben Localport auf diesem Rechner.

    getsockaddr() kenne ich nicht. meinst du getsockname()? kann es sein, dass die funktion dir die remote portnummer anzeigt? sockets sind übrigens keine 1:1 abbildung auf tcp-ports, sondern virtuelle verbindungsendpunkte. wenn dein server auf, sagen wir mal, port 1234 lauscht, dann ist deine lokale portnummer für alle verbindungen auf diesem port immer die 1234. (du kannst es z.b. mit wireshark nachprüfen) und natürlich wird für jedes 'accept' ein neuer socket generiert, da er eine neue verbindung darstellt. die anzahl dieser sockets kann übrigens über 65536 liegen, wenn verschiedene rechner sich auf deinen port verbinden (also nicht so, wie linux-tom meint).
    🙂



  • Ich schreibs nochmals:

    Listen wird auf einen Port gesetzt. Hier wird bei Aufruf schon definiert welche IP-Adresse diesem Port zugeordnet wird.

    Verbindet sich nun ein Client auf diesen Port wird Acccept aufgerufen und dem Socket ein freier HIGHPORT zugewiesen.
    Über diesem und dem Clientport findet die Kommunikation statt.
    Listen hört nun wieder auf dem Listenport.
    Es gibt also keine weiter kommunikation zw. dem Listenport und dem Clientport.
    Es ist auch nicht möglich z.B. dem Port 80 auf eine IP zu legen und den gleichen Port auf eine andere IP.
    Es gibt nur max. 65535 Port pro 32Bit-Rechner.
    Port sind 16-Bit-Zahlen und somit bis 65535 benutzbar.
    Mehrere IPADRESSEN erhöhen die Portanzahl nicht.
    Weiters gibt es auch noch Kernellimits dafür.
    Auf weitere Lernresistenz werde ich jetzt auch nicht mehr Antworten.
    Weiteres steht bei WIKIPEDIA.



  • Naja was ist denn nun genau richtig?
    Also ich hab folgenden Link gefunden: http://www.freesoft.org/CIE/Topics/20.htm
    Da wird auch gesagt, dass mehrere aktive Sockets auf einem Port laufen...



  • Außerdem hab ich eben noch folgendes bei der englischen Wikipedia gefunden:

    A server may create several concurrently established TCP sockets with the same local port number and local IP address, each mapped to its own server child-process and serving its own client process. These are treated as different sockets by the operating system, since the remote client address and/or socket numbers are different.

    Wenn ich das nicht falsch verstehe, kann ein Server mehrere Sockets an einem Port laufen haben, weil der die Verbindungen anhand der Clientadressen und -sockets unterscheiden kann.



  • Unix-Tom hat Unrecht.



  • Unix-Tom schrieb:

    Verbindet sich nun ein Client auf diesen Port wird Acccept aufgerufen und dem Socket ein freier HIGHPORT zugewiesen.

    nein, accept() wird von der anwendung aufgerufen und wartet (im normalfall) auf eine verbindung. sobald eine verbindung steht, liefert accept() einen socket zurück, über den die kommunikation stattfinden kann. aber... socket != port

    Unix-Tom schrieb:

    Über diesem und dem Clientport findet die Kommunikation statt.

    über diese client-socket!

    Unix-Tom schrieb:

    Listen hört nun wieder auf dem Listenport.

    listen hört die ganze zeit auf dem port.

    Unix-Tom schrieb:

    Es gibt also keine weiter kommunikation zw. dem Listenport und dem Clientport.

    es gibt keinen client-port. es gibt nur client sockets. die gleiche lokale portnummer kann sowohl vom server (listen/accept) als auch vom client (connect) auf dem gleichen rechner benutzt werden. wäre es nicht so, dann könntest du z.b. nicht mit einem rechner durchs internet surfen auf dem ein webserver läuft, denn dazu wird port 80 sowohl vom server als auch vom client benutzt.

    Unix-Tom schrieb:

    Es ist auch nicht möglich z.B. dem Port 80 auf eine IP zu legen und den gleichen Port auf eine andere IP.

    dass es mit der normalen socket-api möglich ist, kann ich jetzt nicht sagen. vom tcp-protokoll her ist es jedenfalls absolut möglich.

    Unix-Tom schrieb:

    Es gibt nur max. 65535 Port pro 32Bit-Rechner.

    totaler unfug! was haben diese beiden zahlen miteinander zu tun?

    Unix-Tom schrieb:

    Port sind 16-Bit-Zahlen und somit bis 65535 benutzbar.

    das ist die einzige, fast richtige behauptung, die du seit langem aufgestellt hast. theoretisch sind es 65536 portnummern. die portnummer 0 wird z.b. von manchen OS für spezielle zwecke verwendet, aber aus sicht des tcp-protokolls gibt es 65536 source- und 65536 destination-ports.

    Unix-Tom schrieb:

    Mehrere IPADRESSEN erhöhen die Portanzahl nicht.

    mehrere ip-adressen erhöhen die anzahl der möglichen verbindungen. es sind übrigens total abgefahrene konfigurationen möglich.

    Unix-Tom schrieb:

    Weiters gibt es auch noch Kernellimits dafür.

    du sagt mal was, das stimmt?! kompliment!

    Unix-Tom schrieb:

    Auf weitere Lernresistenz werde ich jetzt auch nicht mehr Antworten.

    aber ich! :p

    Unix-Tom schrieb:

    Weiteres steht bei WIKIPEDIA.

    lies lieber das: http://www.uic.rsu.ru/doc/inet/tcp_stevens/
    🙂



  • Unix-Tom schrieb:

    Na egal. Glaube was Du möchtest.
    Vielleicht vesetzt dein Glaube mal Berge und Dein Rechner kann das.
    Könntest dann teuer an Ebay, und ähnliche verkaufen den die würden dadurch sehr sparen.
    Bräuchten dann nicht tausende Rechner um alle User bedienen zu können.

    Du hast einfach keinen Plan. Verbindung ist identifiziert durch die 4 Kennzeichen ClientPort,ServerPort,ClientIP,ServerIP. Damit kannst
    Du auf einem Server viele Verbindungen zu Port 80 haben. Um im Ernst,
    wenn es an der Zahl der Ports läge, wieviele Verbindungen ein Rechner kann,
    wäre es da nicht einfacher, die Max. Anzahl zu erhöhen statt neue
    Rechner zu kaufen? Logisches Denken ist nicht deine Stärke...

    Also, halten wir fest

    1 Socket -> Eine Verbindung (Client Port, Client IP, Server IP, Server Port)

    Das mit dem Listen/Connectsocket hat eben genau den Grund, dass Du einen neuen
    Socket brauchst (für multithreadserver), wenn einer mit einer
    Verbdindung belegt ist. BEIDE sitzer aber nach wie vor auf dem
    selben Port.

    Du hast das FTP Vorgehen beschrieben, welches sowieso
    eher "braindead" ist.

    Gruss
    S



  • Ich habe nie behauptet das nur ein Client gleichzeitig auf Port 80 verbinden kann.
    Verbindet sich ein Client auf Port 80 des Servers bekommt diese Verbindung auf Serverseite eine Highport zugewiesen. Weitere Kommunikation dann von Serverseite über den Highport.
    Dieser Highport ist dann auf dieser IP belegt. Somit ein User Pro Port auf einer IP.



  • Unix-Tom schrieb:

    Ich habe nie behauptet das nur ein Client gleichzeitig auf Port 80 verbinden kann.

    Doch. Lies deine Posts.

    Unix-Tom schrieb:

    Verbindet sich ein Client auf Port 80 des Servers bekommt diese Verbindung auf Serverseite eine Highport zugewiesen. Weitere Kommunikation dann von Serverseite über den Highport.

    1. Wiederspruch zu deiner ersten Aussage. Aber egal, da:
    2. FALSCH. Wird auch nicht dadurch richtig, dass Du es
      ständig wiederholst. Du beschreibst das FTP Protokoll.
    3. Bevor Du antwortest, lies ein Fachbuch oder lass es Dir von
      jemanden erklären, der sich auskennt.
    4. Siehe 3.
    5. Siehe 3.
    6. Wenn Du immer noch auf deiner Meinung beharrst, dann ändere
      wenigstens deinen Nick, damit hier keiner denkt Du kennst Dich damit
      aus...

    Gruss
    S



  • Severentwickler schrieb:

    Du beschreibst das FTP Protokoll.

    ja, hähähä, den 'passive mode'.

    Unix-Tom: ich denke du hast mal mit sockets rumgespielt und aus deren verhalten völlig falsche schlüsse gezogen. lies doch mal 'tcp/ip illustrated' und rfc 793 und schau die die kommunikation mit 'wireshark' an, damit du nicht mehr solchen blödsinn von dir geben musst.
    🙂



  • fricky schrieb:

    Severentwickler schrieb:

    Du beschreibst das FTP Protokoll.

    ja, hähähä, den 'passive mode'.

    Unix-Tom: ich denke du hast mal mit sockets rumgespielt und aus deren verhalten völlig falsche schlüsse gezogen. lies doch mal 'tcp/ip illustrated' und rfc 793 und schau die die kommunikation mit 'wireshark' an, damit du nicht mehr solchen blödsinn von dir geben musst.
    🙂

    Ja, der Stevens sollte Pflichtlektüre werden... Ansonsten stimme ich
    Frickys Analyse zu.



  • Im Zuge dessen muss ich mich selbst auch korrigieren, getsockname liefert - nicht wie ich angenommen hatte - denselben Port für den Listen-Socket wie für den verbundenen (akzeptierten) Remote-Socket.


Anmelden zum Antworten