Проблема ObjectOutputStream при отправке данных в сокет

Question

Я работаю на сервере в моей программе, и когда cleint отправляет сообщение, я сначала отправляю 1-байтовый ACK, где 1 байт - это msgType, который я получил.

Мой поток выполнения программы выглядит примерно так:

        Socket connection = null;
        connection = serverSocket.accept();
        connection.setKeepAlive(true);
        logger.info("server: connection received from " + connection.getInetAddress().getHostName());
        out = new ObjectOutputStream(connection.getOutputStream());

        .
        .

        switch(msgType) {
         case 0:
                // MSG_START

                logger.info("Received MSG_START");
                        // send ACK
                sendACK(out, 0);
                logger.info("sent ACK for MSG_START");

                break;
       .

        }


        Then I have definition of sendAck function:
private static void sendACK(ObjectOutputStream out, int msgIntType) throws IOException {
    // TODO Auto-generated method stub

    byte[] msgType = new byte[1];
    msgType[0] = (byte) (msgIntType & 0xFF);
    logger.debug("Sending message to client: " + msgType.toString());
    out.write(msgType);
    out.flush();
    logger.debug("Sending msg: " + Arrays.toString(msgType));
}

Теперь проблема в том, что на стороне клиента, когда клиент пытается in.read (), он получает byteRead как -1, а не 1.

В чем здесь проблема?

Спасибо заранее, -JJ

Answer 1

ObjectOutputStream предназначен для записи объектов Java в потоки. В этом случае я думаю, что вы должны использовать DataOutputStream (как и клиент).

Вы бы сделали что-то вроде:

dataOutputStream.writeByte(0);

РЕДАКТИРОВАТЬ : Кстати, клиент должен использовать DataInputStream.

Answer 2

Несмотря на вашу скорость принятия ...

Вы используете ObjectOutputStream для отправки подтверждения, но этот тип потока использует специальный протокол, как описано в Спецификации Java-сериализации . Такой протокол зависит от определенных заголовков, отправленных до фактической полезной нагрузки.

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