2016-06-07 12 views
0

Ich habe einen TCP-Datenstrom, der hereinkommt und ein 256 Byte [] füllt.Verbleibende Bytes von einem Byte [] zu einem neuen vollen Byte []

Von dort verarbeite ich das Byte-Array-Nachrichten Parsen aus usw.

Sobald ich < 100 Bytes in der ersten Reihe zu bekommen, ich will die verbleibenden Bytes nehmen, sie in ein neues Array hinzufügen, und fügen Sie dann den neuen 256-Byte-Array und weiter Verarbeitung, damit ich keine Nachrichten vermisse.

public static byte[] Combine(byte[] first, byte[] second) 
    { 
     byte[] ret = new byte[first.Length + second.Length]; 
     Buffer.BlockCopy(first, 0, ret, 0, first.Length); 
     Buffer.BlockCopy(second, 0, ret, first.Length, second.Length); 
     return ret; 
    }   

ich diese Funktion bin mit (Entnommen aus einem von Jon Skeet post) aber es ist ein Problem, das in kommt vor, dass die byte [] ständig größer wird.

Zum Beispiel, wenn ich Puffer haben [], das ist 256 und newbuff [] 256 und übergebe es an die Funktion oben ... Ich bekomme eine ret von 512 [].

Nun, wenn ich die Combine-Funktion erneut übergebe, addiert es auf 256 zu 512 und wächst ständig, was ein kleines Problem verursacht, da ich einen ziemlich großen tcp-Daten-Feed verarbeite.

Irgendwelche Vorschläge, wie Sie diese effizienter machen können? Momentan habe ich versucht, diese Variante zu verwenden, aber es scheint, als wäre ich in einem Kreis gefangen.

public static byte[] Combine(byte[] first, byte[] second, int srcOffset) 
    { 
    byte[] ret = new byte[first.Length -srcOffset + second.Length]; 
    Buffer.BlockCopy(first, srcOffset, ret, 0, first.Length - srcOffset); 
    Buffer.BlockCopy(second, 0, ret, first.Length - srcOffset, second.Length); 
    return ret; 
    } 

Vielen Dank im Voraus Jungs!

+0

Ihr grundlegendes Ziel baut die Gedächtnisinflation direkt in den Algorithmus auf. Sie geben an, dass Ihr Ziel ist, immer 256 zu nehmen, nur 100 zu subtrahieren und dann weitere 256 hinzuzufügen. Ihr ursprünglicher Algorithmus scheint die 100 Bytes nicht einmal zu subtrahieren, was natürlich zu Ihrer konsistenten Zunahme von 256 führt. Die zweite wird nur noch subtrahiere diesen Offset. Wenn dieser Offset im Durchschnitt nicht mindestens der Größe des zweiten Byte-Arrays entspricht, wird Ihr Array weiter wachsen. Betrachten Sie als Referenz dieses [sehr ähnliches Problem] (http://www.metrolyrics.com/one-step-forward-lyrics-the-desert-rose-band.html) von 1987. –

+0

@MarkBailey Ich bin mir nicht sicher was du sagst, weil es mir scheint, dass du mir das gleiche erzählst, was ich gesagt habe, und ich weiß, dass die erste Funktion immer größer wird. Ich sagte auch, dass ich diese Funktion nicht geschrieben habe. Ich habe eine Modifikation an der zweiten vorgenommen, in der Hoffnung, das Problem zu lösen (Hinzufügen von verbleibenden Bytes zu einem neuen Array), was es ist, was es ist. Ich bin müde und kam von einem Todesjahrestag zurück. Sie können völlig richtig sein, nur nicht sicher .... scheint, als ob wir das gleiche mit mir sagen ... – Valmorgal

+0

Die zweite Funktion bietet mehr Leichtigkeit bei der Verringerung der vorherigen Byte-Array, aber keiner löst Ihr Problem ganz von selbst. In jedem Fall muss eine Logik außerhalb der Funktion existieren, um zu bestimmen, wann das Byte-Array zu trimmen ist: im ersten Fall durch Einspeisen eines bereits getrimmten Arrays; Im zweiten Fall wählen Sie die Größe von srcOffset.Auch wenn dieser Offset im Durchschnitt mindestens die Größe des zweiten Byte-Arrays hat, wird Ihr Array weiter wachsen. –

Antwort

1

Vielleicht ist es zu vereinfachen, Sie können etwas tun, wie die unten, ich persönlich benutze Speicher-Streams mit TCP-Servern, um alle Daten zu halten und es hat gut funktioniert.

public static byte[] Combine(byte[] first, byte[] second, int srcOffset) 
     { 
      MemoryStream result = new MemoryStream(); 
      result.Write(first, 0, first.Length); 
      result.Write(second, 0, srcOffset); 
      return result.ToArray(); 
     } 
+0

Danke für die Antwort .... eigentlich nein, es ist nicht zu einfach zu vereinfachen ..... aber wie geht es mit 0,0,0,0 im Datenstrom .... das wäre fantastisch und wahrscheinlich alle zu lösen Meine Sorgen Peter .. :) – Valmorgal

+0

@Valmorgal der Grund für die 0 ist, (ich schätze) Sie nicht überprüfen, wie viele Bytes gelesen werden. Wenn Sie vom tcp-Stream lesen, erhalten Sie eine Ganzzahl zurück. So viele Bytes wurden gelesen. Selbst wenn Sie einen 512-Byte-Puffer haben, kann er nur 30 Bytes lesen. Das bedeutet, dass die letzten 482 Bytes im Array Nullen sind. Die Art, wie ich Ihre Frage gelesen habe, ist, dass der Parameter zuerst ein vollständiges Array ist und Sekunde nur srcOffset Anzahl der Bytes hat – Peter4499

+0

Sie haben Recht ... wie würden Sie vorschlagen, ich gehe über die Überprüfung, wie viele Bytes ich lese ... weil ich denke Das ist ein Teil des Problems. Wenn ich die richtigen Daten kopiere, könnte es am Ende 0x54,0x83 sein ... etc ... statt 0x00,0x00,0x83,0x45 ..... 0x00,0x00 ... Ich fühle mich wie ich bin fehlt ein Teil dieser Prüfung? ... – Valmorgal

1

Ihre zweite Funktion scheint genau das zu tun, was Sie tun möchten. Ich versuchte, es aus diesem kleinen Testaufbau mit:

byte[] a = new byte[256]; 
byte[] b = new byte[256]; 
byte[] c = Combine(a,b, 100); 
Console.WriteLine(c.Length); 

Das Ergebnis war 412, also genau das, was man erwarten würde (512 Byte - 100 verarbeitet Bytes = 412 Bytes). Vielleicht gibt es einen Fehler in anderen Teilen deines Codes oder ich habe dich missverstanden. Es wäre sehr hilfreich, wenn Sie mehr Kontext für uns bereitstellen könnten. (Ich habe nicht genug Ruf, um Ihre Frage zu kommentieren, also poste ich dies als Antwort, sorry)

+0

Danke für das Betrachten .... es tut und es nicht ... wenn das Byte-Array eine Reihe von 0, 0,0, 0 .... in es ... kopiert es in den ersten Abschnitt ... und dann, wenn der zweite 0,0,0,0 hat, kopiert er das in den zweiten Abschnitt des neuen Arrays ..., so dass ich schließlich mit einem Byte [] fertig werde. mit einem Haufen (0,0,0,0,0) ..... dann bekommt es einen neuen Abschnitt etc und Zyklen ... – Valmorgal