Сначала, все-таки посмотреть лучше в настройки хостинга, касаемо работы поддоменов
ivan-lev,
Объем блоб-бов... хммм.. 5000 примерно.
проблемы две:
1. скидать их все через boundary [не опробованная новая тропа))]
2. обработать на стороне сервера - тут конечно тоже момент.. Не разбирал запросы никогда так детально. То есть до этого момента хватало обычного глобального REQUSET.. Собрав все blobs и отправить думаю не даст хостер (если не по количеству max_post_size то по объему выделенной оперативке).. Так что думалось отправлять эти данные поэтапно..
Но так как самый простой способ - отправить постом строку, думалось брать блоб из бд конвертить в base64 и отправлять по пост (тут даже можно соединять без проблем), и принимать было бы просто - то есть забирать из REQUEST строку декодить и писать в файл например..
Милованов Ю.С,
ок, тогда, что значит в один момент времени?
то есть, пока не закачается 20 файлов отправленных. Сервер не будет обрабатывать запросы на передачу файлов?
В данном варианте подразумеваю, что после закачки любого из 20 файлов сервер примет еще один файл?
Так я перед тем как говорить что не меняется на моем хостинге - уточнил у хостера.
ivan-lev, конкретно к вам вопросов нет, уже почитал все ваши ссылки и задумался. Мат часть в порядке. Могу писать не слово хостинг а слово сервер. По части изменения стратегии (ftp) пока не хочу менять ее, так как уже есть рабочий "кейс" по передачи инфы post запросом. Может быть ftp это круто, но на моей практике - несколько раз взламывались сайты именно через ftp .. опять-таки для отправки по ftp,возможно, так как не точно не знаю, нужно будет блоб все-таки преобразовывать в файл.. Я же хотел обойтись малой кровью. В частности - отправлять post-ом файлы. В принципе думаю можно обработать blob base64 и уже отправлять как чистую строку.. А на хостин.. прошу прощения на удаленном арендованном, (возможно виртуальном) сервере, однако не выделенном, уже конвертировать base64 в файл спокойно..---------- Добавлено 28.10.2012 в 12:55 ----------kiff86,
P.S.
Отходя от темы немного, хотел спросить, так как не до конца понимаю. Вот на сервере у хостера есть ограничение, например 20 файлов за раз максимум. Вот только что значит "Максимально разрешенное количество одновременно закачиваемых файлов". То есть если я в одном запросе кидаю 20 файлов то 21 уже не пройдет. А если у меня два запроса по 20 файлов? То есть если я на стороне отправителя [клиента] сделаю 2 запроса в которых отправлю 20 файлов в разных потоках.. Заметил [просто увидел] что при передаче по ftp файлов все передачи идут последовательно.. В варианте многопоточных запросов будет ли сокращение времени загрузки того же кол-ва файлов?
beginerx, я не специалист по delphi.
Граничит = жаргон = ограничивается максимальное количество файлов для загрузки директивой - max_file_uploads (http://www.php.net/manual/ru/ini.core.php#ini.max-file-uploads) место изменения которого - PHP_INI_SYSTEM. Что на хостинге (выделенном пространстве) не допускается для редактирования.
Выделенный хостинг[в моем тут толковании] - он же, например, vps. Выделенный виртуальный сервер, на котором сам себе хозяин.
beginerx, вам интересны мои выражения для того, чтобы разобраться и подсказать или же уличить меня в чем-то?
Если первое - я готов объясниться с вами так, чтобы вы меня поняли, потому что мне важен результат, а не разглагольствование :)
beginerx, хостинг не выделенный. Ftp пока не хочется. Платформа не выбиралась. Работаем с тем, что есть.
ivan-lev, нет секретов. прога написана под delphi
ivan-lev, Да есть прога, получает блоб из бд.. Дальше эта прога отправляет пост запрос. До этого момента в пост запросе передавались только строки, сейчас встал вопрос о передачи файлов (картинок и pdf документов) Интересует именно этот момент. Прога не на php, стандартные формы запроса (wwwwww, ) это ясно.
То есть для отправки post запроса, где импортируемые данные типа blob можно с помощью сокетов? Не работал еще с сокетами, но слышал, что тема достаточно тяжелая. Вопрос сразу такой, при отправке через сокеты, я фактически получу данные в определенном типе - то есть для меня это чистый blob, который я смогу обработать например функцией - createimgfromstring ? либо делать base64_encode а потом создавать изображение..
Какие все-таки тут баталии прямо.
Все равно - сколько людей, столько и мнений. Аргументы тут я думаю не помогут. Так как на любой +/- можно найти противовес. Скорее в наше время побеждает количество положительных/отрицательных мнений. Большое количество мнений может сильно повлиять на выбор продукта. Так как выбирать приходиться в основном клиентам, не имеющим понятия, что они выбирают [только в общих чертах]. Профессионалу, мнения не столь важны. У него выбор складывается, думаю, 60% - свой опыт и только 30% мнения [10% оставим для somethig else].
Не спорю, что делать из любого продукта (платного/бесплатного) какого-то кумира не стоит. И молиться на него. Уверен, что при старте той же joomla было много позитива у тех, кто писал все в своих "кулуарных" notepad )
Из плюсов коммерческих продуктов [в частности NETCAT] - техническая поддержка. Инструмент - всегда хорошо. Но когда инструмент сложный, всегда приятно получить хороший ман/ответ по нему.
Может быть я даже поспорил бы на тему ответственности за платный продукт и его работоспособность. Это напоминает мне MS. По сути - бери линух и работай и openoffice и все такое.. Но когда "дело доходит до дела" получается, что нет гарантий, что опенсорс будет и дальше работать. По крайней мере в коммерции есть договор, диктующий обязательства сторон.
По мне,платный продукт - это гарантия, страховка. Да она не идеальна, как и все в нашем мире. Но при таком раскладе в нашем мире побеждают мелочи [в нашем случае несколько %]. И тут можно самому решить - хочешь ли ты испытать судьбу или же поспать еще часок спокойно.
В итоге - если человек слабо разбирается в разработке и управлении сайтом, плохо понимает основные процессы, но готов отдать время на их изучение - я бы рекомендовал ему платную систему и частности - NETCAT. Если человек хорошо разбирается в устройстве "web".. что ж, о вкусах не спорят. Гораздо проще написать что-то свое и работать со своим продуктом.
