Как стать автором
Обновить

Комментарии 142

Сервис в букмарки, вам плюс за топик и в карму.
Единственное: поправьте "Для безопастности, вы можете закрыть файл паролем."

Да, ждите хабраэффекта.
Рэспект и уважуха - реальное дело а не пустые слова ;) надо будет тоже попробовать, раньше я думал что это гораздо сложнее.
Ну, что же я свою задачу выполнил:) В расчете.
Вопрос: у вас только визуальная капча, звуковой нет?
а вы что не видете?
И еще вопрос: можно ли увеличить или продлить срок хранения файла?
Вообще это прототип, сделанный "чтобы было", который наверно проработает долгие годы, но так и не станет популярным, да это на самом деле и не нужно. Цель - эксперимент.
Насчет срока хранения файлов, думаю надо исчислять его с момента последней загрузки файла.
Вообще я сервис запустил приблизительно месяц назад и он только-только начал стирать первые файлы.
Думаю, что сейчас выслушаю замечания и реализую их. И на этом пока остановлюсь.
Подскажите, пожалуйста, куда копать с целью изучения информации по удалению файлов?
НЛО прилетело и опубликовало эту надпись здесь
Как удалить - это понятно, как сканировать - тоже.
Неверно сформулировал - интересует информация о том, как определить, что файл не скачивался n дней?
Сейчас так и происходит. При добавлении файла, пароль (если он задан) и номер файла а также дата создания заносится в mysql. Сейчас скрипт запускается раз в сутки, запрашивает идентификаторы файлов старее чем 30 дней и стирает их. Сейчас просто нужно добавить колонку - дата последнего доступа к файлу (правильный ввод каптчи) и стирать те файлы, который никто не скачивал.
Прочитал бред который только что написал и понял, что надо спать. Блин все-таки вредно писать комментарий отрывками. А отправлять не читая - вообще преступная халатность. Позор мне.
Сейчас просто нужно добавить колонку - дата последнего доступа к файлу
(правильный ввод каптчи) и стирать те файлы, который никто не скачивал.


omg! зачем колонка !?
а атрибуты у файлов на что !? что мешает сдвигать modified в момент отдачи файла?
created - будет указывать на дату заливки, modified на послденее обращение... по нему и грохать ;)
ах да... забыл добавить.
игры с атрибутами позволят грохать файлы по крону из скрипта который никуда кроме файловой системы лазить не будет. ибо информации для его работы будет достаточно в самой файловой системе :D
А у Вас так где-то работает? У нас просто довольно большое количество файлов, ищем оптимальное решение.
с маленьким работало...
а вот с большим, как справедливо заметили ниже, может и не работать :(

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

Ведь база данных файлов тоже будет тормозить систему.

Вопрос в том, кто быстрее будет работать.. эх.. Надеюсь, в ближайшее время мы определимся с выбором :)
до 1000 файлов я его работу вообще не замечал, а было это очень много лет назад...

вон, php, как-то ворочает своими сессиями на диске опираясь только на атрибуты... и на небольших проектах нормально себя ведет... его ведь на memcached и прочее переводят не из-за медленного удаления а из-за частых обращений...
Эх, до 1000 файлов.. У нас несколько сотен тысяч файлов :)
Угу и потом чтобы удалить старые файлы на пробегаться в всем и проверять атрибут вместо простой выборки по полю с индексом?
А если файлов тыщ 500? Сколько времени займет такая проверка?
а надо файлы хранить не в ext3 etc., а в BigTable :)
Угу, и на нанокомпьютерах=)
Предлагаю реально смотреть на вещи и исходить из того что действительно можно сделать.
ну это к хранению даты доступа в атрибутах :)
интересное замечание... надо бы подумать...
если файлов немного и лень заводить таблицу/колонку для хранения даты доступа, то можно
Много - понятие растяжимое :)
В какой же ситуации будет лучше удалять по modified, а в какой - добавлять в архитектуру базу данных с датой последнего доступа?
Вот меня как раз и интересовало, сколько времени займёт такая проверка :)
дык проверь
проверь, а потом опубликуй здесь статью на эту тему :)
Я просто думал, что кто-нибудь до нас уже прошелся по этим граблям "modified VS database" :)
Отлично! Кстати можете в коллективный перенести по желанию, карма теперь позволяет.
Мега. За практический опыт, и особенно за uploadprogress респект.
слил.ру - замечательный хостинг, в котором вижу только два недостатка:
1. Отсутствие прогрессбара при закачке через веб.
2. Ограничение на загружаемый файл при закачке через веб.

