Как я могу убедиться, что я получил весь файл через поток сокетов?

Question

Итак, я делаю Java-программу с сервером и клиентом, и я отправляю Zip-файл с сервера на клиент. Я почти полностью отсылаю файл. Но, получив, я обнаружил некоторую несогласованность. Мой код не всегда получает полный архив. Я предполагаю, что это заканчивается до того, как BufferedReader имеет всю полноту. Вот код для клиента:

public void run(String[] args) { 
     try { 
      clientSocket = new Socket("jacob-custom-pc", 4444); 
      out = new PrintWriter(clientSocket.getOutputStream(), true); 
      in = new BufferedInputStream(clientSocket.getInputStream()); 
      BufferedReader inRead = new BufferedReader(new InputStreamReader(in)); 
      int size = 0; 
      while(true) { 

       if(in.available() > 0) {  

         byte[] array = new byte[in.available()]; 
         in.read(array); 
         System.out.println(array.length); 


         System.out.println("recieved file!"); 
         FileOutputStream fileOut = new FileOutputStream("out.zip"); 
         fileOut.write(array); 
         fileOut.close(); 
         break; 
        } 
       } 
      } 
     } catch(IOException e) { 
      e.printStackTrace(); 
      System.exit(-1); 
     } 
    } 

Итак, как я могу быть уверен, что весь архив существует до того, как он напишет файл?

Answer 1

На отправляющей стороне напишите размер файла перед началом записи файла. На стороне чтения. Прочитайте размер файла, чтобы вы знали, сколько байтов ожидать. Затем позвоните, пока вы не получите все, что ожидаете. С сетевыми сокетами может потребоваться более одного вызова для чтения, чтобы получить все отправленное. Это особенно верно, так как ваши данные становятся больше.

Answer 2

Добавить символ завершения в конце файла при его отправке. Я считаю, что Unix использует -1 для обозначения конца файла. При получении файла подождите, пока не найдете -1 и не удалите его.

Answer 3

HTTP отправляет content-length: x + \ n в байтах. Это изящно, оно может вызывать исключение TimeoutException, если соединение не работает.

Answer 4

Вы используете сокет TCP. ZIP-файл, вероятно, больше, чем сетевой MTU, поэтому он будет разделен на несколько пакетов и снова собран на другой стороне. Тем не менее, что-то подобное может случиться:

• клиент подключается
• сервер начинает посылать. ZIP-файл больше MTU и поэтому разбивается на несколько пакетов.
• клиент занят-ждет в while (true), пока он не получит первые пакеты.
• клиент замечает, что данные пришли (in.available() > 0)
• клиент читает все доступные данные, записывает его в файл и выходы
• последние пакеты прибывают

Так как вы можете видеть : Если клиентская машина безумно медленна, а сеть безумно быстро и имеет огромный MTU, ваш код просто не получит весь файл по дизайну. Вот как вы его построили.

Другой подход: префикс данных с длиной.

Socket clientSocket = new Socket("jacob-custom-pc", 4444); 
DataInputStream dataReader = new DataInputStream(clientSocket.getInputStream()); 
FileOutputStream out = new FileOutputStream("out.zip"); 
long size = dataReader.readLong(); 
long chunks = size/1024; 
int lastChunk = (int)(size - (chunks * 1024)); 
byte[] buf = new byte[1024]; 
for (long i = 0; i < chunks; i++) { 
    dataReader.read(buf); 
    out.write(buf); 
} 
dataReader.read(buf, 0, lastChunk); 
out.write(buf, 0, lastChunk); 

И сервер использует DataOutputStream отправить размер файла до фактического файла. Я не тестировал это, но он должен работать.

Answer 5

In.available() просто говорит вам, что нет данных, которые должны быть использованы in.read() без блокировки (ожидания) в данный момент, но это не означает конец потока. Но они могут появиться на вашем ПК в любое время с пакетом TCP/IP. Обычно вы никогда не используете in.available(). In.read() хватает всего на то, чтобы полностью прочитать поток.Образец для считывания входных потоков:

byte[] buf; 
int size; 

while ((size = in.read(buf)) != -1) 
    process(buf, size); 

// end of stream has reached 

Таким образом, вы полностью прочитаете поток до его конца.

update Если вы хотите прочитать несколько файлов, то вы можете передать поток в «пакеты» и префикс каждого с целым размером. Затем вы читаете до получения байтов размера вместо in.read = -1.

update2 В любом случае, никогда не используйте in.available для демаркинга между кусками данных. Если вы это сделаете, вы подразумеваете, что есть временная задержка между входящими частями данных. Вы можете сделать это только в системах реального времени. Но Windows, Java и TCP/IP - все эти уровни несовместимы с реальным временем.

Answer 6

Как я могу убедиться, что получил весь файл через поток сокетов?

Установив код. Вы используете InputStream.available() в качестве теста для конца потока. Это не то, для чего. Изменение цикла копирования на это, что также намного проще:

while ((count = in.read(buffer)) > 0) 
{ 
    out.write(buffer, 0, count); 
} 

Использование любого размера буфера больше нуля, как правило, 8192.