Gleicher Port für Senden und Empfangen ?

[Mondlichtung]

Hallo liebe Community 🙂

Grundlegende Frage:
Angenommen man benutzt ein ServerSocket mit Port 555 zum Empfangen von Daten innerhalb eines Servers (z.B. in einer while(true) Schleife). Darf man dann, beispielsweise in einem anderen Thread, gleichzeitig ein Socket ebenfalls mit Port 555 öffnen, um Daten zu senden ?

Könnte es dann zu Komplikationen kommen oder dies eine legitime Vorgehensweise?

Dankeschön,
Mondlichtung

 

[eRaaaa]

Wozu sollte man das tun wollen? Probiers doch mal aus, dann wirst du sehen ob du einen neuen Socket mit dem gleichen Port aufmachen kannst. Oder du liest dich in das Thema nochmal ein 😀

 

[Mondlichtung]

Ausprobiert habe ich es noch nicht.
Der Nutzen liegt auf der Hand: Der Server muss nur einen Port benutzen für Senden und Empfangen.

Aus deiner Antwort schließe ich jedoch indirekt, dass Java dies wohl nicht zulässt. Und vermutlich einen Fehler wirft ?

 

[Gast2]

Java ist hier nicht das Problem. Du kannst einen Port nicht mehrfach verwenden, das lässt das Betriebssystem nicht zu.

 

[XHelp]

Das hat nichts mit Java zu tun, sondern mit Sockets an sich.
Den von dir genannten Nutzen kann ich allerdings nicht nachvollziehen. Eine Socketverbindung ist ohnehin bidirektional, also kannst du da sowohl senden als auch empfangen. Aber wozu eine 2. aufmachen ist mir rätselhaft: bei 65k Ports werden ja wohl noch ein paar frei sein. Außerdem brauchst du dich beim Client-Socket nur um den Server-Port zu kümmern.

Oooder du meinst es so:
Kann man sich zu einem ServerSocket, der auf Port 553 lauscht, mit mehreren ClinetSockets verbinden: Das kommt ganz darauf an wie du es implementiert hast, aber theoretisch: ja, das geht. Siehst du ja jedes mal wenn du

google.de

eintippst.

 

[Mondlichtung]

Java ist hier nicht das Problem. Du kannst einen Port nicht mehrfach verwenden, das lässt das Betriebssystem nicht zu.

Das würde ich gerne noch einmal genauer unterscheiden.
Ein Socket besteht ja im Wesentlichen aus dem Tupel (local IP, local port, remote IP, remote port).

Ich schätze es ist nicht möglich zweimal ein Objekt mit den gleichen Parametern zu benutzen. Also zweimal ein Objekt der Klasse Socket mit (1.1.1.1, 444, 2.2.2.2, 555).

Ist es jedoch möglich zwei Objekte der Klasse Socket mit den Parametern
(1.1.1.1, 444, 2.2.2.2, 555) und (1.1.1.1, 444, 2.2.2.2, 556) zu haben?
Hier würde ein Server z.B. zwei TCP Verbindungen mit zwei unterschiedlichen Programmen am host 2.2.2.2. betreiben. Ist das möglich?

 

[Mondlichtung]

Das hat nichts mit Java zu tun, sondern mit Sockets an sich.
Den von dir genannten Nutzen kann ich allerdings nicht nachvollziehen. Eine Socketverbindung ist ohnehin bidirektional, also kannst du da sowohl senden als auch empfangen. Aber wozu eine 2. aufmachen ist mir rätselhaft: bei 65k Ports werden ja wohl noch ein paar frei sein. Außerdem brauchst du dich beim Client-Socket nur um den Server-Port zu kümmern.

Oooder du meinst es so:
Kann man sich zu einem ServerSocket, der auf Port 553 lauscht, mit mehreren ClinetSockets verbinden: Das kommt ganz darauf an wie du es implementiert hast, aber theoretisch: ja, das geht. Siehst du ja jedes mal wenn du

google.de

eintippst.

Zweites ist das, was mich interessiert.
Einfaches Beispiel:

while (true) { 
  try { 
    Socket s = server.accept(); 
    new ConnectionHandler(s); 
  } catch (IOException e) { 
    e.printStackTrace(); 
  } 
}

Lauscht der Server z.B. auf 555 und wird ein Request akzeptiert. So hat das resultierende Socket s ja das Tupel (server ip, 555 (server port), remote ip, remote port).
Akzeptiert er kurz darauf erneut eine Anfrage (und läuft die 1. Anfrage in einem eigenen Thread im Hintergrund). Dann hat man, wenn ich es richtig verstehe, ein zweites Socket mit (server ip, 555 (server port), remote ip, remote port).
Ist das soweit korrekt und auch in der Praxis angewendet?

 

[XHelp]

