TCP - Datenübertragung -- Ausführbare Dateien gehen nicht

  • Guten morgen zusammen,

    ich habe von @GtaSpider die Skript-Basis genutzt (folgender Thread) um Dateien per TCP zu senden / empfangen. Leider Funktionieren keine ".exe"-Dateien. Beim Empfänger ist die Datei um einen gewissen Grad kleiner. Hat einer eine Idee woran das liegen kann?

    Datei senden:


    Datei empfangen:

  • Wow, okay :/ ne nix außergewöhnliches. Win 8.1, gleiche Platte, gleiche Partition (zum Testen) sonst über TCP, klar. Beides geht nicht.

    Das Problem hab ich aber auch nur wenn ich ausführbare Dateien senden/empfangen möchte, also z.B. selbst kompilierte mit AutoIT. Sonsige Dateien, .txt .doc .jpg funktioniert alles.

    • Offizieller Beitrag

    Hallo,

    Das Problem ist denke ich mal, dass die Verbindung abbricht, bevor alle Datenpakete empfangen wurden (das geschieht durch TCPCloseSocket)
    Lösen kannst du es, in dem du beim Sender (Client) nach dem Übertragen auf eine Nachricht von dem Empfänger (ServeR) wartest.
    Der Server sendet dann einfach mit TCPSend irgendein befehl (Sowas wie "OK") sobald der Server die Datei komplett empfangen und gespeichert hat.

    Gruß,
    Spider

  • Hash Werte der Datei ermitteln, und dann prüfen ob die Hash Werte übereinstimmen? So läßt sich schon mal prüfen ob die Dateien vernünftig übertragen sind


    Gruß

    Peter

    Hinweise auf Suchmaschinen finde ich überflüssig - wer fragt hat es nicht gefunden oder nicht verstanden. Die Antwort gibt sich oftmals schneller als der Hinweis auf Dr. Goggle & Co.

    Ab 19-10-22 ergänzt um:

    Die Welt wird nicht bedroht von den Menschen, die böse sind, sondern von denen, die das Böse zulassen. (Albert Einstein)

  • Wenn die Dateien unterschiedlich groß sind, braucht man auch keinen Hashwert mehr, um zu merken, dass sie unterschiedlich sind.

    @KriZza GTASpider's Hinweis ist aber super, oder?

    Grüße autoiter

    • Offizieller Beitrag

    Wenn man selbst TCP-Verkehr programmiert, sollte man sich vielleicht selbst um ein ordentliches Protokoll kümmern, unabhängig vom TC-Protokoll selbst.
    Ich mach sowas eher selten, aber wenn dann so (sinngemäßer Ablauf):
    - Verbindungsaufbau
    - Sender an Empf.: [Anzahl-Bytes] zu senden
    - Empf. an Sender: warte auf [Anzahl-Bytes]
    - Sender:
    --- wenn Wert-gesendet=Wert-zu-empfangen -- starte Übertragung Daten
    --- wenn Werte nicht gleich -- beginne von vorn
    - Sender an Empf.: nach Ende Datenübertragung, "fertig"
    - Empf. an Sender:
    --- wenn "fertig" empfangen:
    --- --- Anzahl empfangen = Anzahl angekündigt --> OK
    --- --- Differenz vorhanden --> FAIL

  • Hi,
    auch wenn ich selbst in so gut wie allen meinen Scripten, die mit TCP zusammenhängen, ein "eigenes" Protokoll verwende (s. BugFix´ens Beispiele), MUSS (und das macht es auch!) TCP einwandfrei funktionieren!
    Wenn ich nur GTASpiders Script überfliege, fällt mir auf, dass bspw. beim Empfänger ein

    AutoIt
    While $sRecv = ""
                    $sRecv = TCPRecv($iAccSocket, 2048, 1)
    		$sRecv = BinaryToString ($sRecv)
    WEnd

    funktionieren KANN , aber nicht MUSS.
    Zu tun kann das u.a. mit dem Timeout haben, denn NUR, wenn der Empfänger einen VERBINDUNGSFEHLER registriert, sollte die Schleife verlassen werden!
    ACHTUNG, mit 3.3.8.1 erstellte Scripte fangen die Fehler "besser" ( ?! ) ab, seit 3.3.8.1 hat man es mit geänderten TCP-Errormanagement zu tun!
    Siehe dazu HIER!

    • Offizieller Beitrag

    Hallo,

    Das Script ist auch schon ein paar Järchen alt und sollte eigentlich auch nicht mehr benutzt werden. Es gibt sehr viele TCP File Transfer funktionen die viel mehr up2date sind.
    Es ist richtig, dass man beim Dateitransfer immer ein Protokoll mitschicken sollte. Ich erinnere mich auch, dass ich vor paar Jahren eine Funktion geschrieben hat, die ein Protokoll mitliefert, vlt mal googlen. Ich glaube ich habe dort folgendes Protokoll verwendet : "HEADERLEN|CRC32|FILENAME|FILE-PAYLOAD".

    Falls ich die Tage mal ein wenig Zeit habe, könnte ich ja nochmal eine aktuellere Version schreiben, die auch mit dem Errorhandlig der neuen Version klar kommt (Problem ist hier, das bei der Stable ein bekannter FEhler ist der in der Aktuellen Beta aber auch schon berichtigt wurde, welcher bei nichtempfang fälschlicherweise ein Verbindungsabbruch ausgibt)

    GRuß,
    Spider

  • Es ist richtig, dass man beim Dateitransfer immer ein Protokoll mitschicken sollte.

    Naja, nicht immer"^^, es geht ja primär darum, Informationen mit der Datei mitzuschicken bzw. einen Ansatz fürs Debuggen zu bekommen.
    Wie man (wie auch beim TE ) deutlich sieht, hat man nicht viel davon, wenn man feststellt dass ein Fehler aufgetreten ist, aber nicht weiß wo dieser auftritt und warum!
    Wenn man Dateiname, Dateigröße, ggf Hash o.a. mitüberträgt, wird nicht nur das Fehlermanagement wesentlich einfacher.

  • So, bei bisschen konnte ich mir das bestehende Script anschauen. Mich wundert das bei euch ".exe" - Dateien funktionieren, da hier beim Empfang sofort von Binary in String konvertiert wird. Damit zerhaue ich mir doch die .exe oder?

  • Mich wundert das bei euch ".exe" - Dateien funktionieren, da hier beim Empfang sofort von Binary in String konvertiert wird. Damit zerhaue ich mir doch die .exe oder?

    Gibt es einen Grund, wie du zu dieser Annahme kommst?
    Das eine hat doch mit dem anderen überhaupt nichts zu tun!
    TCP überträgt Bytes, da gibt es keine Restriktionen. Wenn schon bei der Datenübertragung Fehler auftreten, können schlecht intakte Daten auf der Platte landen.

  • Naja, meine Annahme beruht darauf, das ich alles übertragen kann (jpg, bmp, 10 MB große Textdateien, zip-Dateien usw.) nur halt keine exe -Dateien. Da wird mir immer was abgeschnitten! Heute habe ich etwas Zeit dafür. Mal schauen....

  • Habs jetzt neu erstellt und es klappt aufgrund der der _TCPFileTransfer.au3 --> modifiziert mit Dateinamen ...

  • Doch nicht erledigt. Unfassbar: jetzt gehen jegliche Dateiformate nur nichts mit "String" --- > .txt, .ini oder ähnliches.

    Kann mal bitte jemand über das Script schauen und gucken woran das liegen könnte?

    Danke,
    Chris

  • Hmm naja in Textdateien ist es nicht so ungewöhnlich, dass Zeilenumbrüche enthalten sind. Vermutlich ist daher diese Zeile im Client bzw. die entsprechende im Server für deine Probleme mit verantwortlich...

    AutoIt
    If $rBuff = @CRLF&@CRLF Then
    				ExitLoop
  • Du könntest den Datenteil vorher im Übrigen auch mit Base64 encoden, wie es die meisten Webseiten für Uploads erwarten. Dadurch hast du keine Probleme mehr mit Sonder- und Steuerzeichen außerhalb des normalen ASCII Zeichensatzes. Passende und zum Teil auch sehr schnelle Funktionen für Autoit findest du per Google.

    https://de.wikipedia.org/wiki/Base64

    Nachteil ist allerdings ein erhöhter Zeitbedarf für die En- und Dekodierung, sowie ein erhöhter Bandbreitenbedarf, da die Base64 encodierten Daten etwa 30% größer sind.
    Vorteil wäre, dass die Daten einheitlich aufgebaut sind und leichter von (d)einem Kommunikationsprotokoll abgetrennt werden können.