Java Q: Ограничение стрима и строк по длине

MarkM · Сообщение **MarkM** » 18 июл 2004, 06:34

Строки считываются из стрима (сокета). Две возможные проблемы. Враг может сунуть в стрим огромную строку, и/или много строк, что вызовет переполнение памяти сервера.

Усл1. Каждая строка должна быть считана не более заданной длины строки (ЗДС). То что считано более ЗДС - пропустить.
Усл2. Из стрима должно быть считано не более заданной длины чтения стрима (ЗДЧС). После считывания ЗДЧС - ресет стриму.

Искал в стандартных классах - не нашел как поставить ограничения или узнать количества считанного в стримах .

BufferedReader.readLine() читает до бесконца. Без ограничений на длину строки.
Стримы и Ридеры тоже не имеют ни ограничений ни полей вроде readCount.
Можно конечно считать в буфер а потом его сунуть в другой Стрим/Ридер. Но если ЗДЧС будет большой, то надо большой буфер создавать.

Как элегантно решить?

tasko · Сообщение **tasko** » 18 июл 2004, 08:42

Я вообще-то яву знаю поверхностно. Но вот посмотрел в хелп BufferedReader, там есть на мой взгляд все необходимое.
Я бы следующую последовательность организовал:
1. mark(int readAheadLimit) - помечаем начало
2. read() - читаем посимвольно и одновременно считаем. Нашли конец строки? - откатываемся и читаем строку. Не нашли и достигли предела?
Делай, что считаешь нужным.

Marmot · Сообщение **Marmot** » 18 июл 2004, 09:35

Я бы в этом случае не использовал бы Readers, а читал бы обычные InputStreams read-ми, и парсил их на строки сам, чекая все условия в процессе.
Кода всего на пол-экрана, зато полный контроль...

MarkM · Сообщение **MarkM** » 18 июл 2004, 09:42

Marmot писал(а):Я бы в этом случае не использовал бы Readers, а читал бы обычные InputStreams read-ми, и парсил их на строки сам, чекая все условия в процессе.
Кода всего на пол-экрана, зато полный контроль...

Будут ли множественные однобайтные read-ы сколько нибудь существенно влиять на перформанс?

tasko · Сообщение **tasko** » 18 июл 2004, 09:46

MarkM писал(а): Будут ли множественные однобайтные read-ы сколько нибудь существенно влиять на перформанс?

А икс его знает.
В С++ это работает мгновенно.

Vitaliy-2000

MarkM писал(а):
Marmot писал(а):Я бы в этом случае не использовал бы Readers, а читал бы обычные InputStreams read-ми, и парсил их на строки сам, чекая все условия в процессе.
Кода всего на пол-экрана, зато полный контроль...
Будут ли множественные однобайтные read-ы сколько нибудь существенно влиять на перформанс?

а зачем однобайтные?
читай в какой нибудь байтовый буффер приемлиемой для тебя длины

tasko · Сообщение **tasko** » 18 июл 2004, 10:11

Vitaliy-2000 писал(а): а зачем однобайтные?
читай в какой нибудь байтовый буффер приемлиемой для тебя длины

Не очень элегантное решение. Он же читает из сокета. Может быть много байт, может быть мало. ПО-твоему решению, пока этот буфер не закачается, возврата в программу не произойдет. В том то и дело, что длина наперед неизвестна. Мелкие буферы - много возни. Большой буфер - долго ждать возврата.

Я бы все-таки побайтово читал. Самое безопасное.

Marmot · Сообщение **Marmot** » 18 июл 2004, 12:59

MarkM писал(а):
Marmot писал(а):Я бы в этом случае не использовал бы Readers, а читал бы обычные InputStreams read-ми, и парсил их на строки сам, чекая все условия в процессе.
Кода всего на пол-экрана, зато полный контроль...
Будут ли множественные однобайтные read-ы сколько нибудь существенно влиять на перформанс?

Зачем однобайтные, читай в буфер среднего размера, 1К например, и скорость будет и памяти много не съешь...

Marmot · Сообщение **Marmot** » 18 июл 2004, 13:03

tasko писал(а): Не очень элегантное решение. Он же читает из сокета. Может быть много байт, может быть мало. ПО-твоему решению, пока этот буфер не закачается, возврата в программу не произойдет.

Неправильно говоришь, API читай тщательнеЕ

tasko · Сообщение **tasko** » 18 июл 2004, 16:00

Marmot писал(а): Неправильно говоришь, API читай тщательнеЕ

Ушел читать тщательнее...