Java Socket и EOF

[Scheduler]

Есть такая задача. Клиент льет на сервер через сокет некие данные в csv формате. Сервер должен узнать что данные залиты полностью по EOF который должен прийти последним. Сервер должен сконвертить данные, вернуть их клиенту, послать тот-же EOF и закрыть сокет. Клиент по спекам может быть любой, сервер на Java. Проблема в том что в Java нет кода для EOF как например для конуа строки - \n. Подскажите как помочь горю. Гуглю как сумасшедший, но все тольно обсуждают проблему и никто не предлагает решения. А ведь должно же это быть как-то решено.

Заранее спасибо

[Zy]

Так это к Мармоту, он в сокеты льет, а ему сервер что-тов ответ шепчет, если не прикурасил для красного словца.

[Scheduler]

Мармоту в личку я уже стукнулся. Чай на технических пивах бываем, рассказы слушаем

[Marmot]

Лички не получал, отвечу здесь:

Сначала по делу
Традиционно при передаче текстовых данных в качестве терминатора используется байт 0х00, так делает, например Flash.
0х00 ве тексте быть не может, так что все будет работать...

А теперь не совсем по делу, на чтение с терминатором тратится очень много CPU, надо анализировать каждый прочитанный из сокета байт, на больших объемах будет сильно тормозить. Правильнее посылать сначала размер данных в двоичном формате, а уже потом, без терминатора лить данные.
На принимающей стороне, читаем размер, выделяем буфер, и после этого наполняем буфер из сокета, вместо буфера ножно использовать stream, взависимости от того чего надо с данными делать...

[Scheduler]

Спасибо!!!

В общем ясно, спеку которую мне всучили заимплементировать нельзя, потому как EOF в природе не существует. Байт 0х00 в качестве терминатора рспользовать можно, но не факт что на клиенте это будет заимплементировано так-же. В спеке то написано [EOF] и каждый может это понимать по разному. Придется переходить к организационным методам решения вопроса (где здесь смайлик с молотком?).

[Stanislav]

Спасибо!!!
В общем ясно, спеку которую мне всучили заимплементировать нельзя, потому как EOF в природе не существует. Байт 0х00 в качестве терминатора рспользовать можно, но не факт что на клиенте это будет заимплементировано так-же. В спеке то написано [EOF] и каждый может это понимать по разному. Придется переходить к организационным методам решения вопроса (где здесь смайлик с молотком?).

Паааагодите, не спешите! У вас специфицация - чтение csv - а может вам инфо будут пропихивать построчно? И в конце просто пошлют стринг "[EOF]"? Тогда вы можете использовать readLine() - все будет хорошо работать.

[Karlson]

Folks, eof will happen when sending stream is closed. if you mean if( -1 == socket.getInputStream().read(buffer,offset,lenght) ).
I am not sure if you'll be able to use that socket at all for in some implementations this means that socket is closed, or socket.close() was called.
What Jvm is used?

[Karlson]

and what API?

[Marmot]

Folks, eof will happen when sending stream is closed. if you mean if( -1 == socket.getInputStream().read(buffer,offset,lenght) ).

Вся проблема в том, что получение -1 не гарантирует, что на той стороне действительно вызвали close() и данные пришли все.
Реальный пример из жизни, когда падает connection via SOCKS server or stunnel...

I am not sure if you'll be able to use that socket at all for in some implementations this means that socket is closed, or socket.close() was called.
What Jvm is used?

RTFM, если сокет закрыли, то реюзать его нельзя, никак, ни в одной JVM прошедшей TCK...

[Karlson]

You self RTFM... Here's situation where socket.getInputStream().close leads automatically to socket.close(); What about socket.getOutputsTream().close()?
These situations are not reglamented by Sun's Docs (at least I have not found it).

BTW the solution for the original question will be calling socket.shutdownOutput() on the server site. The socket will remain open -client will still be able to write to it.

[Marmot]

You self RTFM... Here's situation where socket.getInputStream().close leads automatically to socket.close(); What about socket.getOutputsTream().close()?
These situations are not reglamented by Sun's Docs (at least I have not found it).

BTW the solution for the original question will be calling socket.shutdownOutput() on the server site. The socket will remain open -client will still be able to write to it.

Хмм, действительно, я не заметил, что речь шла про stream, а не про socket.

But my point still stands, получение -1 на принимающей стороне не гарантирует, что что-то было закрыто на посылающей...

[Marmot]

You self RTFM... Here's situation where socket.getInputStream().close leads automatically to socket.close(); What about socket.getOutputsTream().close()?
These situations are not reglamented by Sun's Docs (at least I have not found it).

BTW the solution for the original question will be calling socket.shutdownOutput() on the server site. The socket will remain open -client will still be able to write to it.

Хмм, действительно, я не заметил, что речь шла про stream, а не про socket.

But my point still stands, получение -1 на принимающей стороне не гарантирует, что что-то было закрыто на посылающей...

PS Посмотрел в SUN JDK 1.6 sources, закрытие любого потока ведет к закрытию сокета, хотя оно и не документировано...

[Karlson]

You self RTFM... Here's situation where socket.getInputStream().close leads automatically to socket.close(); What about socket.getOutputsTream().close()?
These situations are not reglamented by Sun's Docs (at least I have not found it).

BTW the solution for the original question will be calling socket.shutdownOutput() on the server site. The socket will remain open -client will still be able to write to it.

Хмм, действительно, я не заметил, что речь шла про stream, а не про socket.

But my point still stands, получение -1 на принимающей стороне не гарантирует, что что-то было закрыто на посылающей...

PS Посмотрел в SUN JDK 1.6 sources, закрытие любого потока ведет к закрытию сокета, хотя оно и не документировано...

Вот сцуки... Я подозревал.