Anzeige:
Ergebnis 1 bis 10 von 10

Thema: Wie filesharing-tool mit Java realisieren?

  1. #1
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Wie filesharing-tool mit Java realisieren?

    Moin!

    Würde gerne ein filesharing-tool für unsere Netzwerk programmieren, und das ganze soll in Java realisiert werden.

    So weit so gut. Ich habe mir gedacht, ich mach das filesharing-utility aus zwei Teilen pro rechner, den "Dämon", der den anderen Rechnern die freigegebenen Files liefert, und aus dem "Client", mit dem man von anderen Dämonen runterladen kann.

    Naja, ein chat und vieleicht auch ein gemeinsames Zeichenboard ala Netmeeting sollte auch integriert sein ;-)

    Wenns geht, sollte die Verbindung verschlüsselt sein, und das ganze sollte sich per GCJ kompilieren lassen.

    Hmm, mein Problem: Ich wieß überhaupt nicht, wie ich das realisisieren kann. Das ganze sollte ohne zentralen Server ablaufen, der Client sollte also seine seine Dämonen selber suchen. Wir haben dynmische Ips, also so faule halbherzige Tricks laufen da nicht ;-)

    Kennt wer ein Tutorial, dass sich mit java und so was wie ichs vorhab auseinandersetzt und vieleicht auch noch ein bisschen mit den Verschlüsselungsmechanismen in Java?

    Mfg
    Geändert von Lin728 (19-08-2017 um 16:47 Uhr)

  2. #2
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    Erstmal würde ich einen Bereich von IP-Adressen abscannen, ob da auf deinem Port irgendwo ein Daemon hockt. Wenn ja, connecten. Du wirst wohl irgendeine Art von Struktur in dein Netz bringen müssen, ein paar rechner müssen die Verwaltung anderer Rechner übernehmen, du darfst nicht jedem mit jedem connecten, besser eine Art Baumstruktur. Ich hätte auch interesse an sowas, einfach um den Napster-Hydra-Effekt zu unterstützen (Haust du eine Tauschbörse tot, kommen zwei neue)

  3. #3
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Hmmm

    Hi!

    2.) Kennste ein gutes Tutorial dazu? Wie könnte man das mit der Verschlüsselung denn machen?

    3.) Das mit den Tauschbörsen ist gut und schlecht.

    Mfg
    Geändert von Lin728 (19-08-2017 um 16:47 Uhr)

  4. #4
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477
    Was spricht gegen vorhandene Lösungen?

    JXTA zum Beispiel http://www.jxta.org
    Oder FreeNet?
    Oder eDonkey? (eventuell gibt es auch von Overnet eine Java Version)

    Eine gute Site zum Thema p2p ist http://www.openp2p.org

    Eine IP Range zu scannen finde ich keine gute Idee.
    Das könnte von den betroffene Admins als Portscan interpretiert werden und die meisten Provider verbieten sowas.

    Verschlüsselung:
    Da gibts eine ganz feine Site für Java Sachen:
    http://java.sun.com
    Dort gibt es eine Sektion APIs und dort findet man unter anderem eine Crypto API

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  5. #5
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Nix normales...

    Hi there!

    Jeder Client hat intern eine Liste mit ein paar Hostnamen, und verbindet mal zu diesen, wenns nicht klappt -> pech gehabt.
    Danach holt sich der Client von diesen Clients eine Liste mit den aktiven Hosts die dieser kennt und vergleicht welche Hosts er noch nicht kennt. Diese trägt er dann in seine Liste ein.
    Wenn sich ein neuer Host ansteckt, wird an alle registrerten Server eine Message geschickt, dass ein neurer da ist, diese Schicken diese Nachricht an alle die sie kennen.
    Hab das schon so ausgeklügelt, dass der Prozess auch wieder zum erliegen kommt.


    Warum ich keinen normalen P2P-Client nehme, weil es sowas wie ich das brauche einfach noch nicht gibt, und extrene Tauschbörsen nicht über unsere Firewalls kommen.


    lg
    Geändert von Lin728 (19-08-2017 um 16:48 Uhr)

  6. #6
    Registrierter Benutzer
    Registriert seit
    08.07.2002
    Beiträge
    719
    @anda_skoa

    Wenn nicht abscannen, wie macht man es denn dann? Mir fällt einfach keine schlauere Möglichkeit ein

    Nicht jeder mit jedem einfach deshalb, weil es zu lange dauern würde, tausende von Rechnern zu fragen. Deswegen könnte man etwa 11 Rechner zusammenschalten, einer erstellt eine Liste von den Dateien derr 10 anderen, jetzt muß man nur noch den ersten fragen, also nur noch 10% Prozent der Rechner. Natürlich kann man jetzt von diesen Superrechnern wieder 10 zusammenschalten. Und so weiter, einfach das es nicht so lange dauert, bis man mal Treffer kriegt

  7. #7
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Ping unter Java simulieren?

    Kann ich unter java einem Rechner anpingen, um zu sehen, ob er noch im netz ist?

    Mfg
    Geändert von Lin728 (19-08-2017 um 16:48 Uhr)

  8. #8
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477

    Re: Ping unter Java simulieren?

    Original geschrieben von ceisserer

    Kann ich unter java einem Rechner anpingen, um zu sehen, ob er noch im netz ist?
    Direkt geht das nicht, dazu braucht man ICMP und das erfordert RawSockets.

    Du kannst einen normalen TCP Connect machen.
    Wenn am entsprechenden Port kein Service läuft, wird der Connect allerdings auch fehlschlagen.
    Selbiges gilt für UDP.

    Man könnte alternativ ping als Prozess starten und den Output parsen.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  9. #9
    Administrator Avatar von anda_skoa
    Registriert seit
    17.11.2001
    Ort
    Graz, Österreich
    Beiträge
    5.477

    Re: Nix normales...

    Original geschrieben von ceisserer
    Jeder Client hat intern eine Liste mit ein paar Hostnamen, und verbindet mal zu diesen, wenns nicht klappt -> pech gehabt.
    eDonkey funktioniert nach diesem Prinzip.
    Da kann man selber IP/Port angeben, wenn man zufällig einen Host weiß.


    Danach holt sich der Client von diesen Clients eine Liste mit den aktiven Hosts die dieser kennt und vergleicht welche Hosts er noch nicht kennt. Diese trägt er dann in seine Liste ein.
    Eventuell auch die Möglichkeit vorsehen, eine Liste zu exportieren und zu importieren.


    Wenn sich ein neuer Host ansteckt, wird an alle registrerten Server eine Message geschickt, dass ein neurer da ist, diese Schicken diese Nachricht an alle die sie kennen.
    Vielleicht nur an die an diesem Server registrierten anderen Server.
    Wenn man sowas an alle weiter überträgt, artet das schnell aus.
    Aber jeder Server kann sich ja eine Liste von Servern merken, die in den letzten X Stunden mit ihm verbunden waren.


    Es gibt zwei Listen, eine mit generellen rechnernamen die jemals gefunden wurden, und eine mit aktiven Hosts, die sich generell zwischen den Clients austauschen. Natürlich werden so allen paar Skeunden alle in der aktiven Liste gepingt, um die Liste aktuell zu halten.
    Das generiert einen Haufen Traffic.
    Besser wäre vielleicht nur, wenn man Änderungen bekannt gibt.
    Also, wenn ein neuer Server verbindet oder die Verbindung verloren wird.
    Der Vorteil bei TCP ist ja, dass man bemerkt, wenn die Verbindung getrennt wird, ohne dass man ständing das Gegenüber pingen muß.

    Allerdings ist es gut, wenn man im Protokoll eine Art Ping vorsieht um hin und wieder das Bestehen der Verbindung zu prüfen und einen eventuell im read Lock hängenden Thread zu befreien.


    Warum ich keinen normalen P2P-Client nehme, weil es sowas wie ich das brauche einfach noch nicht gibt, und extrene Tauschbörsen nicht über unsere Firewalls kommen.
    eDonkey geht auch über Firewalls, solange nicht beide hinter einer sind, die keine Ports forwarden kann.
    In diesem Fall kann man aber auch mit einem eigenen System nix machen.

    Ciao,
    _
    Qt/KDE Entwickler
    Debian Benutzer

  10. #10
    Registrierter Benutzer
    Registriert seit
    17.09.2001
    Beiträge
    1.182

    Danke!

    Danke für alle Hinweise und Ratschläge!
    Geändert von Lin728 (21-08-2017 um 17:20 Uhr)

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •