staging.inyokaproject.org

Wenn man eine Client-Server Anwendung programmiert, gibt es da eigentlich irgendwelche Anhaltspunkte dazu, welche Ports man dafür verwenden sollte/darf?

In meinem aktuellen Projekt geht es darum, im Netzwerk außer Video Dateien auch die zugehörigen Vorschau Dateien (incl. Metadaten) zu kopieren. Nachdem ich den Server (hoffentlich) IP6 fähig gemacht habe, frage ich mich jetzt, ob ich die Portnummer einfach so auswürfeln kann, oder ob es da irgendwelche Richtlinien gibt. Momentan verwende ich den Port 8081. Ich vermute aber, das der auch von mindestens tausend anderen Hobby-Programmieren verwendet wird.

Hallo!

Du solltest gar keinen festen Port nutzen, sondern den konfigurierbar machen. Welche du vermeiden solltest, kannst du bspw. unter https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers finden.

Generell Ports > 1024, da du für kleinere Rootrechte brauchst. Gegen 8081 spricht aber nichts, solange es konfigurierbar bleibt.

Auf der Client Seite war das seit der Netzwerk Funktionalität schon immer einstellbar. Das ergab sich daraus, das ja auch die Serveradresse einstellbar sein muss.

Auf der Server-Seite ist dies seit heute einstellbar. Ich habe gerade das Server Modul ausgetauscht (neues Lehrbuch). Den Port 8081 hatte ich erst mal gewählt, weil ich mich bei der Kommunikation an HTTP orientiert hatte und dort für lokale Zwecke oft der Port 8080 gewählt wird. Da habe ich dann einfach eins drauf gesetzt, ohne viel darüber nachzudenken.

Das ist jetzt aber nur die hart codierte "default" Einstellung. In der Config-Datei des Clients taucht das noch nicht auf (der Server hat noch keine, geht nur über die Kommandozeile).

Naja, wenn du dir die anderen Projekte anguckst, kannst du überall den Port ändern. SSH, Minidlna, Webserver,… Gerade weil es ja Gründe geben kann Dienste auch mehrfach laufen zu lassen. Der Klient muss natürlich dann den korrekten Port kennen oder über einen Proxy entsprechend weitergeleitet werden (Hauptserver lauscht auf Standardport, wertet die Anfrage aus und leitet sie bei Bedarf an den entsprechenden Zweit-/Drittserver weiter).

Du kannst dir natürlich im lokalen Netz einfach einen Port reservieren und den festlegen. Die 8080er-Reihe würde ich aber nicht nehmen, da da wirklich oftmals die Webserver-Dienste aufnummeriert laufen. Ich hab gern 9300-9400 genommen (die alten Archiv/Spiele/Neverwinter Nights-Ports 😉 )

Dakuan schrieb:

[…] Portnummer […] auswürfeln kann, oder ob es da irgendwelche Richtlinien gibt

Du kannst die Registrierungsstelle bei der IANA befragen:

Service Name and Transport Protocol Port Number Registry

Beachte, dass es nach der ersten angezeigten Seite noch 144 Folgeseiten gibt. Die Seite hat aber auch eine Suchfunktion und man kann sich die Information auch als CSV herunter holen.

Du solltest gar keinen festen Port nutzen, sondern den konfigurierbar machen.

Mache ich doch jetzt. Allerdings hat der Server keine Konfigurationsdatei, daher möchte ich einen Standardwert einsetzen. Der Server wird vom Benutzer auch nur bei Bedarf gestartet. Wenn der Port nicht frei ist, kommt eine Fehlermeldung und der Server beendet sich sofort.

Die 8080er-Reihe würde ich aber nicht nehmen, da da wirklich oftmals die Webserver-Dienste aufnummeriert laufen.

Im Prinzip mache ich ja ansatzweise HTTP (nur GET requests). Zeitweise hatte ich Dillo als Client eingesetzt. Zurück kommt allerdings nur text/plain oder Binärdateien.

Aber die 9300-er Gruppe ist vielleicht besser geeignet.

In erster Näherung solltest Du auf jeden Fall Ports aus /etc/services vermeiden. Desweiteren kann nur root Ports bis 1000 aufmachen, wenn ich mich richtig erinnere - also lieber ein Port über 1000 auswählen.

Mit CAP_NET_BIND_SERVICE kann ein non-root Dienst auch Ports kleiner 1024 nehmen, ratsam ist das trotzdem nicht.

Also auf Ports < 1024 (z.B. 80) wollte ich nicht zugreifen. So tief wollte ich nicht in die Trickkiste greifen. Wobei, das hätte schon etwas. Es scheint mir unwahrscheinlich, das auf einem normalen Aarbeits-PC auch ein HTTP Server läuft. Und der Server muss vom Benutzer gestartet werden (root will man ja nicht).

Aber ich kann den Benutzer natürlich dazu zwingen selber einen Port anzugeben und ansonsten die Ausführung verweigern. Aber damit gewinne ich sicherlich auch keine Freunde.

Default Port 8080, Rest konfigurierbar. Du machst dir zu viele Gedanken, wenn die Anwendung in einem Container läuft ist es eh egal.

Du machst dir zu viele Gedanken ...

Das Gegenteil war aber auch schon der Fall.

... wenn die Anwendung in einem Container läuft ist es eh egal.

Aber warum sollte man eine 36 kB "große" Anwendung in einen Container packen?

Dakuan schrieb:

Aber warum sollte man eine 36 kB "große" Anwendung in einen Container packen?

Weil die 36kB große Anwendung von Libraries und anderem abhängt. Einen Container bekommst du überall ans laufen wo eine OCI taugliche Container Runtime existiert, das kann im Zweifel auch systemd-nspawn sein oder die normale Docker Engine / Podman. Als Beispiel hat Ubuntu und Redhat oft ander libc Versionen im Einsatz, die nicht ABI kompatibel sind, gleichzeitig ist auch der Rest des Systems (OpenSSL z.B.) in einem ganz anderem Zustand.

Einen Container bekommst du überall ans laufen ...

Bisher konnte ich die meisten meiner kleinen Anwendungen, die ich dann auf dem ältesten noch im Gebrauch befindlichen PC erstellt hatte, per USB Stick auf anderen PCs zum laufen bringen. Wenn ich wirklich darauf angewiesen wäre, würde ich lieber auf ein Livesystem zurückgreifen.

Aber die Frage, in welcher Form ich die Programmsammlung veröffentlichen könnte, stellt sich im Moment nicht.