Hallo Leute,
habe mich gestern mit Socketprogrammierung beschäftigt, möchte diese evtl irgendwann für Onlinegames verwenden.
Habe mir erstmal ein kleines Chatprogramm geschrieben mit UDP-Sockets, nur zum austesten.
Mit lokalen IPs funktioniert es einwandfrei, nicht jedoch wenn ich public IPs benütze.
Habe gelesen, es liegt daran, dass der Router dann nicht weiß, an welches Gerät er die Daten weiterleiten soll, als Lösung wurde die Portweiterleitung empfohlen, was ich eigentlich alles noch einleuchtend fand.
Das Problem ist also, dass man keine Daten an ein Gerät schicken kann, dessen genaue Adresse man nicht kennt.

Jetzt hab ich mich aber gefragt, wie es dann z.B. bei Webservern läuft,
da bekommt man ja als Client auch Antworten auf Anfragen an den Server,
ohne dass eine Portweiterleitung nötig ist.
Wie ist der Mechanismus hier?
Kann mich jemand aufklären?

Grüße, Vinz

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Hi Vinz,

bei Webservern wird das Http Protokoll verwendet, welches als Transportschicht TCP benutzt. siehe hier.
TCP öffnet eine Verbindung zwischen zwei Geräten und hält diese. UDP sendet hingegen nur ein Paket.
Bei TCP können beide Seiten auf diese Verbindung zugreifen. Die Pakete werden ausserdem durchnummeriert, um in der richtigen Reihenfolge verarbeitet werden zu können. Da müsste man sich bei UDP selbst drum kümmern.

Zu Spielen: Ich weiß nicht ob es heutzutage noch eine Rolle spielt, aber früher haben Spiele insbesondere Shooter UDP verwendet. Angeblich weil es schneller sein soll und weniger Bandbreite benötige, was man bei ISDN Anschlüssen durchaus nachvollziehen kann. Es gibt auch irgendwelche (ich nenn sie mal) Tricks, um einen Router dazu zu bewegen ein UDP Paket an einen Rechner weiterzuleiten, der keine Portweiterleitung hat. Aber ich habe bei meinen Experimenten immer TCP verwendet um mich damit nicht beschäftigen zu müssen.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Auch für ein Webserver musst du an dem Router port forwarding einstellen.
TCP benutzt eine Session und UDP ist Sessionlos, dieser Unterschied hat beim Routing folgendes Problem.
Für TCP kann ein Port aufgemacht werden, da Sender und Empfänger bekannt sind, für UDP geht das nicht, der Client kann einfach aufhöhren zu reden und später weiter senden aber bei TCP läuft permanent ein Datenaustausch(heartbeat Pakete).
TCP läuft nicht über einen Port sondern ist etwas komplizierter.
Wenn man mit TCP eine Verbindung zu Port 80 auf ein Webserver macht(socket api: listen), dann ist das nur das hallo sagen, weiterer verkehr läuft über ein high level port, der für den client auf gemacht wird(socket api: accept).
Die Maximale, theoretische, Useranzahl auf ein Server sind ~65k, weil nur soviele Ports zur verfügung stehen.
Um mehr Verbindungen parallel zu halten muss der Server mehrere listener auf mehrere IP's machen.
Der Client hat nun 2 Verbindungen zum Server, die erste ist port 80, welche er gleich verliert, weil der server ihn nun auf einen high level port erwartet und der high level Port ist nur für den Client.
Ein Router macht ein Port auf, wenn vom Internem Netzwerk nach aussen geredet werden soll und solange die verbindung aufrecht bleibt(pakete drüber laufen), wird dieser offen gelasse.
Daher muss man für Port 80 port forwarding einstellen aber nicht für die low Level Ports, denn der Server hat nun eine Verbindung mit dem Client aufgebaut und den Port frei gemacht.
Dein Client hat also ein zufälligen high level port an seinem Router auf gemacht, um auf port 80 vom server zu reden, der server hat ein zufälligen high level port zum client Port auf gemacht.
Beide können nun reden, weil beide ein Port aufgemacht haben und TCP nun mal ein Port komplett in beschlag nimmt und niemand anderes drauf laufen lässt.

