Das deutsche Python-Forum

client.py server.py Das ist ein einfaches Chatprogramm. Hab's über's Internet gestestet, allerdings hat der Computer, der server.py ausführen sollte, nichts empfangen. Beim dreimaligen Versuchen nicht. Könnte es daran liegen, dass UDPund nicht TCP genutzt wird, oder funktioniert das Programm über das I-Net nicht?

Hast du daran gedacht, in dem Netzwerk, in dem 'server.py' gestartet wird, an allen Stellen, die zwischen dem Rechner und dem Internet liegen (z.B. Router), entsprechende Freigaben und Weiterleitungen einzurichten?

Nein. Um ehrlich zu sein, verstehe ich nicht mal so wirklich was damit gemeint ist.
Die Nachricht des Clients wird ja, wenn ich die öffentliche IP des Zielrechners eingebe, zum Zielrechner geschickt. Über den Port 50000 wird dann die Nachricht zum Programm geschickt, dass diesen Port anzapft. So habe ich das verstanden.

@Dexter1997: wie sind denn Deine Rechner miteinander Verbunden?

In Privathaushalten steht heute ja meistens ein DSL-Router, der mit dem Internet verbunden ist und sozusagen als Vermittler zwischen dem lokalen Netzwerk und dem Internet dient. Die öffentliche IP ist die des Routers. Geräte im Netzwerk haben lokale IPs. Netzwerktraffic von außen wird vom Router an diese lokalen Adressen weitergeleitet (NAT). Damit das in dem Fall funktioniert, musst du im Router eine UDP Weiterleitung von Port 50000 auf die lokale IP des Rechners, auf dem der Server läuft, einrichten.

Verstehe.
Gibt es da noch einen einfacheren Weg? Andere Chatprogramme verlangen ja auch nicht, dass da erst irgendwas umständliches im Router eingerichtet wird, bevor man chatten kann.

Grundsätzlich löst man dass indem man keine direkte Verbindung aufbaut, sondern über einen Server kommuniziert zu dem sich alle verbinden.

@Dexter1997: Ergänzend zu dem, was DasIch meinte:
In Messengern (früher) waren genau diese Portfreigaben oft das Problem, warum das Verschicken von Dateien nicht geklappt hat. Während die reguläre Chatkommunikation über Server lief, wurde für Dateitransfer eine Direktverbindung aufgebaut. Ich fürchte, die Portfreigaben bleiben dir nicht erspart.

Aber der Server muss ja letzenendes auch wieder eine direkte Verbindung zum Rechner aufbauen, um ihm die Nachricht zu schicken. Anders funktioniert das ja nicht :/

Und dann gibt es da noch eine Sache, die ich nicht verstehe. Das Thema Netzwerke ist auf den ersten Blick ziemlich verwirrend, habe ich den Eindruck.

Es gibt ja die sogenannten Sockets. Ein Programm, dass Daten mit anderen Programmen austauschen will (egal ob beide Programme auf demselben Rechner sind oder nicht), braucht einen Socket.
Das heißt, Programme kommunizieren über Sockets, Wobei also jeweils Client und Server einen Socket haben, wenn ich das richtig verstanden habe.
Dann ist aber noch von sogenannten Ports die Rede. Ports ermöglichen die Zuordnung von Netzwerkverbindungen zu Programmen durch Betriebssysteme. Klingt so, als wäre das dasselbe wie ein Socket. Was ist der Unterschied zwischen einem Socket und einem Port?
Gibt es vielleicht eine gute Einleitung in das Thema Netzwerke? In meinem Buch über Python, in dem es gerade um Netzwerke geht, habe ich das Gefühl, dass das Thema für Neulinge eher oberflächlich erklärt wird.

Hallo,

@Dexter1997: Das ganze kann noch viiiiiiel komplizierter sein - du kratzt gerade mal an der Oberfläche.

Port und Socket sind nicht das gleiche. Bei Wikipedia. Zitat: "Primär sind Ports ein Merkmal zur Unterscheidung mehrerer Verbindungen zwischen demselben Paar von Endpunkten."

