2017-06-10 6 views
3

Ich benutze C#, um eine Server-Software für Windows und Java zu erstellen, um die Client-Software zu erstellen. Es funktioniert die meiste Zeit, abgesehen von den wenigen Ausnahmen, die ich nicht verstehe.TCP Senden/Empfangen von fehlenden Bytes

Ich verwende generell .ReadLine() und .WriteLine() an beiden Enden zu kommunizieren, es sei denn, ich versuche, binäre Daten zu senden. Das ist, wenn ich die Bytes direkt schreibe und lese. Dies ist, wie die Software funktionieren soll:

  1. Client fordert die Binärdaten
  2. Server mit der Länge der binären Daten als String
  3. Kunde erhält die Länge und wandelt sie in eine ganze Zahl reagiert und Lesen beginnt (Länge) Bytes
  4. Server zu schreiben beginnt (Länge) Bytes

Es ist in den meisten Fällen funktioniert, aber manchmal ist die Client-Anwendung die vollständigen Daten und b nicht erhalten Schlösser. Der Server wird immer sofort nach dem Schreiben von Daten gelöscht, so dass das Spülen nicht das Problem ist.

Außerdem habe ich bemerkt, dass dies in der Regel mit größeren Dateien passiert, kleine Dateien (bis zu ~ 1 MB) sind in der Regel kein Problem.

HINWEIS Es sieht so aus, als ob der C# -Server die Daten vollständig sendet, so dass das Problem höchstwahrscheinlich irgendwo im Java-Code liegt.

EDIT - Hier sind einige Protokolle von der Client-Seite

Arbeits herunterladen: pastebin.com/hFd5TvrF

Failing Download: pastebin.com/Q3zFWRLB

Es ist wie der Client scheint für 2048 Byte wartet am Ende (wie es sein sollte, wie length - processed = 2048 in diesem Fall), aber aus irgendeinem Grund blockiert der Client.

Irgendwelche Ideen, was ich falsch mache? Im Folgenden sind die Quellcodes von Server und Client:

C# Server:

public void Write(BinaryWriter str, byte[] data) 
{ 
    int BUFFER = 2048; 
    int PROCESSED = 0; 
    // WriteString sends the String using a StreamWriter (+ flushing) 
    WriteString(data.Length.ToString()); 
    while (PROCESSED < data.Length) 
    { 
     if (PROCESSED + BUFFER > data.Length) 
      BUFFER = data.Length - PROCESSED; 

     str.Write(data, PROCESSED, BUFFER); 
     str.Flush(); 

     PROCESSED += BUFFER; 
    } 
} 

Java Client:

public byte[] ReadBytes(int length){ 
    byte[] buffer = new byte[length]; 
    int PROCESSED = 0; 
    int READBUF = 2048; 
    TOTAL = length; 
    progress.setMax(TOTAL); 
    InputStream m; 
    try { 
     m = clientSocket.getInputStream(); 
     while(PROCESSED < length){ 
      if(PROCESSED + READBUF > length) 
       READBUF = length - PROCESSED; 

      try { 
       PROCESSED += m.read(buffer, PROCESSED, READBUF); 
      } catch (IOException e) { 
      } 
      XPROCESSED = PROCESSED; 
     } 
    } catch (IOException e1) { 
     // Removed because of sensitive data 
    } 

    return decryptData(buffer); 
} 
+0

Wie lauten die Werte für 'PROCESSED' im Java-Client, wenn Sie die Schleife durchlaufen? Ich bin daran interessiert, weil ich neugierig bin, warum es 2048 Bytes kurz endet, wenn 10.000 Bytes gelesen werden. Ich würde erwarten, dass 1808 das letzte Mal gelesen wird, wenn es die Schleife durchläuft, da es in jeder Iteration 2048 Bytes liest. – Poosh

+0

@Poosh Die 10.000 Bytes waren ein Beispiel. Ich bin gerade nicht auf meinem PC, daher kann ich Ihnen nur geschätzte Werte geben, ich werde später wieder mit den genauen Werten kommentieren. Der PROCESSED-Wert wird immer entweder um 1440 oder 2048 erhöht, am Ende wird er nur um ~ 700 inkrementiert. Zu diesem Zeitpunkt sind genau 2048 Bytes zu lesen, aber wie gesagt, sie kommen nicht beim Client an. – detus

+0

UPDATE: Hier sind einige Logs: Arbeit download: https://pastebin.com/hFd5TvrF Failing Download: https://pastebin.com/Q3zFWRLB – detus

Antwort

0

ich ein Update gefunden habe. Ab sofort sendet der Server die Länge und direkt danach das Byte-Array. Aus irgendeinem Grund funktioniert das nicht.

Also, was ich habe mich verändert ist:

  1. Send Länge und warten, bis der Client mit "OK"
  2. Schreiben beginnen Bytes zu reagieren

nicht sicher, warum, aber Es klappt.Ran es in einer while(true) Schleife und es hat Daten 1000 Mal in 4 Minuten gerade und keine Probleme gesendet, so denke ich, es ist behoben.