spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »Nox«

FTP nutzt TCP als Transportschicht, welches wiederum verbindungsorientiert arbeitet. Das heißt eine Seite muss auf dementsprechenden Port zuhören und es ist kein "punch through" möglich. Sprich wenn du P2P mit FTP/TCP realisieren willst und die Clients hinter Routern o.ä. sitzen, muss zumindest ein Teil die Ports öffnen. kA ob das für deinen Anwendungsfall praktikabel ist.

Einen Port "öffnen" muss man dann, wenn er vorher geschlossen war, was ich so interpretieren würde, dass da unter keinen Umständen Traficc passieren kann (bspw. wenn Port 80 "geschlossen" wäre/blockiert werden würde, könnte man keine Website öffnen). Es ist eher so, dass die Portweiterleitung eingestellt werden muss, damit der Router bei eingehenden (nicht ausgehenden) Anfragen weiß, wohin diese Anfragen weitergeleitet werden sollen.
Das ist bei UDP genau das gleiche und spielt hier also keine Rolle. Es hat auch nichts damit zu tun, dass TCP verbindungsorientiert ist.

Es hat in sofern was mit UDP und TCP zu tun, weil man bei UDP ein "punch through" durchführen kann und somit die Notwendigkeit des manuellen Weiterleitens umgehen kann. Dieser funktioniert allerdings nicht bei TCP. Für Details siehe z.B. http://en.wikipedia.org/wiki/UDP_hole_punching .

Errata: hole punching scheint wohl auch bei TCP möglich zu sein. Ob es allerdings mit regulären sockets ohne weitere funktioniert, kann ich aktuell nicht sagen.

Theorie zu NAT im Allgemeinen und Hole Punching im Speziellen: http://www.net.in.tum.de/pub/mccn/2013/m…3_11_26_v02.pdf

Ok, "Hole Punching" bzw. "punch through" war mir bisher nicht bekannt. Das Problem dabei ist aber, dass dann zusätzlich ein Server benötigt wird, über den die Verbindung aufgebaut werden kann (auch wenn er zur eigentlichen Kommunikation dann nicht mehr erforderlich ist). Abgesehen davon muss der 2. Client irgendwie über die eingehende Verbindung informiert werden, da dieser sonst nicht die seinerseits erforderlich Anfrage an den Server schicken kann (sollte ich das Verfahren richtig verstanden haben.)
Ob das überhaupt erforderlich ist, ist abhängig von den Anforderungen, die hier ja nicht gelistet wurden. (Abgesehen von "einen einfachen p2p Dateiaustausch", ob mit dem "einfach" nun die Implementierung oder der Umfang gemeint ist, ist eine andere Sache.)

Was spricht dagegen einen Fileserver im LAN zu installieren?
Mit XAMPP ist das in 5 Minuten erledigt

Die Sache mit dem Internet ist auch im Prinzip nur Portweiterleitung. Dein Code sieht da im Prinzip gleich aus. Das liegt einfach am Aufbau des Netzwerks. Du hast dein Heimnetzwerk und der Router verbindet im einfachen Fall einfach die Rechner. Nach außen hin (ins Internet) ist der Router der Knoten der vorhanden ist. Willst du jetzt "durch das Internet" auf einen Rechner in deinem Netzwerk zugreifen, so schickst du die Anfrage zu dem Router un dieser Leitet das ganze dann an den jeweiligen Rechner und Port weiter. Das ist nur Konfigurationssache.

JXSE habe ich mir mal vor Ewigkeiten angeschaut, die Community war aber schon damals recht ausgedünnt. Im Java Umfeld findest Du aber sicher einige Sachen. JGroups kannst Du innerhalb eines LANs sicher gut verwenden.

Darf man denn mal fragen, was genau dein Ziel ist? Warum willst du denn eigentlich im LAN per P2P Dateien austauschen?