Programmidee!

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Programmidee!

    Hallo Leute,
    diejenigen die mich schon ein wenig kennen, wissen das ich im Programmieren nicht grad' die grosse Leucht bin. Ich möchte deshalb mit Euerer Hilfe ein kleines Programm für die Macwelt (nicht die Zeitschrift) schreiben.
    Also: Ich möchte ein Programm erstellen, dass mir in einer dynamischen Liste alle Files zeigt, welche in's WAN abgesendet werden. Vielleicht das man die Files noch nach Name oder Sendezeit sortieren kann und eine Liste davon ausdrucken kann und mit Command i noch den Pfad sieht. Was könnte man sonst noch für Features einbauen? Wie soll ich das angehen?
    Die Sprache ist die Wurzel des Missverständnisses.

    var firstName = "Fischers Fritz fischt frische Fische, frische Fische fischt Fischers Fritz"
    firstName = firstName.stringByReplacingOccurrencesOfString("i", withString: "udu")

  • tcpdump -i en0 oder so gibt dir alle Pakete aus.;-)

    TCP/IP hat keine Informationen über einen Pfad einer Datei. Es unterscheidet auch nicht groß über welches Applikationsprotokoll gesendet oder empfangen wird. Du müsstest jede erdenkliche Applikation, die dein Netzwerk benutzt mitloggen lassen - ftp client, browser, samba .....
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Das muss doch irgendwie verzeichnet sein welches File da abgesendet wird. z.B. ein Mail, ein Anhang oder ein Kommunikationsprotokoll, über FTP ein zip. File oder was immer. Oder seh ich das falsch?
    Die Sprache ist die Wurzel des Missverständnisses.

    var firstName = "Fischers Fritz fischt frische Fische, frische Fische fischt Fischers Fritz"
    firstName = firstName.stringByReplacingOccurrencesOfString("i", withString: "udu")

  • Da ist Sender- und Empfängeradresse, Port, der Inhalt der gesendet wird (Payload) und ein paar Header.

    Nein, wo die Datei herkommt, steht da wirklich nicht!

    Beispiel: Du lädst eine Datei mit dem Browser ins Internet hoch. Im Browser gibst du an welche Datei. Der lädt sie, und fügt die Daten in einen HTTP Request ein - damit ist die Sache erledigt, der Pfad ist weg. Dieser Request wird dann "auf das Netzwerk geschoben". Beim Server kommen die ROHDATEN deiner Datei an - wo die mal auf deinem Rechner war interessiert HTTP überhaupt nicht, noch weniger das darunterliegende TCP/IP. Die Netzwerkinterfaces tauschen nur Daten, was das im Endeffekt ist, ist denen Wurscht. Wenn sich das Applikationsprotokoll nicht drum kümmert (was die wenigsten machen - wozu auch) und das in seinem Protokoll mitschickt, hast du verloren.

    Das Kommunikationsprotokoll (TCP/IP ) kümmert sich nur darum, das seine Pakete korrekt übertragen werden, nicht was drin steht.
    Seminare, Artikel, Code. ObjectiveCeeds - alles für die Apfelzucht.

  • Die meiste Kommunikation bei IP läuft meist über zwei Subprotokolle UDP oder TCP. In beiden Fällen weist Du nur von welcher IP-Adresse und Port zu welcher IP-Adresse und Port die Pakete laufen. Im Falle von TCP übernimmt der IP-Stack auch noch die Aufgabe die Pakete in die richtige Reihenfolge zu bringen.

    Wenn Du nun sagen wir mal FTP nachverfolgen willst, mußt Du einen FTP-Parser bauen, der in der lage ist den kompletten Datenstroß zu filtern. Sinnvoll kann man das nur machen, wenn man erst einmal einen sogenannten Proxy benutzt, damit man überhaupt Zugriff auf diesen FTP-Datenstrom hat. Anderfalls müßtest Du ein Kernel-Treiber schreiben, der den IP-Datenstrom filtert. Es gibt noch eine weitere Möglichkeit, Du schreibst ein Plugin für ein Tool ala Ethereal mit dem man den Datenstrom sniffen kann.

    Als erstes müßtest Du Dir die passenden RFCs durchlesen und lernen wie FTP funktioniert, danach mußt Du sehen wie man Plugins für den Proxy oder Ethereal schreibt und dann ginge es darum den passenden Parser & Analyser (lex&yacc oder antlr lasen grüßen) zu schreiben.

    Versuch am Anfang einfache Programme zu schreiben, die Dich nicht überfordern.

  • Original von tjp
    Wenn Du nun sagen wir mal FTP nachverfolgen willst, mußt Du einen FTP-Parser bauen, der in der lage ist den kompletten Datenstroß zu filtern. Sinnvoll kann man das nur machen, wenn man erst einmal einen sogenannten Proxy benutzt, damit man überhaupt Zugriff auf diesen FTP-Datenstrom hat. Anderfalls müßtest Du ein Kernel-Treiber schreiben, der den IP-Datenstrom filtert. Es gibt noch eine weitere Möglichkeit, Du schreibst ein Plugin für ein Tool ala Ethereal mit dem man den Datenstrom sniffen kann.


    Und du bist dir sicher dass wenn ich mit FTP die datei von /X/Y/Z/datei.dat auf den server in das verzeichnis /R/S/T/datei hochladen will im paketstrom irgendwo "/X/Y/Z/datei.dat" drinsteht? Das glaub ich wohl weniger. Ich denk mal eher dass einzig und allein der ziehlpfad angegeben wird und dann eventuell dateiinfos (größe etc) und dann gehts schon los mit raw-bytes... oder?

  • Ich habe die RFCs zu FTP jetzt nicht durchgelesen. Aber FTP erlaubt unter anderem den Verzeichniswechsel auf dem FTP-Server. Daher wird es nicht so einfach damit getan sein nach einem Dateipfad zu suchen. Möglicherweise muß man erst einmal vorher nachvollziehen welche Verzeichniswechsel durchgeführt wurden etc. pp.

    Die Sache ist definitiv komplizierter als es den ersten Anschein hat.

  • Original von tjp
    Ich habe die RFCs zu FTP jetzt nicht durchgelesen. Aber FTP erlaubt unter anderem den Verzeichniswechsel auf dem FTP-Server. Daher wird es nicht so einfach damit getan sein nach einem Dateipfad zu suchen. Möglicherweise muß man erst einmal vorher nachvollziehen welche Verzeichniswechsel durchgeführt wurden etc. pp.

    Die Sache ist definitiv komplizierter als es den ersten Anschein hat.


    ist klar dass man die pfade von der serverseite meist "relativ" betrachtet. Aber darum gehts ja überhaupt nicht sondern es geht um die lokalen pfade.

    Ich würd mal sagen dass die Ursprungs-Idee nicht realisierbar ist.

  • Original von kressevadder
    Als erstes müßtest Du Dir die passenden RFCs durchlesen

    Geschmacksache - ich sniffe zuerst und lese dann (manchmal) ;)


    Dann sniife aber auch auf zwei Ports. Denn ftp benuzt nämlich getrennte Ports für Komandos und Datenstreams. Dann haste auch gleich die bessere Dröhnung :)

  • Original von Tom9811
    Ich weiß jetzt nicht, ob Drogenonsuum die Lektüre der RFC vereinfacht.

    So schlimm sind die RFCs nun auch wieder nicht. Das meiste ist doch direkt in ABNF beschrieben und das kann man fast 1:1 in lex umsetzen. Der Rest ist relativ verständlich beschrieben. ISO-Normen finde ich da zuweilen kryptischer.