Netzwerkdaten komprimieren

  • Hallo zusammen

    Ich habe ein Problem bei welchem ich auf Tipps von Eurer Seite hoffe:
    Ich habe ein AutoIt Script, welches auf der ganzen Welt in sämtlichen Filialen von uns ausgeführt wird. Dieses Script installiert verschiedenste Software automatisch auf den Clients. Dabei werden die Programme auch gleich korrekt konfiguriert. Das alles funktioniert einwandfrei. Doch die Sourcedaten - sprich die Software, welche installiert werden soll, liegt auf unseren Servern in der Schweiz. Die Außenstellen haben eigene Server uns sind per Internet mit unseren Servern verbunden.

    Leider ist die Internetverbindung nach Taiwan oder China etc so langsam, dass mein Script dort z.T. über 4h benötigt. (Bei uns geht das in 122 Sekunden)

    Leider dürfen wir (momentan) auf den Servern das Branch Caching nicht aktivieren, welches Server 2008 R2 bietet.
    Nun wollte ich Euch fragen, wie ich die Software (allesamt getippte Exe Dateien) ggfs. noch weiter komprimieren könnte für die Übertragung?

    Geht das überhaupt mit VERNÜNFTIGEN Aufwand?

    Vielen Dank für Eure Inputs!
    Veronesi

    Einmal editiert, zuletzt von veronesi (16. Januar 2011 um 21:19)

  • Die einzelnen Softwarepakete sind nur 1 - 6MB klein. (Alles Firmeneigene interne Tools)
    Doch zusammen ergeben sie über 180MB!

    Ich habe mal die 180MB gezippt - und bin auf 176MB gekommen...
    Das reicht leider nicht.

    FTP Server haben wir zwar, aber nur in der Schweiz. Auch dürfen die Daten nur an einem Ort zentral abgespeichert werden, um ein Datenchaos mit unterschiedlichen Versionen vorzubeugen. Im Schnitt wird nämlich jeden 3. Tag ein Update erscheinen. (1 - 6MB)

    Sonstige Ideen?

  • (Leider) nein. Das sind alles Delphi Scripte. Die werden von meinen Arbeitskollegen programmiert. Mit diesen Tools können sämtliche von unseren Produkten updated, gewartet und online überprüft werden. Darauf habe ich KEINEN Einfluss.

    Ich muss einfach sicherstellen, dass alle unsere Firmen weltweit innert 1h die aktuellen Pakete KORREKT installiert bekommen. Und dass jeder Benutzer die für ihn festgelegten Berechtigungen auf dieses Programm kriegt. (Manche User dürfen mehr machen (Debug) und andere weniger!)

  • Es gibt kompressionsprogramme mit erstaunlichen resultaten (hab mal PAQ8PX mal getestet...).
    Allerdings geht das auf Kosten der Kompressionszeit.
    Eine Umfangreiche Studie darüber gibt es auch wo alle möglichen Kompressionsprogramme getestet wurden.
    http://www.maximumcompression.com/data/summary_mf.php

    lg

  • Werde ich mir gelegentlich mal anschauen, Danke!
    Ich möchte mit unserem Informatiker mal anschauen, ob wir nicht PRO Standort ein gemeinsames Netzlaufwerk haben, auf welches ALLE von diesem Standort Zugriff haben. Dann könnte ich so was wie ein Branch Cache selber programmieren. Mit Hash Werten uns so... Sollte ja nicht so schwierig sein.

    Dann ginge es nur beim ersten Mal pro Standort langsam. Die anderen Leute hätten es dann schnell!
    Aber zuerst brauche ich jeweils ein gemeinsames Laufwerk,... Da war der Informatiker nicht begeistert...

  • Das wird nicht viel nützen. Die Standorte sind bereits miteinander verbunden. Die Netzlaufwerke sind ganz normal im Explorer sichtbar.

    Aber die Geschwindigkeit zwischen den Standorten ist schlecht.

  • Das finde ich auch extrem knifflig.
    Du hast also 1H und in der zeit muss jede ausenstelle die 180 MB bekommen?
    Da fällt mir grad was ein A ist der Server.
    C ist der client in china.
    Jetz könnte es doch unter umständen schneller sein wenn man die daten von A nach B(irgend eine zwischenstelle auf halben weg) nach C hüpfen lassen würde.
    Da würde es aber auch sinn machen mehrere kleine parts zu machen der 180 MB.
    Das man wenn die in B ankommen gleich nach C schicken kann.
    Aber was mir noch einfällt das sind doch scripte oder compilierete sachen ?
    Warum kann man icht die scripte schicken?
    Textdateien lassen sich super komprimieren.
    Und es dan auf dem zielrechner compilieren?

  • @Matthias_199

    Sind das alles AutoIt-Skripte?

    Wenn ja, dann könntest Du die doch als Skript (zusätzlich gepackt) verschicken und dann vor Ort compilieren.

    (Leider) nein. Das sind alles Delphi Scripte.

    Diese Idee wurde schon vorgetragen, geht aber nicht.

    Die vernünftigste Idee ist wirklich diese:

    PRO Standort ein gemeinsames Netzlaufwerk haben, auf welches ALLE von diesem Standort Zugriff haben.

    wenn der Rechner, der dieses physische LW bereitstellt, dann noch zeitgesteuert (Arbeitsbeginn -x Stunden) sich die Daten automatich abholt, sollte das Ideal erreicht sein,

    PS.: mich wundert allerdings die Packrate. ich habe einige Delphi-5 EXEn gepackt und kam damit auf 60% Ersparnis.

    mfg autoBert

  • Die Pakete braucht man täglich mehrmals.
    Und wie gesagt: Es soll bloß auf einem Server gespeichert werden. - Eigentlich. Wenn das nicht geht, dann halt mit dem erwähnten gemeinsamen Netzlaufwerk. Der zusätzliche Vorteil von diesem ist nämlich, dass die Daten dort "automatisch" aktuell gehalten werden. Und zwar nicht von unserer Seite her, sondern von den Clients her, die ja mit dem Hash Wert überprüfen würden, ob die Dateien noch aktuell sind, oder nicht!

    Zudem: Wenn die Dateien (180MB) mal auf allen Außenstellen sind, dann wird ja pro Tag höchstens ein paar wenige MB dazukommen. Dann ist die 1h wieder realistisch.
    Unsere Internetgeschwindigkeit ist 100MBit Download und 100MBit Upload (symmetrische Glasfaseranbindung direkt an den Backbone)

    Die EXE Dateien wurden mit dem neuesten Delphi (Delphi 10 oder CX oder so) erstellt. Mit 7Zip konnten sie wie erwähnt praktisch nicht mehr komprimiert werden.

    Keine Ahnung, was meine Kollegen dafür für Optionen eingestellt haben....

  • Nun habe ich doch noch eine kleine Frage:
    Wenn ich das nun mit einem gemeinsamen Netzlaufwerk lösen könnte, wie kann ich überprüfen, ob es die gleiche Datei ist?

    Ich habe nämlich soeben einen kleinen Test gemacht und gemerkt, dass wenn man eine Datei kopiert, sie einen neuen Hash-Wert bekommt. (MD5) Was ja auch Sinn macht.

    Wie kann ich nun aber überprüfen ob es sich wirklich um die gleiche Datei handelt? (Wenigstens zu 99.9%?)
    Es könnte ja jemand die Datei umbenannt haben.....

    Danke für Eure Inputs!
    Veronesi

  • OK. Sorry: Fehler meinerseits!

    Ich habe _Crypt_HashData anstelle von _Crypt_HashFile verwendet! Nun geht es!

    Edit:
    Die Frage ist nun bloss: Um einen MD5 Hash Wert zu erstellen, muss dazu die ganze Datei "geladen" werden?
    Wenn ja, dann würde mir das ja nichts nützen, weil eben das Laden so lange dauert! Was könnte man hier machen?

    Einmal editiert, zuletzt von veronesi (16. Januar 2011 um 19:24)

  • Wenn ja, dann würde mir das ja nichts nützen, weil eben das Laden so lange dauert!


    Das geht bei mir sehr schnell:

    Code
    C:\Programme\AutoIt3\AutoIt3.exe 0x78C22DF03127318893CE5B1FEDE8401C Dauer: 42.268221240409 ms
    C:\Programme\AutoIt3\Neuer Ordner\AutoIt3.exe 	0x78C22DF03127318893CE5B1FEDE8401C Dauer: 42.3855545886419 ms

    ermittelt mit diesem Beispielskript:

    Spoiler anzeigen
    [autoit]

    #include <GUIConstantsEx.au3>
    #include <StaticConstants.au3>
    #include <Crypt.au3>

    [/autoit] [autoit][/autoit] [autoit]

    ; Example of hashing files

    [/autoit] [autoit][/autoit] [autoit]

    ; Create GUI
    $hWnd=GUICreate("Hasher",370,60)
    $hFileControl=GUICtrlCreateInput("",5,5,200,20)
    $hBrowseButton=GUICtrlCreateButton("...",210,5,35,20)
    $hHashCombo=GUICtrlCreateCombo("MD5",250,5,50,20)
    GUICtrlSetData(-1,"MD2|MD4|SHA1")
    $hCalcButton=GUICtrlCreateButton("Calculate",305,5,60,20)
    $hHashLabel=GUICtrlCreateLabel("Hash Digest",5,35,365,20,$SS_CENTER)

    [/autoit] [autoit][/autoit] [autoit]

    GUISetState(@SW_SHOW)

    [/autoit] [autoit][/autoit] [autoit]

    _Crypt_Startup()

    [/autoit] [autoit][/autoit] [autoit]

    Do
    $msg=GUIGetMsg()

    [/autoit] [autoit][/autoit] [autoit]

    Switch $msg
    Case $hBrowseButton
    $sFile=FileOpenDialog("Open file","","All files (*.*;)")
    GUICtrlSetData($hFileControl,$sFile)

    [/autoit] [autoit][/autoit] [autoit]

    Case $hCalcButton
    $iALG_ID=0
    ; What algorthm did the user choose?
    Switch GUICtrlread($hHashCombo)
    Case "MD2"
    $iALG_ID=$CALG_MD2
    Case "MD4"
    $iALG_ID=$CALG_MD4
    Case "MD5"
    $iALG_ID=$CALG_MD5
    Case "SHA1"
    $iALG_ID=$CALG_SHA1
    Case Else
    MsgBox(16,"Error","Not a valid algorithm!")
    ContinueLoop
    EndSwitch
    $sFile=GUICtrlRead($hFileControl)
    If Not FileExists($sFile) Then
    MsgBox(16,"Error","Invalid file")
    ContinueLoop
    EndIf
    $tdStart = TimerInit()
    $bDigest=_Crypt_HashFile($sFile,$iALG_ID)
    $tdDauer = TimerDiff($tdStart)
    GUICtrlSetData($hHashLabel,$bDigest)
    ConsoleWrite($sFile & " " & $bDigest & " Dauer: " & $tdDauer & " ms" & @crlf)
    Case $GUI_EVENT_CLOSE
    ExitLoop

    [/autoit] [autoit][/autoit] [autoit]

    EndSwitch
    Until False

    [/autoit] [autoit][/autoit] [autoit]

    _Crypt_Shutdown()

    [/autoit]

    mit dem Standard-Parameter: MD5

    mfg autoBert

  • Ja, klar geht das schnell. Aber ich habe es mal an einem 3MB File über eine sehr langsame Internetverbindung geprüft,... Es scheint so, als ladet AutoIt das ganze File, bevor er die MD5 bzw SHA1 berechnet.

    Muss es noch genauer verifizieren. Wenn das wirklich stimmt, muss ich wohl sämtliche SHA1 Hash Werte in einer kleinen Datenbank (oder INI) abspeichern, damit sie im voraus als Vergleichswerte zur Verfügung stehen!

    Sonstige Ideen, wie es anders gehen könnte?
    Trotzdem danke an alle, die bis hierher mitgeholfen haben!

    Veronesi

  • Es scheint so, als ladet AutoIt das ganze File, bevor er die MD5 bzw SHA1 berechnet.


    Das scheint nicht nur so, dass ist so. Die Lösung hast du ja schon selbst gefunden:

    muss ich wohl sämtliche SHA1 Hash Werte in einer kleinen Datenbank (oder INI) abspeichern, damit sie im voraus als Vergleichswerte zur Verfügung stehen!

    mfg autoBert

  • Ich habe noch 1, 2 Tipps für dich:
    - damit dann nicht mehrere Clients die selbe Datei auf dem Mirrorlaufwerk aktualisieren, solltest du während dem Aktualisierungsvorgang für diese Datei ein Flag in einer Datenbank setzen, sodass andere Clients auf das Ende des Updatevorgangs warten (sie können so lange ja mit anderen Dateien weitermachen)