А вот почему его ругают за скорость - скорее всего это только те, кто живет не в России. Ибо у меня качает с максимальной для меня скоростью ~300 кб\сек. Думаю что это проблема всех файловых хостингов, по крайней мере русских.
отличное дело сделали !
Сделай выбор: Нахуя?
Вы бы последили за речью, товарищ.
Обалденный сервис. Как специалист говорю вам: дизайн получился круче, чем ya.ru! :)
Функционал, разумеется, на высоте: как же мне всегда не хватало красивого прогресс-бара и удобной каптчи на подобных ресурсах... "Bookmark this page" и большое... нет, огРОМНОе вам спасибо! =)
Извините конечно за вопрос, но: А где дизайн?
Еще вопрос: А где красивый прогресс-бар?
и еще вопрос: А что такое удобная капча?
Ну и последний вопрос: А чем круче?
Весь йумор этой цитато в том... Ой, не то. :-)
Дизайн в том, что он минимален (нет ничего лишнего).
Капчу нельзя назвать удобной по определению, но наверно, автор имел ввиду то, что она не "захламленная".
Лучше проще — да круче!
Кхм, хотя, все-таки назвать это дизайном тяжело. :-)
Это и есть самый настоящий Дизайн. С большой буквы.
Почему-то многие ошибочно полагают, что дизайн - это когда буквы прыгают, на фоне сайт - яркая картинка, и, главное - рюшечки, рюшечки по краям сайта.
дизайн это не то, как выглядит, а то, как работает
Вы когда-нибудь замечали, насколько чудесен дизайн Google? Нет? Вы просто пользуетесь им, как и миллионы других пользователей. ;)
супер спасибо за ценную инфу и интересую идею.
так где визуализация загрузки?
Пока что заметны недоработки небольшие - прогрессбар появляется далеко не сразу, и обновляется редко, хотя может это причуды IE7.
А вообще классно, тем более домен зачетный, Soviet Union!
Прогресс бар по задумке должен появится через секунду с момента нажатия на кнопку загрузки. Соотвественно увидеть его при загрузке маленьких файлов невозможно.
В целом конечно: а. достаточно хорошо описано. б. у меня получилось залить, что тоже хорошо.
Вопрос: а можно одновременно заливать 2 файла? или 3? в двух окнах одного браузера.
Можно с помощью JS "рисовать" второй, третий, .. input type="file" и при ткой "пакетной" загрузке upload bar будет показывать загрузку для всех файлов, ведь насколько я понимаю он выводит кол-во реальных принятых данных по отношению к указанному в заголовке Content-Length
Вы меня возможно не совсем поняли. Сейчас у Вас получается закачивать в одном браузере 3-4-5 файлов и видеть прогресс-бар?
возьмите и проверьте, в чем собственно трабл?
Я уже проверил. Не работает. Поэтому и спросил автора.
Этот эффект предстоит еще изучить. Проблема где-то кроется в моем косоруком AJAX. Firefox (да и не только он) перестает отсылать запросы вообще. Думаю надо все-таки от козлячих решений уйти в пользу prototype PeriodicalUpdater, это будет следущим шагом.
если уж делать планетарный хостинг, то выбирайте распределенную файловую систему с возможностью минимум дублировать закаченный контент. и никаких папок! :)
Это я просто к тому, что сваливать миллион файлов в одну директорию - не правильно. Насколько мне известно время поиска файла напрямую зависит от кол-ва файлов в папке.
Насчет распределенной системы. Сейчас up.giga.su - это RAID 5, учитывая ценность данных и вероятность отказа контроллера (либо дисков), я не думаю, что нужно еще что-то дублировать. Но если бы я стал строить планетарную систему, я бы пошел по пути кучи "дерьмо-компьютеров" с RAID 1 и SAS дисками, либо без RAID вообще, но тогда с дублированием данных на 2х серверах. Как мне кажется там все упрется в шину и каждый такой компьютер загнется мегабитах на 50 приблизительно сетевой активности при множестве маленьких файлов.
так мы про планетарную систему вроде и говорим?

