Array Ofset und Count in ein Byte Array Inplementieren?

  • VB.NET
  • .NET (FX) 4.0

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

    Array Ofset und Count in ein Byte Array Inplementieren?

    Hallo,

    Ich würde gerne folgende Methoe(n) Inplementieren:

    VB.NET-Quellcode

    1. Public Overrides Sub Write(ByVal buffer() As Byte, ByVal offset As Integer, ByVal count As Integer)
    3. End Sub

    VB.NET-Quellcode

    1. ​
    2. Public Overrides Sub Flush()
    4. End Sub

    So, was mache ich jetzt mit den ofset und count parametern, bezihungsweise wie kriege ich diese aus diesen buffer array raus??

    LG, Herbrich

    Ich nehme an, Du leitest eine Klasse von System.IO.Stream ab.
    offset und count gibt lediglich an, welche Bytes in buffer verwendet werden sollen.
    Beispiel:
    Der Buffer ist 100 Bytes groß, offset ist 0 und count ist 100: Der gesamte Puffer wird verarbeitet.
    Der Buffer ist 100 Bytes groß, offset ist 20 und count ist 40: Nur 40 Bytes ab dem Index 20 werden verwendet.
    Eine konkrete Implementierung könnte so aussehen:

    VB.NET-Quellcode

    1. Public Overrides Sub Write(ByVal buffer() As Byte, ByVal offset As Integer, ByVal count As Integer)
    2. Dim EndIndex = offset + count - 1
    3. For i = offset To EndIndex
    4. DoStuff(buffer(i))
    5. Next
    6. End Sub
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Hallo,

    Vielen danck, du hast mir echt sehr geholfen aber was macht DoStuff?? Ist das ne einfache Sub in der ich weiter Arbeiten soll. Das würde dann ja in prinzip ja nur bedeuteten das ich alles in Base64 zu kodieren habe und dann eine Instanze der Target Klasse zu erstellen habe und diese dann zu Serialisieren. Ok vielen danck, ich dencke ich habe es geckekt :)

    LG, Herbrich

    Ist das ne einfache Sub in der ich weiter Arbeiten soll.

    Ja. DoStuff heißt halt "Mach was!". Was Du dann genau machst, bleibt Dir überlassen ;)

    Übrigens: Beachte, dass Du nicht davon ausgehen kannst, dass Write nur einmal aufgerufen wird, bzw. dass sich der Aufrufer um die korrekte Anzahl an Bytes kümmert. Du musst eventuell die letzten... ähm... 2 oder 3 Bytes puffern, wenn Du mit Base64 arbeiten willst.
    Denn Base64 verarbeitet immer 3 Bytes und macht daraus 4 Zeichen. Wenn Du jetzt beispielsweise Write mit 2 Bytes aufrufst, dann fehlt Dir das letzte Byte. Der Aufruf an Convert.ToBase64 gibt dann sowas in der Art zurück: "ABC="
    Wenn Du das stur an 'nen String dranknüpfst, stimmen die Daten nicht mehr.
    Du solltest also so lange Bytes puffern, bis 3 vorhanden sind, und diese dann verarbeiten. Dann wieder puffern bis 3 vorhanden sind, diese verarbeiten. Und so weiter.
    Sobald der Stream geschlossen wird, verarbeitest Du die übrigen Bytes (wenn vorhanden).
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Hallo,

    Also ich mache dass so, ich habe eine Liste aus Bytes und erst wen die Flush Methode aufgerufen wird wird dann die Base64 Coodierung durchgeführt, eine Klasse Instanziert, das Base64 da rein kopiert in die Value eigenschaft, eine MD5 Hash gebildet und ganze serialisiert.

    Jetzt habe ich aber doch eine Frage zu Read Funktion, da habe ich als Return nur ein Integer, wie muss ich diese Programmieren damit ich die Bytes in Integer zurück geben kann??

    VB.NET-Quellcode

    1. ​
    2. Public Overrides Function Read(ByVal buffer() As Byte, ByVal offset As Integer, ByVal count As Integer) As Integer
    3. ' Mach was
    4. End Function


    LG, Herbrich

    Liste aus Bytes und erst wen die Flush Methode aufgerufen wird wird dann die Base64 Coodierung durchgeführt

    So geht's auch, aber beachte, dass das nicht ganz der Sinn von Streams ist.
    Streams sind eigentlich dazu da, dass man nicht alles im Arbeitsspeicher haben muss, sondern mit "Häppchen" arbeiten kann.

    damit ich die Bytes in Integer zurück geben kann

    Das ist nicht der Sinn der Read-Funktion. Lies Dir am besten die Dokumentation zu der Funktion durch.
    Die gibt die Anzahl an gelesenen Bytes zurück.
    Und ähnlich wie in der Write-Methode geben offset und count den Bereich im Puffer an, in den geschrieben werden soll.
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    Hallo,

    Gut, aber wie kann ich dann die Bytes wieder aus den Stream rauskriegen?? Und mir ist es eig egal wie die Daten durch meinen Stream gehen, d.h. ob man da jetzt alles reinpackt und dann flusht oder ob man writet und dann direct nach aufruf von wirte flushgt. Weil die Daten werden letzendlich in einen Netzwerk Stream übertragen und zwar in Protocol.

    LG, Herbrich

    Niko Ortner schrieb:

    Streams sind eigentlich dazu da, dass man nicht alles im Arbeitsspeicher haben muss, sondern mit "Häppchen" arbeiten kann.

    Hat nix mit Arbeitsspeicher zu tun. Siehe MemoryStream, UnmanagedStream und viele anderen Streams.

    Zudem muss man nicht erst nen Base64 string machen und dann den Hash davon. Nimm doch gleich die rohen bytes??


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

    @thefiloe
    Ich würde eher sagen, MemoryStream u.ä. sind einfach Schnittstellen für andere Verwendung. Manchmal kann es gewollt sein, einen Stream komplett in ein Byte-Array schreiben zu lassen -> MemoryStream und UnmanagedMemoryStream.
    Puffern, um aus vielen kleinen Write-Aufrufen einen größeren zu machen -> BufferedStream.
    Aber meistens will man vermeiden, viele Daten gleichzeitig im Speicher zu haben:
    FileStream, PipeStream, NetworkStream, CryptoStream, Kompressions-Streams, etc.

    @zn-gong
    wie kann ich dann die Bytes wieder aus den Stream rauskriegen

    Du musst Dich etwas genauer ausdrücken.
    Aus welchem Stream willst Du die Daten rausbekommen? Was meinst Du mit "in Protocol"?
    "Luckily luh... luckily it wasn't poi-"
    -- Brady in Wonderland, 23. Februar 2015, 1:56
    Desktop Pinner | ApplicationSettings | OnUtils

    IO.Streams sind vielmehr eine generische Schnittstelle zum schreiben und lesen von Daten. Woher diese kommen ist doch total irrelevant. Das hat rein gar nichts mit Speicher zu tun.


    Opensource Audio-Bibliothek auf github: KLICK, im Showroom oder auf NuGet.

    Hallo,

    Was in diesen Stream geschrieben wird wird letzendlich nur über einen Network Stream rausgeschickt in Base64 eingebettet in einen JSON string, also von darher würde ich mal sagen dass es an sich ein Netzwerk Protokol Stream zum Tunneln beliebiger Daten ist.

    LG, Herbrich

    wattn nu?
    Wird Json-Code in den Stream geschrieben oder Base64-Code?

    Mir scheint dann aber, dass ein Stream die falsche Basisklasse ist, was du da am basteln bist, ist eher eine Art StreamWriter für Json oder Base64 oder whatEver.

    Weil Json oder Base64 ist ja Text, in einen Stream schreibt man aber nur Bytes.

    Aber es gibt doch glaub auch Json-Serializer, die können doch beliebige Objekte nach Json umformen und auch gleich in einen Stream schreiben, und Json kommt doch auch mit Byte-Arrays klar, also warum da noch selbst was mit Base64 basteln?

    Hallo,

    Der Stream macht nicht's weiter als nach einen genau festgelegten Protocol in ein NetzwerkStream zu schreiben, so der Plahn. Und das Protocol baut auf JSON und Base64 auf :)

    LG, Herbrich

    Hallo,

    Nur dass Problem ist dass das Protocol schon Exisitert, das Protocol an sich kapselt verschiedene unter protokole auf den Port 2147 (und den auto direcovery Port 1994), nun möchte ich nen Stream für ein Tunnling Protocol machen weswegen ich Bewusst von Stream ableite und nicht von einen Wirter.

    LG, Herbrich

    <Stream Writer>---<Cocaine Data Protocol tunnling Stream>--<Network Stream-->---<IP>--<Netowrk Stream>--<Cocaine Data Protocol Tunnling Stream>--<Stream Reader>

    Also in prinzip ein verschatelter Stream, und ja letzendlich geht es genau darum, Bytes zu Transportieren und zwar in einen Forgeschiebenen Protocol. Das ding ist ähnlich wie der CryptoStream KEIN Base Stream sondern ein erweiterungs Stream.

    LG, Herbrich

    PS: Der Name des Protokols Cocaine Tunnling Protocol hat nichts mit der Droge zu tun.

Facebook
Telefonspende