Natürlich wird das in der Praxis angewendet, du selber machst davon täglich Gebrauch.

 

[Gast2]

Lauscht der Server z.B. auf 555 und wird ein Request akzeptiert. So hat das resultierende Socket s ja das Tupel (server ip, 555 (server port), remote ip, remote port).
Akzeptiert er kurz darauf erneut eine Anfrage (und läuft die 1. Anfrage in einem eigenen Thread im Hintergrund). Dann hat man, wenn ich es richtig verstehe, ein zweites Socket mit (server ip, 555 (server port), remote ip, remote port).
Ist das soweit korrekt und auch in der Praxis angewendet?

Der ServerSocket horcht immer auf Port 555. Wenn dann allerdings ne Verbindungsanfrage von nem Client kommt, wird nen anderer Port ausgehandelt, der dann für den Datenaustausch genutzt wird.
Ein Port kann nicht mehrfach benutzt werden!

Das lässt sich ganz einfach mal zeigen:
Der Server:

		ServerSocket ss = new ServerSocket(5555);

		while (true) {
			Socket s = ss.accept();
		}

Der Client:

		while (true) {
			Thread.sleep(1000);
			Socket s = new Socket("localhost", 5555);
			System.out.println(s.getLocalPort());
		}

Soviel sei verraten, es wird nicht 5555 ausgegeben 😉
Der Server hat also auf Port 5555 nen ServerSocket der auf Verbindungen wartet. Der komplette Datenaustausch zwischen Client und Server verläuft aber auf ganz anderen Ports (irgendwo weit oben).
Falls du Wireshark hast kannst du dir da auch mal nen kleinen Mitschnitt anschauen.

 

[irgendjemand]

@TO
ich verstehe weder deine fragen noch deine probleme

1) serversocket
wenn dein rechner *gleich ob java oder sonstwas* auf einem bestimmten port auf verbindungen wartet ist dieser gesperrt ...
du kannst also nie zwei serversockets auf dem selben port aufmachen ...

2) socket-accept
falsch
wenn dein serversocket eine verbindung annimmt so wird ein port ausgehandelt *weit oberhalb von 40k* und über diesen die kommunikation fortgesetzt ...
heißt also : der port auf dem server über den die verbindung mit dem client läuft ist NICHT gleich dem port des serversockets

3) socket-connect
wenn du einen serversocket auf einem port laufen hast hindert dich das doch nicht daran eine verbindung zu einem anderen rechner aufzubauen der den selben serversocket-port hat ...
wie gesagt : die eigentlichen ports über die die verbindung läuft liegen weit oberhalb von 40k ...

 

[t_fuchs005]

2) socket-accept
falsch
wenn dein serversocket eine verbindung annimmt so wird ein port ausgehandelt *weit oberhalb von 40k* und über diesen die kommunikation fortgesetzt ...
heißt also : der port auf dem server über den die verbindung mit dem client läuft ist NICHT gleich dem port des serversockets

Das stimmt so nicht... Der Server handelt seine Verbindung über den Port, auf dem er lauscht. Auf der Client-Seite wird eine Portnummer >= 1023 ausgewählt.
Falls mehrere Verbindungen auf den gleichen Server-Port bestehen (von einem Client), dann werden die Verbindungen anhand des Source-Port unterschieden.
Falls ein weiterer Client (zufällig) den gleichen Source-Port verwendet, wird die Verbindung anhand der unterschiedlichen IP-Adressen unterschieden.

 

[HoaX]

2) socket-accept
falsch
wenn dein serversocket eine verbindung annimmt so wird ein port ausgehandelt *weit oberhalb von 40k* und über diesen die kommunikation fortgesetzt ...
heißt also : der port auf dem server über den die verbindung mit dem client läuft ist NICHT gleich dem port des serversockets

3) socket-connect
wenn du einen serversocket auf einem port laufen hast hindert dich das doch nicht daran eine verbindung zu einem anderen rechner aufzubauen der den selben serversocket-port hat ...
wie gesagt : die eigentlichen ports über die die verbindung läuft liegen weit oberhalb von 40k ...

Nö, was du erzählst ist falsch. Der Client verbindet z.B. zu Port 80 bei Google.de. Und wenn der Server antwortet ist sein Quellport auch Port 80.
Der einzige Punkt an dem dynamisch ein Port gewählt wird ist auf der Clientseite, wenn dieser seinen Socket nicht explizit an einen lokalen Port bindet und dann eine Verbindung herstellt.

 

[tuxedo]

Kopfschüttel... :noe: Was hier so alles "erzählt" wird lässt es einem kalt den Rücken runterlaufen. :shock:

Zur Aussage "wenn dein serversocket eine verbindung annimmt so wird ein port ausgehandelt *weit oberhalb von 40k* und über diesen die kommunikation fortgesetzt ...":

:autsch: :autsch:
Dann würde Portforwarding nicht wirklich gut funktionieren und SIMON wäre nicht wirklch benutzbar über's Internet.

Kann HoaX und t_fuchs005 nur zustimmen. Der Serversocket-Port ist und bleibt gleich, und nur dieser wird benutzt und sollte in einer Firewall bzw. Portforwarding-Liste eingetragen werden... --> :rtfm:

- Alex

 

[Spamkiller]

So ich hab mich auch mal eingelesen.
Hier wird von vielen Leuten etwas gesagt und nichts ist 100% richtig.

@Mondlichtung:
Es ist wirklich wichtig, dass du dich vorher in das Thema einliest. 98% deines Problems löst du damit und merkst auch wahrscheinlich wo dein Denkfehler liegt.

Zweitens: Überleg genau was du tun willst. Bei dem folgenden Code stehen mir die Haare zu Berge:

while (true) { 
  try { 
    Socket s = server.accept(); 
    new ConnectionHandler(s);   //Was ist das? Du lässt die Instanz hier ins "Leere" laufen. 
  } catch (IOException e) { 
    e.printStackTrace(); 
  } 
}

Und das hier ist auch nicht richtig. Ich hab mich geschüttelt beim Lesen:

Kopfschüttel... :noe: Was hier so alles "erzählt" wird lässt es einem kalt den Rücken runterlaufen. :shock:

Zur Aussage "wenn dein serversocket eine verbindung annimmt so wird ein port ausgehandelt *weit oberhalb von 40k* und über diesen die kommunikation fortgesetzt ...":

:autsch: :autsch:
Dann würde Portforwarding nicht wirklich gut funktionieren und SIMON wäre nicht wirklch benutzbar über's Internet.

Kann HoaX und t_fuchs005 nur zustimmen. Der Serversocket-Port ist und bleibt gleich, und nur dieser wird benutzt und sollte in einer Firewall bzw. Portforwarding-Liste eingetragen werden... --> :rtfm:

- Alex

Hier stimmt zumindest 50%. Natürlich wird ein neuer Port ausgehandelt und zwar auf der Client-Seite. Der Server akzeptiert Verbindungen auf Port X. Den musst du Forwarden.
Der Client kommuniziert aber auf einem unbekannten Port der ausgehandelt wird wenn die Verbindung aufgebaut wird. Den musst du nicht forwarden und genau deshalb mach Portforwarding auch Sinn 🙂

 

[tuxedo]

@Spamkiller:

jetzt geht's hier die ganze Zeit um "Ports merfach verwenden" und um Serversockets. Und dann kommst du mit Client-Ports daher... 😱
Na klar werden die (in der Regel) vom Client beim Verbindungsaufbau mit dem Server vom OS gewählt.
Ich dachte nur - um die Sache nicht noch mehr zu verkomplizieren - bleib' ich mit meiner Erklärung beim bisherigen Thema (Port doppelt auf Serverseite) und weite es nicht noch weiter aus....

Aber wo wir gerade bei "mich Schüttelt's beim lesen" sind :shock:

Der Client-Port kann auch fest vorgegeben werden, womit er dann bekannt ist. Dann ist nix mit dynamischer Aushandlung. Nur sollte man das eher nicht tun und die Sache i.d.R. dem OS überlassen.

Summa sumarum: Ich hatte 100% recht. Nur bin ich bei den akuten 50% der Themengebiets geblieben und hab's nicht auf 100% ausgeweitet. Und letzten endes hattest du zu 50% recht 😀

Den musst du nicht forwarden und genau deshalb mach Portforwarding auch Sinn

Die Nicht-Notwendigkeit der Portweiterleitung des Clientports ist nicht der Grund für den Sinn des Portforwardins an sich --> :rtfm: --> Portweiterleitung ? Wikipedia

 

[HoaX]

Irgendwie drehen wir uns im Kreis...

 

[Spamkiller]

Um Gottes Willen, ich wollte mir hier auch nicht anmaßen alles 100% richtig zu machen.

Wenn du nochmal genau deinen Post liest, wirst du feststellen, dass du die ganze Sache auch nicht einfach halten wolltest. Du hast immerhin mit Port-Forwarding und Firewall angefangen.

Das Einzige was ich damit etwas nachdrücklicher sagen wollte ist der Punkt, dass man sich in eine solche Thematik besser einliest bevor man direkt anfängt zu codieren.

Dass du jetzt so beleidigt deswegen bist, war keine Absicht! 🙂

 

[tuxedo]

Seh ich aus als wäre ich beleidigt?

Um Gottes Willen, ich wollte mir hier auch nicht anmaßen alles 100% richtig zu machen.

Wie soll man das verstehen? Auf der einen Seite nicht alles 100% richtig machen wollen, auf der anderen Seite "behaupten" meine Aussage wäre nicht 100% richtig.... ???:L