а так будет что-то типа реляционной базы вместо fs (искать будет на порядок проще), та же куча дешевых компов, но распределение данных может быть гораздо более хитрым (см также сети доставки данных) и надежным (файл может быть сдублирован в разных частях света). да и загибаться там нечему - при хорошем-то распределении нагрузки на частозапрашиваемые файлы на несколько (не один!) серверов.
НЛО прилетело и опубликовало эту надпись здесь
введя капчу верно единожды - дальше можно качать безболезненно всё без капчи
и это тоже не комильфо :-)
Безусловно это небольшой минус, но я пренебрег этим.
Вариант с X-Accel-Redirect лишен этого скромного недостатка.
интересовался этим вопросом в рамках nginx, нашел такой upload прогресс модуль для nginx
там же есть примеры использования
enjoy :)
Вы его пробовали?
Модуль имеет статус "экспериментальный". Мои знакомые его пробовали и говорят, что были проблемы в работе.
Если у Вас есть успешный опыт его использования, то поделитесь с сообществом :)
к сожалению под сколько-таки весомой нагрузкой не тестировал :\
ИМХО концепция данного сервиса становится интересной исключительно в том случае, когда архитектура становится распределённой, с резервированием, балансировкой и прочими "прелестями".
А так перечислены просто особенности тюнинга апача и nginx, что в принципе тоже полезно.
ps: апач нужно, конечно, убирать из подобного рода сервисов.
Apache - сам по себе зло.
Подпапки уже не нужны - юниксовая файловая система уже давно мудра
Зачем asp после точки в адресах?
Почему при нажатии сабмита "error: in uploading file"?

Кто нащелкал этому топику +21?
Всё замечательно, автору большой респект за статью.
Единственный недочёт - если я начал скачивать один файл, то все остальные я могу скачивать уже без капчи по прямой ссылке (и парольная защита, полагаю, работать не будет, например). Это не совсем секьюрно. Однако из-за того, что первый файл всё таки надо скачивать через капчу, то прямых ссылок никто давать не будет, т.ч. это не такая большая проблема. Ну и если делать всё правильно, как описанно в статье в варианте "Круто", то такой проблемы не будет.
Я бы советовал еще сделать перенаправление на нужный файл на встроенном в nginx перле, таким образом освобождается нехилое количество памяти и что особенно важно загрузка стартует намного быстрее. Настоятельно рекомендуется шифровать всю необходимую информацию в УРЛ, не делая никаких обращений ни к базе ни к локальной (или тем более удаленной) ФС, за исключением возможно проверки существования файла (nginx и сам отловит но теряется возможность сделать какой-то экшен, например пнуть какой-то демон чтобы поискал дубликать где-то на другом сервере или диске.

Распределнная ФС в данном случае не рекомендую. Достаточно хранить файлы локально и сихронизировать их по http.

Еще стоит считать хеши файлов чтобы отсеивать дубликаты.

SAS диски - неоправдано, 14*500 SATA при вменяемой стоимость потянут до 3К потоков скачивания на средней скорости и 1K на высокой (2-10Mb), упремся скорее в каналы уже.

Если интересно - могу описать примерную структуру своего ресурса, который когда запускался был примерно таким, как тут описано, но за где-то год с небольшим вырос до всеукраинского проекта. Конкретно, думаю, будет интересно про распределение файлов и аплоад файлов по фтп.
Интересно. Опишите.
Это было бы очень инетересно и безумно полезно.
Было б здорово веб-интерфейс в аплет вынести..
ммм.. задумался (:
Круто! Классный сервис, будет нужда - обязательно воспользуюсь.
Инфа по реализации - ещё круче, пригодится)
И одно предложение - по-моему, рядом с прогресс-баром не хватает кнопки отмены закачки.
Закройте эту вкладку браузера и закачка отмениться ;-)
В подобных сервисах главное — не техника «выдачи» файлов, а техника «хранения» и «масштабирования» информации.
nginx вкурсе о заголовке x-send-file, схема простая, первично запрос типа /blablabla/1.mp3 получает php, проверяет все данные (введена ли капча, не флуд ли это итп) и делает что-то вроде:
headaer('X_SEND_FILE /blablabl2/2.mp3');
nginx все это дело видит, закрывает соединение с fast-cgi и отдает файл. Умный сцуко.
Реализовать это все не сложно, nginx более чем подходит к этой задачи. Сложнее спроектировать сервис таким образом, чтобы подключение новых дисков или массивов не требовало каждый раз поддержки программиста.
Так, с заголовком x-send-file я намудрил, заголовок, соответственно, x-accel-redirect
Как я уже писал выше - это не самый эффективный путь. Лучше реализовывать выдачу этого заголовка на встроенном перле без использования бекэнда вообще.
хм.. не знал, что Apache и nginx - "программы" )

