gZip vb.net

  • VB.NET
  • .NET (FX) 4.0

Es gibt 13 Antworten in diesem Thema. Der letzte Beitrag () ist von zn-gong.

    gZip vb.net

    Hallo,

    Ich würde gerne mal Wissen ob gZip auch mit NetworkStreams arbeiten kann. Hintergrund ist der dass ich Serialisierte Daten Komprimiert und (später auch) verschlüßelt durch ein Netztwerk (TCP) übertragen möchte.

    LG, Herbrich

    alle Streams können mit allen anneren Streams zusammenarbeiten. Man kann richtige "Verarbeitungs-Strecken" zusammenstecken, etwa Html->gZip->Crypto-Stream.

    "Endverbraucher" sind meist verschiedenerlei StreamReader oder Writer (für Xml, Html, Text, Binary - was du wolle)

    gugge auch activevb.de/tipps/vbnettipps/tipp0101.html

    @ErfinderDesRades
    Hättest du dir den Artikel, den EaranMaleasi gepostet hat durchgelesen, wüsstest du, dass offensichtlich nicht jeder Stream mit jedem anderen zusammen arbeitet. Technisch gesehen ist es natürlich möglich, den Output eines CryptoStreams in einen NetworkStream reinzuleiten, praktisch funktioniert das aber nicht.

    @nafets3646 Doch es geht, man muss nur den richtigen CryptoStream erstellen, der nicht Blockbasiert arbeitet...
    Ansonsten(was sicherer ist) natürlich nen Stream zwischen hauen, der das ganze in der Blockgröße puffert...
    Ich wollte auch mal ne total überflüssige Signatur:
    ---Leer---

    Hallo,

    Kann mir das bitte vieleicht jemand genauer erklähren, ok ich habe ein hZipStream, kann ich den ein Netzwerk Stream zuweisen, oder muss ich beim Param der Sub New() der klasse gzip den NetworkStream eintrgen??

    LG, Herbrich

    Ja, eigentlich müsstest du in Sub New den Networkstream als Parameter angeben.

    Nur - der überschrift des in post#2 verlinkten Artikels nach trifft auf GZip dasselbe Problem zu wie auf Crypto: Dass diese Streams ein Stream-Ende brauchen, aber ein NetworkStream hat kein Ende.
    Aber der Artikel gibt ja auch eine Lösung dazu an.

    Ich selbst hab bisher nur mit FileStreams geGzippt:
    activevb.de/tipps/vbnettipps/tipp0101.html

    Das kann immerhin insofern nützlich sein, dass du eine funktionsfähige filebasierte Vorlage hast, und wenn nun der GegenTest mit einem Networkstream ergibt, dass die Datei unvollständig ankommt, dann liegts wohl daran, dass der letzte Teil der Datei im Puffer des Senders verbleibt, weil der Sender erst dann ein Datenpaket abschickt, wenn sein Stream-Puffer voll ist.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Hallo,

    Zur not kann man ja einfach in ein String schreiben und diesen Base64 Coodeiren und abschicken.

    Das Wilhelmstift Data Protocol sieht so aus "HEADER|JSON-SERIALISERTES OBJECT"

    Nur wen in JSON ein Pipsympol | auftaucht kann es zu Problemen kommen (ähnlich einer SQL-Injection) also einfach mit Base64 Escapen :)

    LG, Herbrich

    Weil ein Memorystream ein Ende hat und ich somit das ding nicht wieder ins Netzwerk schicken kann?? -.-

    Ich hatte ja schon diese Idee (sry hätte ich vlt schreiben sollen) aber das ver****** Ende ist immer bei Netzwerk Streams ein Problem -.-

    LG, Herbrich

    Ok, so wie ich es verstanden habe muss man eig nur alles in einen simplen MemoryStream Buffern und schon ist das Problem gelöst?? Weil da ist mir ein bissjen zu viel Coode drinn, (Threadhings, TCP kram, usw....) Ich habe mir dass jetzt doch mal sehr gründlich angesehen und habe gelsen dass es unerlässlich / sehr extrem wichtig ist die Daten in einen MemoryStream zu Buffern was ja auch sind macht weil dieser ja wieder ein Ende hat (ist ja nur der buffer^^) und ich dencke mal dass es übrigens auch der Performance zu gute kommen kann.

    Nur eine frage noch, an welcher stelle würdet ihr den MS auf die Position 0 zurückfahren?? Ich meine klar, irgendwan nach den Laden aber da kommen ja Ständig Daten durch.

    LG, Herbrich

    nur "buffern" ists glaub nicht. Das Problem ist - wurde das nicht schon erwähnt? - dass der LeseStream (ob nun crypto oder Gzip) iwie animiert werden muss, den letzten Puffer auch zu verarbeiten.
    Keine Ahnung wie der in dem Artikel das macht - ich stimme dir zu: sieht urs kompliziert aus.

    Ich hab eine neue Idee: Wenn es dir um Dateiübertragung geht, dann erstell extra dafür eine eigene Tcp-Verbindung, übertrage die Gzip-Daten und schließe dann die Tcp-Verbindung.
    Dann gibt der Networkstream auch FileEnd aus, und die Leseseite verarbeitet ihren letzten Puffer.
    Glaub ich jedenfalls, getestet noch nicht.

    Damit hättest du gleichzeitig den Vorteil, dass die Standard-Tcp-Verbindung nicht blockiert ist durch den Vorgang.

    Halllo,

    Also der Memorystream wird geclont aus den Netzwerkstream heraus (so wie ich dass verstanden habe), in gZip sind ja auch nicht so viele Daten nur soll halt durch's Netz flutschen.

    Ich würde sonst einfach ein BitArray aus den gZip erstellen und dass dann in den Stream jagen. Und auf der anderen Seite wieder diesen umweg gehen müssen. Ich werde aber trotzdem weiter am Ball bleiben :)

    Lg, Herbrich

Facebook
Telefonspende