UDP hingegen kennt keine session und daher gibt es kein heart beat, kein neuen port für weitere kommunikation, alles läuft über ein Port und der Server muss über ein eigenes Protokoll raus bekommen welches Paket gehört zu welchen client und in welcher reihenfolge und wann redet er nicht mehr.
Um das ganze aber Performant zu gestalten und auch sicherer zu machen, nutzt man in der regel auch andere Ports für die Kommunikation als für den Verbindungsaufbau.
Da UDP keine Ports aufmachen kann, wird in der Regel TCP benutzt, um den Port auf zu machen, der socket zerstört und dann mit UDP auf dem Port weiter geredet(wie gesagt, solange Pakete auf ein Port durchlaufen bleibt der Port offen).
Diese Technik nennt sich Net-Punch through und erlaubt das Kommunizieren mit UDP durch Firewalls hindurch.

UDP kommt so langsam aus der Mode, weil es ne menge Mehraufwand ist und es wenig Vorteile für die meisten Anwändungsfälle gibt.
UDP ist sehr schlank und erzeugt nahezu keine last, weil es kein heartbeat, session, handshake und weitere mechaniken gibt, die bei TCP notwendig sind und es ist mehr Platz für Daten pro Paket verfügbar.
Bei TCP kann man einige Teile, des Protokolls an/abschalten, z.B. Jumbo Frames(für Gigabit Lan gedacht), Linger(deaktiviert packet loss mechaniken um die latenz zu verbessern) und einiges mehr.
Praktisch kann man wohl TCP auf die Latenz und durchsatzt von UDP bekommen und muss dafür ledeglich die Socket Optionen dafür anpassen und keine komplexen Protokolle schreiben, wie bei UDP.
Funkverbindungen über UMTS und ähnliches laufen über TCP, welche aber eigene Treiberstacks benutzten, um den langen Verbindungsabbrüchen herr zu werden.
Der einzig wahre Grund, auf UDP zu setzen ist broadcast.
TCP kann kein Broadcast im direktem Sinne, weil es auf Session setzt und an der Endstelle immer wer sein muss oder man wartet, bis der Timeout durch ist.
UDP hat keine Session und sendet einfach an jede IP auf einem Port ein Paket und kümmert sich nicht darum ob es angekommen ist oder nicht und daher kann er ohne zu warten mal eben das ganze Sub-Netz zuspammen.
Für LAN-Applikationen ist also UDP recht praktisch.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Vielen Dank für die ausführlichen und hilfreichen Antworten.
Hab ich das richtig verstanden, dass Portforewarding immer nötig ist,
bei TCP, nur serverseitig, um einen Client anzunehmen und für ihn einen Port aufzumachen, worüber dann in beide Richtungen gesendet und empfangen werden kann und bei UDP, auf beiden seiten, da keine permanente Verbindung besteht, es sei den mann öffnet zunächst per TCP einen Port?
Es ist also immer mindestens serverseitig Portforewarding nötig?
Wie ist das mit Broadcast unter UDP gemeint, kann ich nur an alle Geräte im lokalen Netz senden, oder auch an das Gesamtnetz einer public IP?
Dann wäre ja Portforewarding nicht nötig...Also nein, oder?

Wie ist es bei einer Chatanwendung, die beiden Clients, die kommunizieren wollen, machen ja kein Portforewarding, kommunizieren sie dann für gewöhnlich indirekt über einen Server, der zu beiden eine TCP-Verbindung aufbaut und weiterleitet?
Oder bei Onlinegames, wenn man einen Server aufmacht, wie funktioniert das? Auch über irgendeinen Server?
Der Router eines Gamers macht doch normalerweise kein Portforewarding, dennoch kann man bei Onlinegames meist selbst Server erstellen...

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Ja du hast das richtig verstanden.

Broadcast funktioniert immer nur auf einem subnet, dieses wird durch die Subnet-Mask festgelegt und ist für Internet nicht möglich, da die Provider dies üblichweise blockiert.
Um Broadcast zu verstehen muss man sich ein bisschen mit IPv4, Subnet-Mask und deren verhalten beschäftigen.
Um es mal ultra kurz zu machen, Broadcast wird durch die letzte IP Addresse eines Subnet gemacht.
Diese kann nie an einem Client vergeben werden und daher erkennt jede blechbüchse das es an alle IP's im Subnet weiter gegeben werden soll und diese verarbeiten es auch.
Dein Internet Provider ignoriert Pakete die an diese IPs geschickt werden und verhindert damit, dass das Netzwerk geflutet werden kann.
Daher könnte erstmal UDP und TCP broadcasten, da aber TCP eine 1zu1 und keine 1zuN Verbindung ist, kann es dies dann doch nicht.

Instant Messanger und Chat Programme benutzen üblicherweise TCP und kommunizieren über Server, so muss kein Teilnehmer Firewalleinstellungen machen, weil der Client zum Server kommuniziert und nach aussen telefonieren immer funktioniert.

Bei Spielen nahezu immer ein Server vom Hersteller in verwendung aber es gibt auch kleine Spiele, wo man dedizierte Server aufstellen kann und diese muss man an der Firewall auch entsprechend frei geben.
Man kann auch ein Spiel entwickeln, wo ein Client der Server ist und trotzem ohne Firewall Einstellungen funktioniert. Dazu verbinden sich alle Clients zu einem Server vom Hersteller und dieser leitet dann den Datenverkehr an den Spielhoster weiter, dies ist dann ein Proxy Server.
Der Sinn darin ist, dass keiner die IP des anderen kennt und keiner irgendwas einstellen muss.
Der Nachteil ist, dass die Latzen höher ist, da alle Pakete über ein weiterem PC gehen und noch dazu sind alle von der Geschwindigkeit und Anbindung des Spielhosters abhängig.
Solche Systeme nennen sich oft Lobby oder Technisch gesehen Proxy.
Steam bietet z.B. für alle über Steam veröffentlichten Games ein Proxy dienst an, man erreicht diese über 25021TCP/UDP und man muss über ein Protokoll die AppID mit übergeben und Steam kann anhand dieser dann die hinterlegte weiterverarbeitung ausführen(an hersteller server senden, mit bestimmten clients reden).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hab grad über etwas gelesen, das sich "UDP hole punching" nennt. (http://en.wikipedia.org/wiki/UDP_hole_punching)
Diese Methode wird z.B. bei Skype und p2p-Diensten verwendet.
Könnte man das für Games auch nutzen?
Wenn ich richtig verstanden habe, braucht man erst mal einen öffentlich erreichbaren Server, um die externen Portnummern der Clients zu bekommen, die durch ein UDP-Paket an den Server geöffnet wurden.
Ist das kompliziert?
Dann werden diese Ports mit IP weitergegeben und die Clients können loslegen.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Das ist ein P2P verfahren und diese versucht man in der Spielebranche zu vermeiden, denn Spieler A soll nicht wissen wer Spieler B ist und durch eine direkte Verbindung ist dies möglich.

Würde jemand ein solches Spiel spielen, dann kann man die IP filtern und anhand der IP die Stadt, Provider und über den Provider letzlich auch die genaue Adresse und Name einholen.
Nun kann man sehr viel böses machen, Pishing, Drohung, Denial of Service Attacken und vieles mehr.
Es gibt ein bekannten Call of Duty gamer, den seine Addresse hat man raus bekommen, dann haben ihn zig leute Pizza geschickt, nun haben die Pizzeria ihn auf der Black list und liefern nicht an ihn, das gleiche bei der Polizei, da haben leute so oft angerufen, dass er der Polizei jedes mal, wenn er streamt vorher anrufen muss, dass die nicht vorbei kommen brauchen, weil da jemand nen Joke durch zieht.
Ist es ein Spiel, wo man gegeneinander Spielt, dann kann man auch DDOS attacken auf den Mitspieler laufen lassen und damit sorgen, dass er nicht gewinnen kann.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Ich möchte mal ein paar Statements zu TCP korrigieren:

1. Heartbeats (TCP_KEEPALIVE) sind optional. TCP-Verbindungen haben aus historischen Gründen ein großes Timeout. Man kann problemlos eine SSH-Session, die über TCP läuft, nach drei Stunden inaktivität aufwecken (mit Inaktivität meine ich, der Rechnern war z.B. im Ruhezustand). [In Anwendungen wo man das nicht will, z.B. Instant Messaging, werden dann keepalives verwendet, um festzustellen, ob der Benutzer überhaupt noch da ist und die Verbindung rechtzeitig zu terminieren, damit nachrichten nicht ins nichts laufen ]
2. Ein Server kann beliebig viele Verbindungen annehmen [modulo Speicher- und Betriebssystemlimits]. Für den Clienten wird kein Port reserviert, er wird anhand des Tupels (Destination IP, Destination Port, Source IP, Source Port) identifiziert. Die Kommunikation geht weiterhin über den Zielport (also für HTTP Port 80). Die Limits bestehen eher durch die maximale Anzahl an offenen Sockets die ein Prozess haben kann, sind aber rein Softwarenatur und nicht durch irgendwelche Netzwerkspezifikationen eingeschränkt.

Zu der Netzwerkterminologie: Das Routing ist kein Problem. Mit IPv6 hätten wir diesen ganzen mist garnicht mehr. Das Problem ist die Network Address Translation die auf Plastikroutern zu Hause statt findet. Da man ja vom Provider meinst nur eine IPv4-Adresse bekommt, müssen alle fünf (oder wieviele auch immer) Rechner im Netzwerk sich diese teilen. Dazu legt sich das Gerät eine Zuordnung an, (Fremde IP, Fremder Port, Äußerer Port) <-> (Lokale IP, Lokaler Port). Wenn man nun eine TCP Verbindung von einem Lokalen Rechner mit IP 192.168.178.3 und vom Port 63225 (den wählt das Betriebssystem zufällig aus den freien Ports aus) zu einem Server 176.9.101.187 auf Port 80 macht, dann sucht sich der Plasterouter einen freien Port an seiner Schnittstelle ins Internet aus, z.B. 33848, und legt einen solchen Eintrag in die Map an: (176.9.101.187, 80, 33848) <-> (192.168.178.3, 63225). Außerdem schreibt er das Paket um, und trägt seine eigene Internetadresse und die gerade ausgewählte Portnummre als Absender ein. Wenn nun der Server antwortet, antwortet er an die Adresse vom Router und an den Port, den dieser ausgewählt hat. Der schlägt jetzt in der Zuordnung nach und leitet das Paket an den lokalen Rechner weiter. So ungefähr .

Mit IPv6 gäbe es das ganze Problem nicht mehr, denn es wären genug Adressen für alle lokalen Rechner da. Damit braucht man Network Address Translation nicht mehr und die ganzen scherereien fallen weg.

soviel zu etwas theorie, viel spaß

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Ein kurzer Off-Topic-Einwurf: DAS ist bestimmt nicht der Grund. IP-Adressen kann man (bei den meisten Providern) schließlich schnell wechseln. Der wahre Absicht hinter diesem "alles über unsere Server"-Trend dürfte die Durchsetzung von Kopierschutzmaßnahmen sein. Diese Abhängigkeit vom Server-Betreiber ist für den Spieler alles andere als wünschenswert.

Für die Privatssphäre der Nutzer ist P2P eigentlich das beste, was es gibt. So organisiert sich beispielsweise die (noch in Entwicklung befindliche) Skype-Alternative Tox dezentral. Bei denen ist hole punching auch ein großes Thema.

_________________
So aktivierst du Syntaxhighlighting im Forum: [code=pascal ][/code], [code=cpp ][/code], [code=java ][/code] oder [code=glsl ][/code] (ohne die Leerzeichen)

Ohne keepalive kannst du nur in netzwerke, wo portforwarding passend konfiguriert ist, sonnst macht der router dir nach ms bis sekunden den port wieder dicht. Deswegen benutzt man Prinzipiell den Heartbeat, wenn man Internet Services bastelt.
Ein toller test, ist folgender.
Client macht eine Verbindung zum Server auf, Server hat ein Timeout von 3min, sende nach 2min vom Server an den Client ein Paket.
Der Server kann das Paket nicht zustellen, weil der Port wieder zu ist, das probiert er üblicherweise 3x und dann macht er nen timeout.
Der Client versucht nun nach 12min mal mit dem Server zu reden und der dropt das Paket, weil die Verbindung nicht mehr gelistet ist.

Wieso es bei dir mit ssh funktioniert, ka. mein ssh wirft mich nach einigen Minuten raus, wegen timeout.
Kann natürlich auch an mein Router liegen, wie Router mit den Port aufmachen und schliessen hantieren macht jeder wie er mag.
Es kann auch schlicht ein unterschied im sshd sein.

Okey geh ich mal ins Detail.
Linux und Windows, so auch Mac OS X nutzen filehandler, für Sockets, der Filehandler für ein Socket besteht aus vielen Metadaten, je nach System und den Verbindungsinformationen.
Diese bestehen aus wie schon genannt Ziel-IP, Zeil-Port, Src-IP,Src-Port.
Ein Process hat unter allen 3 genannten Systemen ein Soft- und Hard-Limit für diese FileHandler, Soft ist unterschiedlich(bei linux zwischen 1k-32k) und Hard liegt bei 65k.
Nun muss man als erstes soft und hardlimit entsprechend erhöhen, da zählen unter linux übrigens auch offende Datein auf der Platte mit rein.
Nun kann der Prozess erstmal mehr als 65k TCP Verbindungen auf machen.
Die Theoretisch mögliche Anzahl an Verbindungen auf einem Port liegt bei ~ (255^4-3)*65k.
In der Netzwerkprogrammierung gibt es die üblichen Server und die 10k Server.
Unter den 10k Servern versteht man Dienste, die mehr als 10k Verbindungen halten können und dafür muss man ne menge mehr aufwand betreiben.
Filehandler Limits sind nur das erste offensichtliche Problem, das nächste ist Stacksize, Anzahl an zugesicherten Speicher, Kernel reservierter Speicher für die iNodes, NetzwerkBuffer im Kernel, NetzwerkBuffer in der NIC, CPU-Leistung der NIC, Kernel Prozessing Zeit für die Socket verwaltung. Da muss schon echt alles stimmen, Thread Pooling, Socket-Poolgröße, async message verarbeitung und so weiter.
Ich hatte mal vor 2-3 Jahren auf Arbeit ein Testserver geschrieben, den konnte ich auf knapp 100k Verbindungen bringen aber da war keine Programmlogik drin, der 8Kerner war einfach völlig ausgelastet und ich hab ewig mit root am Kernel drehen müssen, geschweige an mein Code.
Ein weiteres Problem sind Router, die billig Teile können nur wenige hundert bis tausend Verbindungen halten, die kleinen Cisco schaffen Theoretisch 100k und die Schlachtschiffe bis zu 10m.
Damit man den Aufwand vereinfachen kann, hab ich z.B. mehrere virtuelle Netzwerkkarten auf Linux angelegt, das löst, die Bufferproblematik in der Software(die NIC kann natürlich immer noch überlaufen).


Da hab ich mal richtig gepennt, das ist bullshit.
Apache und co machen sowas nicht und auch nicht der UDP oder TCP/IP Stack.
Der Client macht nen highlevel port auf und sagt hallo zum Server auf port 80.
Der Server kann dann nun über Port 80 zu dem aufgemachten Highlevel Port vom Client kommunizieren.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004