"отдачей файлов должен заниматься Apache, а лучше nginx. Во первых эти программы в полной мере поддерживаю "
а что это, если не программы? Железо?
ну некорректно называть веб-серверы "программами", серверы БД ведь никто не называет программами..
что за ламерство, не понимаю
ну хорошо, хорошо =) не кипятись =) А что это, если не программы? =)
я спокоен. веб-серверы. называйте вещи своими именами
Есть аппаратные веб-серверы, например решения от Cisco, есть программные веб-серверы, например apache и nginx. Если называть вещи своими именами, то nginx и apache — программы.
есть hardware и software,
к чему, по твоему, относятся apache и nginx?
мля на секунды опредил =(
software. глобально - да. ПО.
Почитай про классификацию ПО и подумай, куда можно отнести вышенаписанное.
В моем понимании "программы" - это инструментальное ПО, а не прикладное.
в следующий раз к своим комментариям прикладывай список твоего понимания и трактации общепринятых определений. Апач и енджиникс — ПО, софт, программы.
Почему вы уверены, что ваш сервис будет отличаться от других?
Как только подрастет количество посетителей - возникнут проблемы со скоростью и местом на дисках.
Чтоб решить эти проблемы нужны $$, отсюда три пути: - реклама, - платные аккаунты, - оставить все как есть
Может быть немного не в тему вопрос, а как быть с правовыми аспектами данного сервиса. Надо наверное добавить страничку с текстом, что владелец ресурса не несет ответственности за файлы, котрые загрузили пользователи. Иначе там могут такого на закачивать :))
забыли рассказать, что помимо пекл-модуля можно организовать индткатор загрузки через RFC1867 или флэшку на стороне клиента. и про то, как вы отдаете файлы (тут надо было бы рассказать про http_send_file). а в планах перехода на nginx / lighttpd вспомнить про замечательные http_perl_module и mod_magnet.
а в целом поучительно для некоторых будет.
Прекрасно :)
Первый виденный мной, нормально работающий через мою корпоративную проксю, прогресс-бар.
Все оно, конечно, хорошо. Но держится все на голом энтузиазме или как? Поддержка железа + каналов = неплохая копеечка. В чем будет источник доходов?
VPK
Жаль что не могу Вам плюсануть. Это самый главный вопрос. Построить сервис можно. Но для того чтобы он был жизнеспособным он должен как минимум самоокупаться. Иначе...
Здесь описан технический аспект. Автор молодец. Но прежде чет запускать очередной файл-хостинг необходимо описать его миссию и набросать бизнес модель. Где деньги???
Например мой блог помимо моей воли стал оплотом борьбы с Letitbit. Да нехочу я ни с кем бороться. Я хочу быть клиентом их файл-хостинга. Но для этого необходима правильно выстроенная парадигма монетизации сервиса. Иначе даже незачем все начинать.
Насчет:

"Однако у такого метода есть свой косяк: при загрузке файла на сервер nginx полностью получает весь запрос, и только потом передает его в apache. До тех пор, пока nginx полностью не получит весь файл, apache даже не будет знать, что происходит загрузка, что делает невозможным работу upload progress bar."

Посмотрите на http://www.dleex.com, там используется nginx как front-end и при этом работает progress bar
отличное описание и реализация. а дальше — посмотрим, на сколько хватит ваших мощностей ;-)
можно сделать плавный прогресс бар, если добавить ему анимацию ширины индикатора между AJAX запросами. например, запрос идёт каждую секунду, а ширину вы изменяете в течении, скажем, 950 мс как раз до следующего.
идеал, к которому надо стремиться
Отлично!
Прекрасная скорость, лаконичный интерфейс.

Принято 6.46 Mb из 8.72 Mb средняя скорость 174 Kb осталось времени 00:13

разделите как-нибудь смысловые блоки, например с помощью символа | другого цвета, а то сейчас как-то оно в кучу слеплено.
Плюсанул карму. Хорошая, приятная статья и отличный сервис)
Поддерживаю комментаторов — поставил плюс, кинул в карму, добавил в избранное.

Кстати, у вас из-за хабраэффекта коллапс неожиданно не наступил? :) А то создадите новый тренд — пользоваться малоизвестными качественными сервисами и народ туда попрет! :)))
Проблема качественности резко стает актуальной с ростом посещаемости.
Без нагрузки много кто может работать нормально, а вот когда качает несколько сотен или тысяч человек (не говоря уже о десятках тысяч), то узкие места системы (особенно железо) вылазят наружу.
Мнение о том, что веб-ресурсы могут выжить только обложившись тошнотворными всплывающими банерами и прочим рекламным трешем ошибочно ибо устарело.
Приходит Эра имиджа ISP (интернет провайдеров), которые могут поддерживать подобные ресурсы на базе своего оборудования и не завешивать мерцающим мусором ссылок на порно-сайты. Просто престиж - "Мы сделали это для вас, дорогие Наши клиенты, и для всей планеты"
И как успехи у подобных благотворительных сервисов?
Я могу ответить как руководитель подобной небольшой (пака) компании - мы с радостью готовы поддерживать подобные проекты.
Ну я на вас посмотрю, когда в месяц прийдется докупать по серверу за 2500$ и за колокейшн платить тысячи 2$ или больше =)
Посмотрим на сколько в таком случае хватит альтруизма.
Под оплатой за колокейшн я имел в виду оплата каналов, ресурсов гермозоны итд
С каналом у нас всё в порядке, мы за него в любом случае платим. Хостинговая площадка у нас тоже своя, как вы наверно поняли.
Дело вовсе не в альтруизме.
Есть такое плохое слово "Совок". Оно обычно характеризует некую систему восприятия мира человеком. Между альтруизмом и пошлой псевдокоммерцией по размещению прыгающих банеров на всякие недосайты, есть понятие - престиж, который по сути является конкурентным преимуществом.
Вы никогда не задумывались над возможной цифрой рекламных сборов с главной страницы Google.com? Там нет рекламы? Может они альтруисты?
Реокмендую найти и почитать в том-же гугле что такое adsense и попробовать ввести любой коммерческий запрос, например http://www.google.com.ua/search?hl=ru&cl… и посмотреть направо.
Про прыгающие банеры никто не говорил, как правило дорогая реклама качественная сама по себе, но когда серьезную вещь пытаются сделать на голом энтузиазме, как правило этот энтузиазм со временем куда-то девается. Прийдете к пункту минимизации расходов и сразу возникнут мысли прикрыть файлообменник или сделать его прибыльным.
ОМГ!
Файлообменник это капля в море расходов. Это всё равно что оптимизировать расходы при покупке пластиковых стаканчиков для поилки в офисе где работают 10 человек!
Ещё раз повторяю - для ISP важнее имидж. И десяток другой лишних клиентов, которые подключатся к нашей сети воспользовавшись файлообменником ценнее чем идиотские разноцветные баннеры.
Я бы посоветовал сперва поинтересоваться цифрой расходов (то что я говорил + зарплата или время людей которые будут это добро поддерживать... То что вам напишут студенты или фрилансеры имида не добавит)
В общем чего тут говорить - поднимайте обменник, через какое-то время оценим маштабы развития и то на сколько это капля в море=)
Если таки сделаете что-то хоть сколько либо популярное (скажем от 10К хостов в сутки) я без проблем признаю свою неправоту. Пока что похоже на то что вы не сильно представляете во что выльется создание и поддержка хорошего обменника=)
Вы, любезный, для начала посмотрите где живёт вышеуказанный ресурс...
Какой именно вышеуказаный? Тот что в статье описывался?
Он самый.
Не хочу обижать топикстартера но сейчас его ресурс имеет не более чем академический интерес. Спасибо ему конечно что описал несколько основных вещей, думаю кому-то это будет полезно.
Но даже для слабенького и простого обменника ему еще работать и работать (cудя по архитектуре), да и затрат он практически не требует сейчас. Таких сайтов появляется достаточно много, но лишь малая часть из них перепрыгивает тот поток о котором я говорил. Я просто профессионально занимаюсь такими ресурсами (можете посмотреть в профиль), практически постоянно мониторю рынок подобных ресурсов, смотрю кто и на чем останавливается. Я не зря назвал цифру 10K, потому что сравнительно небольшое число обменников преодолевает эту цифру. А кто преодолел, можно считать что настроен более-менее серьезно.
Я живу в Киеве и тут многие провайдеры для, видимо, тех целей что и вы, хостят файловые ресурсы (большей частью варезники) бесплатно. Все вроде бы хорошо, но есть несколько прецедентов, когда крупные обменники додумались поставить к этим провайдерам свои сервера. Каналы трещали по швам и провайдеры старались побыстрее сбагрить эти сервера подальше (да и сами обменники особенно против небыли, потому что забиты каналы мешали и их работе).