Dein Rechner hat eine IP-Adresse, diese kann 65535 verschiedene Ports für verschiedene Verbindungen / Protokoll benutzen. So nutzt z.B. HTTP standardmäßig Port 80, HTTPS 443, IMAPS 993, SSH 22 usw. Gäb's da nicht, wäre eine gleichzeitige Verbindung nicht möglich.

Ein Programm, dass Daten mit anderen Programmen austauschen will (egal ob beide Programme auf demselben Rechner sind oder nicht), braucht einen Socket.

Nee, das geht auch anders. Socketprogrammierung ist eher so der unterste Level, mit dem man das macht. Was willst du denn für Daten austauschen?

In meinem Buch über Python, in dem es gerade um Netzwerke geht,

Welches Buch nutzt du?

Gruß, noisefloor

https://www.amazon.de/Python-umfassende ... n+handbuch

Das ist das Buch, dass ich nutze.
Ein bisschen Erfahrung in Python habe ich bereits, das meiste kann ich durch querlesen in verschiedenen Quellen. Folgendes Beispiel zeigt ungefähr meinen Wissensstand (habe ich gemacht):

https://codereview.stackexchange.com/qu ... wise-words

Ich denke, dass ich bereit bin, Python nicht chronologisch lernen zu müssen und bin in diesem Buch direkt in die Netzwerkprogrammierung eingestiegen, ohne großartig was anderes vorher zu lesen. Ich schätze also, mangelnde Programmierkenntnisse sollten nicht das Problem sein, eher mein schlechter Wissensstand über Netzwerke.

Hallo,

bleibt immer noch die Frage, welche Daten du übertragen willst.

Gruß, noisefloor

Dexter1997 hat geschrieben:Dann ist aber noch von sogenannten Ports die Rede. Ports ermöglichen die Zuordnung von Netzwerkverbindungen zu Programmen durch Betriebssysteme. Klingt so, als wäre das dasselbe wie ein Socket. Was ist der Unterschied zwischen einem Socket und einem Port?

Vielleicht hilft Dir eine (wie so oft hinkende) Analogie: Stell Dir eine Stadt mit vielen Häusern vor. Jedes Haus hat eine eigene Adresse; das ist die IP. In jedem Haus gibt es eine Vielzahl von Dienstleistungen (Bäcker, Schuster, etc. -> Apache, Nginx, Datenbank, usw.). Diese erreichst Du durch eine für jeden Dienst eigens numerierte Tür; das ist der Port. Hinter jeder Tür steht aber zunächst einmal der Butler; das ist der Socket - dieser empfängt Dich (die Daten); und er achtet auf das Protokoll. Benimmst Du Dich daneben (falsches Protokoll), dann bekommst Du Schwierigkeiten. Vor den Häusern mit den Türen gibt es aber außerdem - wie bei Clubs - noch die Rausschmeißer. Die lassen Dich unter Umständen erst gar nicht durch, selbst wenn die Türen offen sind; das sind Firewalls.

Zur Frage, welche Daten ich übertragen will:
So, wie ich das verstanden habe, überträgt UDP einfach Byte-Objekte. Byte-Objekte können, wenn ich das richtig verstanden habe, alles mögliche sein: Filme, Bilder, Textnachrichten usw. sie müssen nur mit der Funktion encode() zu Byte-Objekten gemacht werden (warum auch immer, denn streng genommen sind die besagten Dinge ja sowieso schon "Objekte", die aus "Bytes" bestehen, sowie alles in der Software-Welt.

Also kurz und knapp: Ich möchte per UDP Byte-Objekte übertragen.

Zur Analogie:
Sind die Butler in deiner Analogie die Sockets?

Hallo,

@Dexter1997: das ist aber sehr vage... warum nennst du nicht deinen konkreten use-case? Wie du richtig sagst, Byte-Objekte können alles sein. Und du bist mit Sicherheit nicht heute morgen aufgewacht und hast gedacht: "Heute ist mir mal danach, Byte-Objekte zu übertragen".

Dir ist auch klar, dass du bei UDP keine Garantie hast, dass die Daten jemals ankommen?

Gruß, noisefloor

Die Sache ist die, dass ich keinen konkreten "use-case" habe. Ich habe das Programm nur zum Üben benutzt. Konkreter ausgedrückt wollte ich in diesem Zeichenketten, also Textnachrichten übertragen, die der Empfänger lesen kann. Das hatte innerhabl des lokalen Netzwerkes gut funktioniert.

Mir ist klar, dass die per UDP übertragenen Daten nicht ankommen könnten. Aber dieses Risiko habe ich mal in Kauf genommen, da ich den Umgang mit
TCP erst noch erlerne

@Dexter1997: Du weißt nicht, wie man UDP benutzt, denkst aber dass Du es besser beherrschst als TCP? Du findest im Internet und in den meisten Büchern, die nicht explizit Netzwerkprotokolle behandeln, zu 99.99% nur fehlerhafte Beispiele. Weder TCP noch UDP werden meist korrekt umgesetzt. Daher will man ja auch höhere Protokolle einsetzen, zu allervorderst HTTP, weil man damit durch fast alle Firewalls durchkommt.

Nunja, sagen wir es genauer: Ich weiß, wie ich ein Python-Programm dazu bringe, eine UDP-Verbindung zu einem anderen Programm aufzubauen. Sonst hätte ich ja die gezeigten Programme nicht schreiben können.
Ich erlerne den Umgang mit UDP und TCP, nicht, wie sie im Einzelnen funktionieren. Ich denke, das reicht für einen Anwendungsprogrammierer auch aus.
HTTP kann meines Wissens allerdings nur Textdateien übertragen, wobei meistens nur HTML-Dateien übertragen werden.
Hättest du vielleicht ein Beispiel parat, wie man so ein Chatprogramm, wie ich es geschrieben habe, mit der Nutzung des HTTP-Protokolls realisiert?
Das wäre sehr interessant für mich.

Dexter1997 hat geschrieben:Ich erlerne den Umgang mit UDP und TCP, nicht, wie sie im Einzelnen funktionieren. Ich denke, das reicht für einen Anwendungsprogrammierer auch aus.

Du weißt, dass dein o.g. Problem erstmal nichts mit UDP / TCP zu tun hat? Letzteres sind Protokolle, die je nach Anwendungsart eingesetzt werden. UDP i.d.R. für Echtzeitanwendungen z.B. Internettelefonie / VoIP - hier ist wurst ob einzelne Frames flöten gehen, die Übertragung muss besonders verzögerungsfrei sein. Bei TCP soll die Vollständigkeit der Daten gewährleistet werden, wird meist bei verbindungsorientierten Sitzungen, wie bspw. HTTP eingesetzt.

Dexter1997 hat geschrieben:HTTP kann meines Wissens allerdings nur Textdateien übertragen, wobei meistens nur HTML-Dateien übertragen werden.

Gegenfrage, mit welchem Protokoll spricht dein Rechner / Internetbrowser wenn du eine Seite ansurfst, und Bilder angezeigt werden?

Wenn du mit zwei Clients von Standort A nach B und vice versa kommunizieren möchtest, wirst du einen Server als Vermittler benötigen, der die Daten vollständig, sicher und an das richtige Ziel ausgibt. Du hast also nicht nur ein Problem dass du erstmal am Standort des Servers entsprechende Portfreigaben einrichten musst, sondern, dass dieser u.U. multithreading-fähig o.ä. ist, und weiß, wann eine Nachricht "vollständig" ist, da TCP zunächst ein endloser Byte-Stream ist. Zusätzlich sollte die Übertragung der Daten verschlüsselt übertragen werden. Eine Applikation zu schreiben, die über keinerlei Schutzmechanismen verfügt und auf einem Netzwerkport WAN-seitig Anfragen entgegennimmt würde ich sowieso in eine DMZ verfrachten.

UDP ist IMO absolut nicht geeignet für die Erstellung eines Chat-Servers.

Mfg, sls