2012-01-31 3 views
0

Я реализовал программу Java, которая считывает данные с устройств GPS через ServerSocket.Чтение данных из входного потока без клиентской стороны «flush()»

ServerSocket serverSocket = new ServerSocket(13811); 
serverSocket.setReceiveBufferSize(receiveBufferSize); 
Socket incomingSocket = serverSocket.accept(); 
InputStream stream = incomingSocket.getInputStream(); 
byte[] buffer = new byte[1000]; 
      StringBuffer sb = new StringBuffer(); 
System.out.println("START getting message from TCP stream: " + dateFormat.format(Calendar.getInstance().getTime())); 

      while (stream.read(buffer) > 0) 
      { 
       sb.append(new String(buffer)); 
       System.out.println(sb.toString()); 
      } 
System.out.println("[incomingMessage]: " + incomingMessage); 

System.out.println("FINISHED getting message from TCP stream: " + dateFormat.format(Calendar.getInstance().getTime())); 

Тем не менее, мы обнаружили, что существует большая задержка (т.е. большое отклонение между Sys из «START ...» и «FINISHED ...» время выше). Время было потрачено на inputStream.read().

Если я использую Java-клиент для подключения к вышеуказанному серверному порту и отправки данных на него, сообщение читается через входной поток сервера в течение нескольких мс. Ниже показан код клиента Java.

Socket socket = new Socket("localhost", 13811); 
DataOutputStream out = new DataOutputStream(new BufferedOutputStream(socket.getOutputStream())); 
String tobesend = "testing message 1"; 
out.writeBytes(tobesend); 
out.flush(); 
out.close(); 

Однако, если добавить "Thread.Sleep (10 * 1000)" перед "out.flush()" и "out.close()", задержка на стороне сервера будет 10seconds .. Поэтому я подозреваю, что GPS-устройство не выполнило «флеш» и привело к задержке вводаstream.read() со стороны сервера ...

К сожалению, у нас нет контроля над TCP-устройствами GPS-устройств, поэтому я могу «внесите в него какие-либо изменения, чтобы принудительно применить его к сообщению« flush »для моего входного потока ... Пожалуйста, советьте, есть ли какие-либо средства, чтобы серверная сторона могла читать данные из входного потока без такой задержки, даже на стороне клиента (то есть на устройстве GPS) не выполнять «флеш»?

+0

Там же вопрос, как, что здесь: [http://stackoverflow.com/questions/1169739/java-tcp-socket-data-transfer-is-slow][1] [1]: http://stackoverflow.com/questions/1169739/java-tcp-socket-data-transfer-is-slow – eduyayo

+0

Спасибо за исх. Похоже, что ссылка говорила о проблеме со стороны отправителя ... Я пытаюсь следовать одному из ответов там, обертывая входной поток сервера BufferedInputStream, но все тот же ...Прошу просветить, если я ошибаюсь. – xlogger

ответ

6

Приемник не может прочитать данные, которые не были отправлены. Он не может заставить другой конец отправлять данные, которые не были отправлены.

+0

Простите, что я не знаком с программированием сокетов ... это значит, что данные на самом деле не отправляются на сервер, даже writeBytes() был выполнен, но «flush()» не вызван? ... и ничего не может быть сделано на стороне приемника? Мне просто интересно, работает ли устройство GPS, как то, что я тестировал с помощью тестового клиента Java ... Есть ли у вас какие-либо предложения о том, как я могу это пересмотреть? Спасибо – xlogger

+0

Вы можете использовать wirehark, чтобы увидеть фактический отправленный пакет. Если устройство GPS отправило данные, вы сможете его увидеть. Если он не отправил данные, вы ничего не можете сделать, кроме как изменить способ работы GPS-устройства. –

0

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

Но тогда мы выполняем некоторый нагрузочный тест с той же программой сервера, имея 4000 пробных GPS-устройств, которые подталкивают данные к ним каждые 5 минут, каждый из которых составляет около 300 байт.

Мы попытались изменить код сервера, представив Threadpool для обработки данных TCP и надеемся, что это даст нам лучшую производительность.

Мы включили TCPDump и обнаружили, что на этот раз было обнаружено временное отклонение между временной меткой TCPDump и меткой «START ...», записанной в программе Java. Отклонение составляло от нескольких секунд до менее 20 секунд ...

Любое предложение о том, как устранить проблему?

Инициализация Threadpool:

blockingQueueForRetriveTCPMsg = new LinkedBlockingQueue<Runnable>(50); 
threadPoolExecutorForRetriveTCPMsg = new ThreadPoolExecutor(
    50,1200, 0, TimeUnit.SECONDS, 
    blockingQueueForRetriveTCPMsg, 
    new ThreadPoolExecutor.CallerRunsPolicy()); 

ServerSocket.accept():

ServerSocket serverSocket = new ServerSocket(13811); 
serverSocket.setReceiveBufferSize(receiveBufferSize); 
Socket incomingSocket = serverSocket.accept(); 

RetrieveTcpMessage retrieveTcpMessage = new RetrieveTcpMessage(incomingSocket); 
Thread retrieveTcpMessageThread = new Thread(retrieveTcpMessage); 
threadPoolExecutorForRetriveTCPMsg.execute(retrieveTcpMessageThread); 

Внутри RetrieveTcpMessage.run(), simuilar раньше:

InputStream stream = incomingSocket.getInputStream(); 
byte[] buffer = new byte[1000]; 
     StringBuffer sb = new StringBuffer(); 
System.out.println("START getting message from TCP stream: " +  dateFormat.format(Calendar.getInstance().getTime())); 

     while (stream.read(buffer) > 0) 
     { 
      sb.append(new String(buffer)); 
      System.out.println(sb.toString()); 
     } 
System.out.println("[incomingMessage]: " + incomingMessage); 

System.out.println("FINISHED getting message from TCP stream: " + dateFormat.format(Calendar.getInstance().getTime())); 
+1

Добро пожаловать в переполнение стека! Если у вас есть НОВЫЙ вопрос, пожалуйста, спросите его, нажав кнопку [Задать вопрос] (http://stackoverflow.com/questions/ask). – oers

Смежные вопросы