Так что рекомендую сначала подождать, пока ресурс наберет популярность (если наберет) и потом рассказывать как это ненапряжно для вас. Я свой проект тоже когда-то из зарплаты кормил, пока не стало получаться что большая часть на него и уходила. Сейчас ежемесячный расход приближается к 10K$ и сомневаюсь чтобы много провайдеров могли себе позволить такое содержать чисто для имиджа.
Я не хочу вас обижать, но у нас тут не Киев.
Денег на полезные для человечества ресурсы нам не жалко! Зарплаты мы и так платим. Одним ресурсом больше не проблема.
Вы поинтересуйтесь ситуацией с интернетом в Киеве, потом переживайте за меня=)
Можно вычесть 2K за инет вообще если вы можете бесплатно хостить сервера и давать 3Гбита исхода к ним на халяву.
А сервера и сотрудники у вас там где-то где не Киев тоже халявные?
Урий! Урий! Где у него кнопка?
:)
На пузе.
Вот уж не думал что при затратах 10К$ файлшара может быть рентабельной. П.С. Не в обиду конечно, но какой у тебя пройцент пэйд-аккаунтов? Разве розетка уже деньгами платит? )))))
Розетка всегда платила деньгами=)
Премиумы приносят где-то треть дохода да и последнее время мы их нашару раздаем.
Реклама + продажа трафика остальное окупает (трафик - посетители).
Существует отличный прогресс-бар зовущийся Uber-Uploader.
Работает на PHP+Perl, фронтэнд - javascript. Плюс к этому - он беслплатный.

ссылка на сорс фордж

Я недавно интегрировал его, если какие вопросы - могу ответить.
А как на счет архитектуры вашего сервера? Стоит ли nginx как фронт-энд? Просто видел кучу случаев, когда вроде бы рабочий скрипт не работает из-за того, что nginx передает апачу файл только после полного кэширования. В описании скрипта заявлена его работа на основе аякса, а значит данные он получает от апача.
"Во первых эти программы в полной мере поддерживаю спецификацию HTTP/1.1, во вторых Apache всегда будет работать быстрее, чем интерпретируемый php" - нет. нет.
"делая это в миллион раз эффективнее чем apache" 2-3 порядка на мелких файлах. Да и то какой апач? У вас там второй стоит.. так, что если правильно сконфигурен - использует те же эвентовые механизмы работы с сокетами.
"Если предположить, что с сервера начнет одновременно качать 1000 модемщиков в 10 потоков каждый" вы же сами написали, что хотите "тяжелый апач" спрятать за акселерирующий nginx

Вообще по хорошему -
1. Апач нахуй.
2. Принимать файлы нужно чем-то своим. Не один из существующих на данный момент вебсерверов (достойных внимания nginx, lighttpd, apache, 0W и тд) не отдадут РОST стороннему приложению без предварительного полного приема. Значит с ними у вас полюбому будут лишние дисковые операции. Значит идеальный вариант - свой вебсервер или модуль к существующему.. с разбором multipart и конечно сразу застрелите и второго зайца с именем "прогресбар", отдавая его тем же сервером.
3. Отдавать nginx-ом это вполне. Конечно никаких реврайтов не надо - Внутренний локейшин и X-Accel-Redirect.
4. Прицепитесь бинарным PHP (раз так любите этот язык) как сторойнний FastCGI и им авторизуйте пользователей.
5. PHP - говно =)
Сервис очень понравился, но было бы очень удобно, если бы ссылка на скачивание давалась сразу, как только началась закачка. Интересно, почему это еще нигде не реализовано? Сегодня например хотел закачать из института 70Мб, флешки с собой не было, так бы поставил на закачку и пошел домой :)
Время ожидания ответа от сервера up.giga.su истекло.

