Comments 41
жаль прогрессбара нет. А в целом — шикарная работа, и исходники доступны, это вам +.
Молодцы. Пожалуй, зря я изучение Silverlight забросил. Про обработку кода ответа сервера — было интересно, хороший обход =)
мм это, я так понимаю, работает только на дефолтной платформе?
Элегантное решение
ну че, первая годная статья от майла и наверно 1ое че то хорошее на ваших сервисах. И да, без прогрессбара смыл докачки файлов почти почти теряется.
Что Вы имели в виду?
Поэтому мы пытаемся разделить файл на 100 чанков для отображения прогресса от 0% до 100% [...]
У вас не отображается прогресс в виде бегущих процентов?
Возможно, у вас просто не успел инициализироваться silverlight-модуль.
Наш загрузчик — это результат более чем 2-летнего «вылизывания» кода, и он автоматически откатывается по цепочке silverlight -> flash -> iframe даже при наличии банерорезок. Для отката предусмотрен механизм таймаутов, в течении которых мы ждем инициализации плагинов (Silverlight и Flash). Если у вас установлена банерорезка или какой-либо прокси между вами и нашим сервером «режет» контент, то вполне возможно, что произошел откат до iframe-варианта, над отображением процентов в котором мы даже не заморачиваемся.
Возможно, у вас просто не успел инициализироваться silverlight-модуль.
Наш загрузчик — это результат более чем 2-летнего «вылизывания» кода, и он автоматически откатывается по цепочке silverlight -> flash -> iframe даже при наличии банерорезок. Для отката предусмотрен механизм таймаутов, в течении которых мы ждем инициализации плагинов (Silverlight и Flash). Если у вас установлена банерорезка или какой-либо прокси между вами и нашим сервером «режет» контент, то вполне возможно, что произошел откат до iframe-варианта, над отображением процентов в котором мы даже не заморачиваемся.
Что Вы имели в виду?
То, что для отображения прогресса от 0% до 100% файл размером 10 000 000 байт нужно разделить на 100 чанков по 100 000 байт каждый.
Но делать слишком маленькие, либо наоборот, слишком большие чанки, не оправданно. Поэтому файл размером 500 000 байт мы делим на 10 чанков по 50 000 байт, при этом отображается прогресс с шагом 10%. А файл размером 1 000 000 000 байт мы делим на 2000 чанков по 500 000 байт каждый для того, чтобы в случае сбоя загрузки терять в среднем 250КБ.
А о реализации на базе веб-сокетов не думали? Чтобы откат шёл от них шёл на silverlight -> flash -> iframe
При всей моей неприязни к C#, статью читал с удовольствием. До мелочей просчитанный механизм, молодцы.
P.S./~offtop: лично я для бесперебойной отправки файлов(в личных целях) использовал bittorrent протокол, результат всегда был положительный, из минусов разве что необходимость наличия торрент-клиента у получателя; и при нестабильном IP DynDNS нужен как вода (для безтреккерной передачи, когда адрес руками вбивается).
P.S./~offtop: лично я для бесперебойной отправки файлов(в личных целях) использовал bittorrent протокол, результат всегда был положительный, из минусов разве что необходимость наличия торрент-клиента у получателя; и при нестабильном IP DynDNS нужен как вода (для безтреккерной передачи, когда адрес руками вбивается).
А что не так с C#, если не секрет?
Идеологическое отторжение на уровне «Да они же слегка изменили джаву и теперь перетягивают на себя одеяло, ох уж этот мелкософт!»
Ясное дело, что сделать свой продукт выгодней, чем развивать продукт компании Sun, но лично мне неприятно, когда плодятся похожие ЯП, и это разобщает программистов по каким-то признакам.
Ясное дело, что сделать свой продукт выгодней, чем развивать продукт компании Sun, но лично мне неприятно, когда плодятся похожие ЯП, и это разобщает программистов по каким-то признакам.
Проблема состоит в том, что протокол HTTP изначально текстовый и для передачи больших объемов бинарных данных не очень приспособлен.
На самом деле HTTP такой же текстовый, как и FTP. Проблем с передачей бинарных потоков ни в одну из сторон у него нет. Есть только проблемы у отдельно взятых клиентов/серверов с пониманием Content-заголовков.
Клиент генерирует уникальный идентификатор сессии для каждого загружаемого файла.
Я бы на вашем месте использовал guid. Random хорош для генерации шума, но никак ни для обеспечения уникальности.
2. Нельзя достоверно определить код ответа сервера, мы видим лишь 200 или 404 коды (при использовании Browser HTTP Stack в Silverlight)
А текста response у вас разве нет?
5. Silverlight при наличии в имени файла определенных русских букв (буква «з» точно попала в немилость Microsoft) выдавал исключение в строке …
Microsoft тут не причем, во всем виноват RFC :) Согласно ему ваша попытка засунуть русские имена в Content-Disposition — это несоответствие стандарту.
6. Даже несмотря на сброс буферов после загрузки определенного количества байтов, Silverlight кеширует POST запрос и отправляет его полностью. Это делает невозможным загрузку файлов целиком (без чанков), т.к. на больших файлах памяти клиента не хватает для буферизации запроса. Эта особенность также делает невозможной адекватное отображение прогресса загрузки
Если бы вы сразу посмотрели на существующие на рынке решения, то увидели бы, что практически все по этим граблям уже прогулялись и используют загрузку чанками. Это решает и проблемы с Content-Range, и с хэшированием, и упрощает отображение прогресс-бара (если бы файловые сессии хранились на сервере, то простыми AJAX-запросами к простенькому же хэндлеру это реализуется без проблем), и дает возможность многопоточной загрузк, и еще много всяких фенек.
А текста response у вас разве нет?
Сознайтесь, что вы невнимательно прочитали статью.
Microsoft тут не причем, во всем виноват RFC :) Согласно ему ваша попытка засунуть русские имена в Content-Disposition — это несоответствие стандарту.
У вас есть ответ на вопрос, почему Exception выбрасывается не на всех русских буквах?
Если бы вы сразу посмотрели на существующие на рынке решения, то увидели бы, что практически все по этим граблям уже прогулялись и используют загрузку чанками.
Поверьте мне на слово, мы изучили много вменяемых решений, но как-то не встречали упоминания о том, что именно из соображений невозможности загрузить файл целиком загрузка сделана чанками.
Это решает и проблемы с Content-Range, и с хэшированием, и упрощает отображение прогресс-бара (если бы файловые сессии хранились на сервере, то простыми AJAX-запросами к простенькому же хэндлеру это реализуется без проблем), и дает возможность многопоточной загрузк, и еще много всяких фенек.
Могу поспорить, что вы не смотрели код, в противном случае теряюсь в догадках, к чему эта фраза относится.
Видно что комментарий от человека в теме. Пристану с вопросом тогда
>сразу посмотрели на существующие на рынке решения,
Не могли бы тогда, дать пару названий, по которым надо гуглить? Мне вспомнился только swfupload
который сильно далек от представленного тут решения. Был бы очень благодарен!
>сразу посмотрели на существующие на рынке решения,
Не могли бы тогда, дать пару названий, по которым надо гуглить? Мне вспомнился только swfupload
который сильно далек от представленного тут решения. Был бы очень благодарен!
Вопрос видимо не ко мне, но отвечу: посмотрите на plupload
В свое время, когда я изучал этот вопрос, то взял решения от известных брендов (триалы от Telerik, Devexpress, ComponentOne и т.п.) и просто Fiddler'ом посмотрел, каким образом они ведут работу.
Сознайтесь, что вы невнимательно прочитали статью
Если имеется ввиду, что далее именно текст ответа и был использован, то читал. И именно поэтому мне показался странным тот тезис, который я прокомментировал.
У вас есть ответ на вопрос, почему Exception выбрасывается не на всех русских буквах?
Наверно потому же, почему несоответствие стандартам W3C, например, не отображается одинаково плохо во всех браузерах. Нестандартное поведение зачастую неопределено.
Поверьте мне на слово, мы изучили много вменяемых решений, но как-то не встречали упоминания о том, что именно из соображений невозможности загрузить файл целиком загрузка сделана чанками.
Это написано в любом букваре по IO-операциям. Вы копирование файла из БД или загрузку его из сети как бы делали? Засосали весь в память, а потом скинули на диск или все-таки выполняли эти операции чанками? Из этих же соображений видится странной методика определения размера чанка. Обычно он зависит от инфраструктуры ввода-вывода (сеть, ФС и т.п.) и подбирается экспериментальным путем для достижения точки наивысшей производительности при разумном использовании ресурсов. Но никак не зависит от размера файла, как не зависит от размера файла MTU или размер кластера.
Могу поспорить, что вы не смотрели код, в противном случае теряюсь в догадках, к чему эта фраза относится.
Честно признаюсь — не смотрел, ибо думал, что код кореллирует с постом. А относится эта фраза к тому, что если бы вы сказали в самом начале «будем делать чанками, ибо IO-операции так принятор делать», то многие из дальнейших описанных проблем не возникли бы в принципе.
И не принимайте близко к сердцу мои придирки. То исследование, которые вы провели — суть совершенно правильный путь, ибо идеальных по эффективности все равно не будет. Что-то я почерпнул из вашего поста, что-то вы из комментариев :)
будем делать чанками, ибо IO-операции так принято делать
Так в том всё и дело, что сильверлайт позволяет читать файл чанками, и даже отправлять чанками в пределах одного POST-запроса, периодически делая Flush. Но видимо из-за невозможности вручную выставить Content-Length сильверлайт целиком буферизует запрос (несмотря на Flush'и) и только после полной буферизации (когда он уже знает длину запроса) добавляет к запросу заголовок Content-Length и отправляет его на сервер.
Кстати, вспомнил еще одну причину ограничения размера чанка сверху — это антивирусы (пламенный привет лаборатории Касперского), которые всенепременно хотят проверить, что же пользователь отправляет в сеть, и тем самым при загрузке больших файлов провоцируют таймауты в Flash-загрузчике, которые (таймауты) в Flash'е увы нам неподвластны.
Нашел багу — кнопки нет.
Скрин
img-fotki.yandex.ru/get/4804/deerares.61/0_44f74_fae6f40c_L.jpg
Mac OS 10.6.4
Safari 5.0.1
Скрин
img-fotki.yandex.ru/get/4804/deerares.61/0_44f74_fae6f40c_L.jpg
Mac OS 10.6.4
Safari 5.0.1
Да, мы знаем об этой баге в Safari под MacOS…
Это либо баг сафари, либо сильверлайта.
Если вас не затруднит, не могли бы вы посниферить http-запросы при загрузке страницы? :)
Это либо баг сафари, либо сильверлайта.
Если вас не затруднит, не могли бы вы посниферить http-запросы при загрузке страницы? :)
Вот лог files.mail.ru/UVVTSP
Хотя сам скрин закачать смог — кликнув по этому пустому месту
files.mail.ru/1E95PU
files.mail.ru/1E95PU
Скажите, у вас появляется кнопка если открыть сайт, а затем открыть Разработка -> Показать веб-инспектор -> закладка «Элементы»?
Да, появляется.
Если перейти по ссылке на скачивание файла, например, files.mail.ru/1E95PU
То тоже показывается сразу.
Если же переходить на морду, то нет.
Если перейти по ссылке на скачивание файла, например, files.mail.ru/1E95PU
То тоже показывается сразу.
Если же переходить на морду, то нет.
Вопрос, какая у кода лицензия? (затаил дыхание в надежде на BSD, MIT или Apache License 2.0)
Второй вопрос: выше прочитал, что в случае чего идет fallback на Flash и на iframe. Как это реализовано?
Ой, и еще вопрос: а в сторону web-sockets не смотрели?
Второй вопрос: выше прочитал, что в случае чего идет fallback на Flash и на iframe. Как это реализовано?
Ой, и еще вопрос: а в сторону web-sockets не смотрели?
1. Отвечу чуть позже, после уточнения.
2. Вся логика очереди загрузки (и fallback в том числе) реализована в javascript. Изначально так сложилось потому, что JS для нас саппортить гораздо легче и проще, нежели код плагинов (хорошо, что в Silverlight это C#, в случае Flash это птичий язык под названием Actionscript).
Как это реализовано.
Каждый плагин (Flash и Silverlight) сделан максимально простым: он умеет показывать диалог выбора файла, вызывать JS-callback о выборе файла(ов) и загружать файлы на заданный адрес, вызывая колбэки прогресса загрузки, окончания загрузки и ошибок загрузки. После своей инициализации на странице плагин вызывает JS-callback; если после вставки кода плагина на страницу в течение заданного таймаута callback не был вызван — значит либо что-то не так с плагином, либо банерорезка его «зарезала», либо просто медленный канал/компьютер у пользователя. В этом случае мы откатываемся: в случае отката на Flash повторяется такая же процедура ожидания, в случае отката на iframe нам нужен только javascript, поэтому никакого ожидания нет.
3. Не смотрели, потому что имхо технология пока находится в стадии альфы.
Возможно посмотрим тогда, когда nginx будет нативно их поддерживать.
Пока мы следим за развитием JS FileAPI и ждем, когда ребята из мозиллы разродятся Blob'ами и Firefox4 выйдет из состояния беты для того, чтобы сходный функционал дозагрузки можно было реализовать только лишь средствами JS, без помощи Silverlight.
2. Вся логика очереди загрузки (и fallback в том числе) реализована в javascript. Изначально так сложилось потому, что JS для нас саппортить гораздо легче и проще, нежели код плагинов (хорошо, что в Silverlight это C#, в случае Flash это птичий язык под названием Actionscript).
Как это реализовано.
Каждый плагин (Flash и Silverlight) сделан максимально простым: он умеет показывать диалог выбора файла, вызывать JS-callback о выборе файла(ов) и загружать файлы на заданный адрес, вызывая колбэки прогресса загрузки, окончания загрузки и ошибок загрузки. После своей инициализации на странице плагин вызывает JS-callback; если после вставки кода плагина на страницу в течение заданного таймаута callback не был вызван — значит либо что-то не так с плагином, либо банерорезка его «зарезала», либо просто медленный канал/компьютер у пользователя. В этом случае мы откатываемся: в случае отката на Flash повторяется такая же процедура ожидания, в случае отката на iframe нам нужен только javascript, поэтому никакого ожидания нет.
3. Не смотрели, потому что имхо технология пока находится в стадии альфы.
Возможно посмотрим тогда, когда nginx будет нативно их поддерживать.
Пока мы следим за развитием JS FileAPI и ждем, когда ребята из мозиллы разродятся Blob'ами и Firefox4 выйдет из состояния беты для того, чтобы сходный функционал дозагрузки можно было реализовать только лишь средствами JS, без помощи Silverlight.
Sign up to leave a comment.
Silverlight + nginx = возобновляемая загрузка файлов в браузере