COVD, так там изначально получают длину данных или нет?


А как же я её получу, это ж поток... Который читается до тех пор пока другая сторона не закроет сокет..

В политбюро не дураки сидят - ночью полетите (шутка). Там предлагается читать из файла (или соединения) в другой, временный поток, который по сути выполняет роль безразмерного буфера ( как ArrayList, например). После того, как чтение завершено, и, следовательно, фактическая длина данных известна, из этого временного буферного потока данные копируются в byte[], т.е. массив создается, когда уже известен необходимый размер. Это просто удобное решение, потому что не надо заранее создавать массив большого размера и увеличивать его длину при необходимости. Этим временный поток занимается.  

Это сообщение отредактировал(а) COVD - 12.5.2009, 22:44

Мы вот об этом коде?


А.. ну насколько я понял тут length вообще не нужен?
Идея этого кода в том, чтобы читать очередной байт через: inputStream.read() и по мере каждого байта подсчитать длину?
Чего-то походу здесь уже какая-то ошибка.. инае зачем нам повторно расширять массив и перекачивать в него данные, если мы уже при подсчёте получаем эти байты.. 

Кстати! А что плохого вот в таком методе приёма?


Потихоньку тянем файл.. Таким образом и большой вытащить получится наверное..? 

об этом, вестимо



читаем байт и пихаем его в ByteArrayOutputStream. Мы длину сами не подсчитываем. ByteArrayOutputStream обо всем заботится. 



Смысл той заметки в том, что удобно пользоваться ByteArrayOutputStream , который всю рутинную работу сделает. Точно также, как, например, ArrayList. 



Наоборот, это самый лучший вариант. Для перевалочного пункта. Например, сервлет. Он откуда-то читает (БД, файл,другой компьютер) и тут же отправляет клиенту (браузеру) не буферизуя и, следовательно, не расходуя памяти. Идеальный посредник.  А вот на клиенте, т.е. у конечного потребителя, буферизация бывает неизбежна, если данные имеют смысл только при полной загрузке. Например, jpeg. Пока картинка полностью не загрузилась, ее невозможно употребить по назначению.


Это сообщение отредактировал(а) COVD - 13.5.2009, 03:18

Однако браузеры справляются 

Спасибо за поправку. Рад за браузеры  . Ну, тогда не jpeg, а другой тип данных. Тут ведь не только вопрос умения клиента "потреблять" загружаемые данные "на лету", не дожидаясь конца загрузки. Что будет, если данные загрузятся наполовину и произойдет разрыв соединения? Клиент может попытаться повторить попытку. Если загружаемые данные накапливались в буфере, то буфер просто очищается и все начинается сначала. А что будет, если данные уже пошли в дело, породили какие-то действия, новые данные или сообщения? Откатывать назад последствия неполной обработки данных в этом случае может оказаться намного сложнее. Тут мы к понятию "транзакция" подбираемся. Хотя для клиентов это не типично, а для тонких и вообще, наверное, не применимо.

Это сообщение отредактировал(а) COVD - 15.5.2009, 12:39