я идиот! убейте меня кто-нибудь.
Всё - убили сервис :D
Один недостаток прогрессметера описанного в статье, так это-то, что для хранения статистики он использует APC насколько я помню. Это не удобно. http://www.webta.org/projects/uploadprog… Вот наша модификация этого экстеншиона, только теперь данные хранятся в мемкаше, о преимуществах такого подхода писать я думаю нет смысла.
Возможно, при неправильном вводе капчи стоит писать сообщение об этом, как при вводе неправильного пароля?
И еще - если после ссылки для скачивания написать /download/ то файл можно скачать и без капчи, и без пароля, что на мой взгляд, не совсем хорошо.
> если после ссылки для скачивания написать /download/ то файл можно скачать и без капчи
только в том случае, если вы ранее уже вводили captha, в противном случае такое добавление к ссылке ни к чему не приведет.
я немного опечатался. я имел ввиду /download/имя_файла. Хотя да, капчу я один раз вводил. А как же тогда быть с паролем? Ведь получается, что если я когда нибудь вводил капчу, я могу скачивать любые файлы без ввода пароля?
Да есть такой косяк, об этом я совсем забыл. Надо будет в концепции моей что-то изменить немного.
пробую. пользуюсь. пока очень доволен.

поскольку надо срочно раздать некий свой mp3 файл нескольким людям, а существующия файлопомойки бесят
В моем случае я через AJAX обращался с скрипту раз в секунду и получал актуальную информацию.

У меня через AJAX стояло обращение раз в 2 секунды, и во время всплеска загрузок (около 7 - 10 в один момент времени) Apache сильно закашлялся :)
1 секунда слишком резво будет.
по-моему, индикатор загрузки - абсолютно лишняя вещь. Дает дополнительную нагрузку на сервер, принося сомнительную пользу. Тот же ютуб просто пишет "Ваш файл загружается, подождите".
Такое исполнение мне кажется гораздо более разумным.

А то, что nginx отдает файл только после полной загрузки - так это даже в плюс ему: пока файл полностью не загрузится, не дергается обработчик сайта, не съедается память (представьте 10 человек загружающих файлы по 100мб - каждый запущеный обработчик сожрет несколько мегабайт памяти и будет висеть пока загрузка не закончится. _очень_ большие накладные расходы получаются. а если файлы заливают с модема?)
НЛО прилетело и опубликовало эту надпись здесь
Было интересно почитать комменты :)
Сам пару лет назад заморочился проблемой аплоад прогресса и всё это вылилось в xfilesharing.net
Молодец, хорошее дело сделал. Только будет тяжело конкурировать с Народным Диском от Яндекса, о котором не так давно писали на Хабре.

Кстати, заметил небольшой баг:
если в имени файла присутствует кавычка ('), то при попытке скачивания файла имя показывается со слешами (\) перед кавычкой. А после скачивания, слеши меняются на минусы.
Да, косяк. Забыл при переносе:
php_flag magic_quotes_gpc off
php_flag register_globals off
теперь все ок
Быстро фиксите :)

Кстати, я думал, что эта вся система не на PHP, а на ASP работает. Там при успешной загрузке файла перенаправляет на:

_http://up.giga.su/хххххххххх/done.asp
RewriteRule ^([0-9]+)/done\.asp /view.php?id=$1&done=1 [L]
Технически мне понятно как это сделать, а понять "зачем", пока не могу ;)
пользуюсь им уже давно и всем рекомендую.
спасибо также за объяснения принципов его работы, особенно интересно было прочесть про индикатор загрузки
сервис не работает :(
недолго мучалась старушка, уже не работает сайт.
хабраэффект?
Загнулся сайт… Еще в 2009-м. Очень часто, когда заканчивается срок домена нового сервиса, он загибается…
Спасибо большое за статью! У меня 2 вопроса, был бы очень признателен если вы ответите.
1) Какой из вариантов именно загрузки файлов на сервер более эффективный и правильный PHP $_FILE[] или Nginx module upload
2) Скажите, пожалуйста, я не совсем понял про «По этому правильнее было бы повесить nginx на отдельный адрес». Т.е допустим на site.ru стоит 1 nginx (без бакэнда) с php и занимается закачкой файлов на сервер (а пхп просто записывает в БД и т.д) а на download.site.ru другой nginx который занимается отдачей контента.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории