|
|
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Есть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.09.2014, 21:46 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dymytry, HTTP,FTP - работают поверх TCP. SSH - обертка для обеспечения безопасности. Я бы выбирал между TCP и FTP. Как оно в деталях - тебе сюда . Хинт - при ошибке в checksum пакета протокол запрашивает его повторно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 01:33 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Лучше слать в архиве, тогда архиватор проверит при распаковке. И трафика будет поменьше. Недавно столкнулся с тем что по FTP с помощью wput иногда доходят битые файлы. Еще не разбирался, думаю проблема в отправителе, т.к. наблюдается на двух разных FTP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 07:50 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Забыл двоичный режим передачи включить?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 14:59 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovЗабыл двоичный режим передачи включить?.. хз, передается многотомный rar-архив, 10-20 файлов, битый всегда последний файл (есть копия отправленного), причем валиться так что размер совпадает, а содержимое левое, но структура rar-a соблюдена. Мистика какая-то. Может винда как-то помогает. Иногда нормально доходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 15:21 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovЗабыл двоичный режим передачи включить?.. Не было, добавил -B, понаблюдаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 15:29 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryЕсть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? все эти протоколы выстроены на базе TCP, который гарантирует целостность передачи, т.е. ты либо получишь целостную передачу, либо тебе выдадут ошибку. поэтому чексумма не нужна. Но она может быть нужна для устранения других проблем -- подмены сайта передачи, программных ошибок при передаче и т.п. 1) каким способом передать файл наиболее надежно по критерию целостности файла Любым. 2) каким способом передать файл наиболее быстро Почти всё равно. Шифрованные протоколы немного медленнее. 3) нужно ли проверять md5/checksum своим кодом Не нужно. НО можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 16:32 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TDimitry SibiryakovЗабыл двоичный режим передачи включить?.. хз, передается многотомный rar-архив, 10-20 файлов, битый всегда последний файл (есть копия отправленного), причем валиться так что размер совпадает, а содержимое левое, но структура rar-a соблюдена. Мистика какая-то. Может винда как-то помогает. Иногда нормально доходит. Это реально мистика, видимо, у тебя битый эталон. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 16:34 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dymytry3) нужно ли проверять md5/checksum своим кодом Несмотря на то что TCP и нижележащие протоколы имеют контрольные суммы, эти суммы не гарантируют что данные не битые. Там простая 16-битная сумма, даже не CRC. Повреждения в виде двух битых байтов компенсирующих друг друга не определяются. Поэтому если стоит задача гарантировать целостность переданных данных, то используйте дополнительно MD5/SHA-1 и подобные суммы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 16:46 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
И как часто кто-либо видел искажание текста хоть на этом сайте, хоть где-то ещё? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:08 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
MasterZivЭто реально мистика, видимо, у тебя битый эталон. Это бэкап бэкапа на самый черный день. Несколько больших файлов ежедневно бэкапится, копия сливается на ftp. Т.к. размер большой, то пакуется томами по 50 Мб. Вот кусок батника который копирует Код: sql 1. 2. 3. 4. 5. Т.е. копируется в два места: локальная папка COPY и на FTP Руками скачиваю с FTP и сверяю. Не сходится всегда последний. Например сегодняПравильный локально: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Было подозрение что это возможно вчерашний не затерся, нет, у вчерашнего другой размер и содержимое. Тут размер одинаковый. Содержимое чуть-чуть совпадает в первых байтах, дальше все разное. Мистика. -B сегодня добавил, может поможет, но сомневаюсь. Причем таких многотомных архивов несколько, и в каждом валится только последний том. Иногда не валится, но редко. Есть подозрение что может виндовс как-то "помогает", т.к. перед отправкой запаковка, но опять же локальная копия нормальная. В общем мистика. PS Проверяйте бэкапы. Я так два года бэкапил, недавно решил проверить распаковку. Я в шоке. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:26 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ как часто кто-либо видел искажание текста хоть на этом сайте, хоть где-то ещё? Я видел. HTTP/GET скачивание файла. Некоторые прокси могут портить файлы. Редко, но бывает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:35 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TНекоторые прокси могут портить файлы. Редко, но бывает.Ну и каким боком кривой софт к надёжности протокола? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:38 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovDima TНекоторые прокси могут портить файлы. Редко, но бывает.Ну и каким боком кривой софт к надёжности протокола? А где гарантия что кривой софт не будет участвовать? В паре случаев был виноват кэш NGINX`а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
И? От необходимости тестовых восстановлений это всё равно не освобождает, т.к. причин, по которым это восстановление не пройдёт - много и дефекты софта и железа будут явно не на первом месте. P.S. Лично мне приходилось более-менее регулярно выкладывать архивы на пару-тройку гигабайт. После того, как осознали, что 7-zip пишет в первый кусок нужную ему информацию после создания всего набора - проблем не было. Даже после того, как отказались от дробления архивов на части. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 17:56 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ? От необходимости тестовых восстановлений это всё равно не освобождает, т.к. причин, по которым это восстановление не пройдёт - много и дефекты софта и железа будут явно не на первом месте. Освобождает иногда. Если данные не являются куском чего-то более глобального (например репликации БД). В некоторых случаях достаточно чтобы получатель оперативно понял что не дошло, т.е. битого файла достаточно. Дальше сами свяжутся с отправителем и попросят повторить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 18:56 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ как часто кто-либо видел искажание текста хоть на этом сайте, хоть где-то ещё? Какая разница как часто обнаруживали? Главное что вероятность несрабатывания контроля довольно высока - 1/65536 от всех поврежденных пакетов. Что например в сетях с высоким уровнем коллизий (сотовые/вайфай) на больших файлах дает ощутимую вероятность повреждения данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:18 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyГлавное что вероятность несрабатывания контроля довольно высока - 1/65536 от всех поврежденных пакетов. Что например в сетях с высоким уровнем коллизий (сотовые/вайфай) на больших файлах дает ощутимую вероятность повреждения данных.Вероятность намного (на порядки) ниже. Существует еще проверка на канальном уровне (Ethernet-фрейм и т.п.) во всех современных средствах связи. Без таковой проверки последнее, что я видел, была модемная связь со скоростями порядка 7200-9600 (точные протоколы уже не помню). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:23 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryЕсть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? Я вспоминаю разные случаи из практики обмена бэкапами БД (нехилые кусочки по несколько терабайт) когда вобщем-то протокол не имел значения (чаще всего это был SSH!). Попробую перечислить эпик-фейлы. 1) Слали на старую Linux/RHEL32 bit машинку в которой нельзя было создавать файлы больше 2 Гб. Epic fail. Долго искали хвост проблемы. Она каким-то образом сигнализировлась как ошибка другого рода. 2) Неграмотный админ очень резко закрывал сеанс Far/SCP копирования. Zip-плагин отпускал управление очень быстро. Но в фоновом режиме FAR дописывал zip архив. Админ этого не знал. Получали по башке все включая админа. Epic fail. 3) Слали многотомный архив RAR (опция Solid включена). Где-то запоролся 1 битик в среднем томе. Пришлось перезаливать всё заново. RAR не мог восстановить трафик в середине после сбойного бита. Оригинальные архивы не сохранялись по причине нехватки места на сервере БД. 4) Zip коцал кириллицу в именах файлов, gzip/tar по неизвестным причинам вдруг отказывались распаковываться на винде. FTP сервер стоял в текстовом режиме. Были попытки протолкнуть много гигабайтный файл через корпоративную почту. Вобщем во многих этих случаях протокол связи не имел значения. Он вобщем-то свою задачу делал. Но некорректным было обращение с файлами большого размера, незнание и неумение работать с сеткой в highload, эникейство и раздолбайство многих ответственных лиц которые передавали файл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:39 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
miksoftВероятность намного (на порядки) ниже. Существует еще проверка на канальном уровне (Ethernet-фрейм и т.п.) во всех современных средствах связи. А, ну если там другая к.сумма, тогда да. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
нужно ли проверять md5/checksum своим кодом Да. Нужно. Если вы - являетесь заинтересованным лицом, то перед отправкой файла почтой, протоколом, вебом, диском или флешкой делаете openssl md5 <filename> формируйте контрольную сумму md5 и прикрепляйте ее рядом в виде текстового файла или в почтовом сообщении. Обяжите получателя сделать проверку файла при получении так-же. Такая практика распространения файлов существует например у Apache Software Foundation при публикации дистрибутивов и у многих других поставщиков опенсорца. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 19:58 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyГлавное что вероятность несрабатывания контроля довольно высока - 1/65536 от всех поврежденных пакетов. Добавь еще такую же вероятность из IP (там также сумма считается), в который оборачивается TCP-пакет. Будет 1/2^32 и умнож на вероятность сбоя в канале передачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:08 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonDymytryЕсть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? Я вспоминаю разные случаи из практики обмена бэкапами БД (нехилые кусочки по несколько терабайт) когда вобщем-то протокол не имел значения (чаще всего это был SSH!). Попробую перечислить эпик-фейлы. 1) Слали на старую Linux/RHEL32 bit машинку в которой нельзя было создавать файлы больше 2 Гб. Epic fail. Долго искали хвост проблемы. Она каким-то образом сигнализировлась как ошибка другого рода. 2) Неграмотный админ очень резко закрывал сеанс Far/SCP копирования. Zip-плагин отпускал управление очень быстро. Но в фоновом режиме FAR дописывал zip архив. Админ этого не знал. Получали по башке все включая админа. Epic fail. 3) Слали многотомный архив RAR (опция Solid включена). Где-то запоролся 1 битик в среднем томе. Пришлось перезаливать всё заново. RAR не мог восстановить трафик в середине после сбойного бита. Оригинальные архивы не сохранялись по причине нехватки места на сервере БД. 4) Zip коцал кириллицу в именах файлов, gzip/tar по неизвестным причинам вдруг отказывались распаковываться на винде. FTP сервер стоял в текстовом режиме. Были попытки протолкнуть много гигабайтный файл через корпоративную почту. Вобщем во многих этих случаях протокол связи не имел значения. Он вобщем-то свою задачу делал. Но некорректным было обращение с файлами большого размера, незнание и неумение работать с сеткой в highload, эникейство и раздолбайство многих ответственных лиц которые передавали файл. не знаю, мы очень большие файлы перекидывали rsync ом, никогда проблем не было. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:12 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Anatoly Moskovskyвероятность 1/65536 Так тоже утверждать нельзя. Надо учитывать особенность канала передачи и алгоритм проверки. Наиболее вероятная ошибка канала - неправильный прием одного бита, т.е. 0 буде принят как 1 или наоборот. Алгоритм проверки это выявит. Вероятность двухбитовой ошибки = вероятность однобитовой в квадрате, трехбитовой - в кубе и т.д. Сколько бит должно быть искажено чтобы контрольная сумма совпала? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:15 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
MasterZivне знаю, мы очень большие файлы перекидывали rsync ом, никогда проблем не было. У заказчика чаще всего не было rsync. Да и разговор не вёлся в этом ключе. Нас просто ставили перед фактом что будет так или эдак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:26 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TДобавь еще такую же вероятность из IP (там также сумма считается), в который оборачивается TCP-пакет. Будет 1/2^32 и умнож на вероятность сбоя в канале передачи. В IP сумма только заголовка, без данных. Но выше уже сказали что в канальном уровне есть своя сумма. Я посмотрел, в ethernet вроде вариация CRC-32 - это снимает все вопросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:43 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Anatoly MoskovskyЧто например в сетях с высоким уровнем коллизий (сотовые/вайфай) на больших файлах дает ощутимую вероятность повреждения данных."Но есть ньюанс" - транспортный уровень этих сетей обеспечивает собственное обнаружение ошибок, которое адекватно и уровню помех и уровню коллизий. P.S. Если кто забыл, то размер сектора CD - 2532 байта. Именно для того, чтобы оставалось место для кода коррекции ошибок. И уж если диск не читался, то, обычно, узнавали об этом из системной ошибки, а не по контрольным суммам, которые параноики могли записать вместе с данными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:52 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TВероятность двухбитовой ошибки = вероятность однобитовой в квадрате, трехбитовой - в кубе и т.д.Грубое заблуждение - для типичного канала/носителя характерны именно групповые ошибки. В радиоэфире это происходит потому, что длительность импульсных помех превышает период квантования, на компакт-дисках царапины далеки от точечных и т.д. и т.п. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:56 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Насколько я разбираюсь CD позволяет иметь процент ошибок и при этом нормально звучать/читать файлы. Таковы начальные условия. Материал такой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 20:57 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Точно такой же "материал" и Ethernet. Коррекцию ошибок он, конечно, не умеет, то контроль длины и CRC32 пакета - делает. Точно так же у модемов появился сначала MNP2 (символьный, мог эмулироваться программно), затем MNP4 (битовый поток на аппаратном уровне) и, в конечном итоге - стандарт в виде V.32 и более старших. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 21:02 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Попробуем обобщить. TCP и лежащие над ним протоколы с высокой вероятностью передадут файл верно тк имеют встроенные проверки. Однако возможны погрешности 1) из-за разного софта, роутеров, особенностей сетей итд 2) некоторая вероятность ошибки в TCP Т.о. проверять файл все равно надо. Собственно для этого при скачивании openSource часто пишут checksum. Согласны? Остается только одно недоразумение: почему авторы протоколов не добавили в них эту простейшую проверку. То есть почему FTP не проверяет checksum и md5 хэш файла. Логично сделать проверку на самом высоком уровне. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 22:07 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryТо есть почему FTP не проверяет checksum и md5 хэш файлаFTP появился на 20 лет раньше MD5. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 22:37 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryОднако возможны погрешности 1) из-за разного софта, роутеров, особенностей сетей итд 2) некоторая вероятность ошибки в TCP Т.о. проверять файл все равно надо. Собственно для этого при скачивании openSource часто пишут checksum. Согласны?Нет. То, что меня в любой момент может сбить автомобиль - не повод всегда оставаться дома. Контрольные суммы, безусловно, выкладываются часто, но это далеко не общепринятая практика. Статистики, которая позволила бы учесть фактическое использование контрольных сумм - вообще не существует.Остается только одно недоразумение: почему авторы протоколов не добавили в них эту простейшую проверку.Зачем??? Если BitTorrent или ZFS интенсивно используют различные проверки, это ещё не повод втыкать сложные контрольные суммы в каждую дырку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.09.2014, 23:09 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Точно такой же "материал" и Ethernet. В отличие от Ethernet, CDDA использует технологию "перемежения" битов в группе блоков. Это позволяет "распылять" групповую ошибку на несколько блоков и передавать ее на декодер кодов коррекции ошибок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 00:46 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryОстается только одно недоразумение: почему авторы протоколов не добавили в них эту простейшую проверку. То есть почему FTP не проверяет checksum и md5 хэш файла. Логично сделать проверку на самом высоком уровне. Первые сетевые протоколы создавались в те времена когда производительность мерялась в несколько мегагерц и объемы передаваемого трафика - в килобайтах. А такие суровые хеш-функции как SHA-2-(512) были уже продуктом лабораторий криптографии. И появились уже в двухтысячных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 00:52 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovЕсли BitTorrent или ZFS интенсивно используют различные проверки, это ещё не повод втыкать сложные контрольные суммы в каждую дырку. В последнее время пошла мода портировать всё и вся от PC на мобилы. Но здравая инженерная мысль бъёт по рукам. Любое bluetooth устройство типа гарнитуры - это в первую очередь экономное устройство. В его спецификацию включены опции снижения энергопотребления. Для миниатюрных устройств даже существует класс криптографии (т.н. эллиптические кривые) специально созданные для снижения "прожорливости" вычислений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 01:00 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TDimitry SibiryakovЗабыл двоичный режим передачи включить?.. хз, передается многотомный rar-архив, 10-20 файлов, битый всегда последний файл (есть копия отправленного), причем валиться так что размер совпадает, а содержимое левое, но структура rar-a соблюдена. Мистика какая-то. Может винда как-то помогает. Иногда нормально доходит. Попробуйте отключить антивирус - однажды столкнулся, но название антивируса не знаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 02:45 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonВ отличие от Ethernet, CDDA использует технологию "перемежения" битов в группе блоковТолько потому, что у привода нет возможности перезапросить исходный блок. Но дело даже не в этом - эзернет считает CRC32, а CD определяет технологию коррекции ошибок исходя из надёжной передачи данных на следующий уровень. Таким образом, в сегодняшних условиях, мы имеем надёжный транспорт над любой доступной средой передачи. Времена, когда в распоряжении протокола мог оказаться канал без контроля ошибок передачи (V.22(bis)) - давно прошли. Вот там - да, ошибки сыпались "тока в путь". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 09:11 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
По протоколам: plain TCP - сразу нафиг. Вы же не планируете придумывать свой, ни с чем не совместимый и трудно-отлаживаемый бинарный протокол ? FTP - устарел, умер и мумифицировался. Этому старичку давно пора на покой - в мир вечно живых rsh, nntp и прочих мамонтов. Оно использует два соединения (из-за чего может плохо проходить через нат), передает открытым текстом не только тело файла, но и команды вместе с логинами/паролями, да ещё и вносит путаницу с двумя режимами работы, что тоже частенько становится причиной ошибок. HTTP - идеален, если не требуется сохраняться приватность данных. Протокол HTTP также не шифрован, шифрование прикручивается дополнительно средствами SSL. SSH - для бэкапов самое оно, особенно в варианте авторизации по ключам. Мой вам добрый совет - сделайте так, чтобы бэкап-сервер сам заходил на сервер БД за бэкапом, а не сам сервер БД лез по ссш на хранилище бэкапов и что-то туда заливал. Что касается проверок - все эти встроенные проверки в протоколы позволяют проверить только лишь корректность процесса передачи. Для бэкапов же может быть актуальна проверка целостности любой ранее сохраненной копии. Так что sha256sum * > Hashes.sha256 на каждом сервере, и копируйте его вместе с отсальными архивами. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла SSH / HTTP 2) каким способом передать файл наиболее быстро Пофиг 3) нужно ли проверять md5/checksum своим кодом Для бэкапов - обязательно, используйте утилиту sha256sum (есть под все ОС) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 10:03 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Комменты в теме ЖГУТ! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2014, 13:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
x1ca4064Dima Tпропущено... хз, передается многотомный rar-архив, 10-20 файлов, битый всегда последний файл (есть копия отправленного), причем валиться так что размер совпадает, а содержимое левое, но структура rar-a соблюдена. Мистика какая-то. Может винда как-то помогает. Иногда нормально доходит. Попробуйте отключить антивирус - однажды столкнулся, но название антивируса не знаю. Отключал. Не помогает. У меня MS Essential, не замечал чтобы он гадил. Заменил FTP на SSH, т.е. вместо wget передавал pscp. Всё дошло. Битых файлов нет. Буду наблюдать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 07:02 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dymytry1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро HTTP малоудачен и с точки зрения оверхеда, и с точки зрения надёжности. TCP слишком низкого уровня, придётся много делать самому. Практически стоит выбирать между FTP и SFTP. Dymytry3) нужно ли проверять md5/checksum своим кодом Ни один checksum не даёт абсолютной гарантии, поэтому своя проверка не помешает. Также она поможет от ошибок в используемом софте. Dimitry SibiryakovЗабыл двоичный режим передачи включить?.. Да многое может быть. Скажем, в некоторых случаях на ftp обрывается передача, а получатель тут же радостно забирает неготовый файл до того, как отправитель дошлёт остаток. Basil A. SidorovИ как часто кто-либо видел искажание текста хоть на этом сайте, хоть где-то ещё? Регулярно. По ZMODEM-у, например, с 32-битными контрольными суммами, у меня выпадало два-три десятка файлов в год (то есть пришёл файл, контрольные суммы совпадают, а попытка распаковать даёт ошибку архиватора). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 11:30 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerРегулярно. По ZMODEM-у, например, с 32-битными контрольными суммами, у меня выпадало два-три десятка файлов в год (то есть пришёл файл, контрольные суммы совпадают, а попытка распаковать даёт ошибку архиватора).И где сейчас найти zmodem? И даже если кто-то продолжает пользоваться dialup-ом, где гарантия, что файлы бились при передаче, а не при упаковке кривыми руками? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:23 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerHTTP малоудачен и с точки зрения оверхеда, и с точки зрения надёжностиМожно поподробнее с этого места? А то мне аж попкорн захотелось достать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:29 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ где сейчас найти zmodem? А зачем искать? Будете утверждать, что CRC32 в нём какой-то особый и кардинально отличается от других контрольных сумм в других местах? Basil A. Sidorovгде гарантия, что файлы бились при передаче, Эти файлы упаковывались не Вашими руками, а неплохо написанными роботами, и распространялись по снежинке. Когда один файл ко всем приехал нормально, а на одном из получателей оказался побитым, нетрудно догадаться, что он побился при передаче. Хотя, конечно, никто не помешает и дальше придумывать всякие левые версии, лишь бы хватило твёрдости лба не признавать правды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:34 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Тут как-то уж сильно ругают FTP. Давайте позащищаем что-ли. Двухсокетность. Неумение работать за Nat (если я верно понял). И открытость передачи паролей. А в целом? Оки доки. И набор команд пошире чем у http. Удалять по крайней мере можно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:35 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovsoftwarerHTTP малоудачен и с точки зрения оверхеда, и с точки зрения надёжностиМожно поподробнее с этого места? А то мне аж попкорн захотелось достать. Хорошее желание, лучше жевать, чем говорить. А за этим делом откройте RFC и прочитайте, что в случае http с ненулевой вероятностью вообще не удастся определить, передан ли файл до конца или оборван на середине. Пользователи всяких качалок типа ReGet-а хорошо помнят такие проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:40 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonДвухсокетность. Неумение работать за Nat (если я верно понял). Есть пассивный режим, прекрасно пропускается натом, но не файрволами с кучей запретов исходящих соединений по номерам портов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:47 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonДвухсокетность. Неумение работать за Nat (если я верно понял). Есть пассивный режим, прекрасно пропускается натом, но не файрволами с кучей запретов исходящих соединений по номерам портов. Напомню, что топикстартер ищет способ передать файл по сети. Контролируемой, я так понимаю; у него нет или во всяком случае не заявлено задачи работать с произвольными отправителями-получателями за всякими заборами и интернетами. Поэтому не думаю, что подобные ограничения должны существенно влиять на его выбор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 14:57 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerА зачем искать? Будете утверждать, что CRC32 в нём какой-то особый и кардинально отличается от других контрольных сумм в других местах?Я повторю свою позицию: "на сегодняшний день IP-сети работают поверх принципиально надёжного транспорта". Когда вы найдёте в этом утверждении контрольные суммы - можно обсудить надёжность CRC32.softwarerХотя, конечно, никто не помешает и дальше придумывать всякие левые версии, лишь бы хватило твёрдости лба не признавать правды.У меня есть представительная статистика. Система регионального уровня, где не было собственной системы контроля целостности, а данные передавались по HTTP в упакованном в виде (deflate). Ошибки распаковки давали бы вполне конкретную ошибку во вполне конкретном месте сервере приложений. Сетевые ошибки на сайте системы были обычным делом делом - read/write timeout, connection reset by peer и всё такое, а вот на сервере приложений ошибок распаковки не было. За все шесть лет, которые я работал. По этой причине исторические экскурсы не очень интересны: первое, что я сделал подключившись к местной BBS модемом V.22bis/None - скачал MNP-эмулятор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:01 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerКонтролируемой, я так понимаю; у него нет или во всяком случае не заявлено задачи работать с произвольными отправителями-получателями за всякими заборами и интернетами. Поэтому не думаю, что подобные ограничения должны существенно влиять на его выбор. Обратного тоже не заявлено. К чему вообще эта попытка думать за ТС? Я просто поправил утверждение что нат мешает работе FTP. Он не мешает. Запреты на файрволе решаются админом который их поставил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:09 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerDima Tпропущено... Есть пассивный режим, прекрасно пропускается натом, но не файрволами с кучей запретов исходящих соединений по номерам портов. Напомню, что топикстартер ищет способ передать файл по сети. Контролируемой, я так понимаю; у него нет или во всяком случае не заявлено задачи работать с произвольными отправителями-получателями за всякими заборами и интернетами. Поэтому не думаю, что подобные ограничения должны существенно влиять на его выбор. Вспомните. Любые it-работы на аутстафах, конмадировках, выездах к заказчику начинаются с того что вы распаковываете ноут. Включаете. И вопрошаете: - А где у васт тут паблик FTP-шничек с дистрами дровами и прочим? Вам отвечают. - А вот тут дескыть на xxx.xxx.xxx.xxx. Логин анонимос пароль - пустой. Profit. Ничего практичнее еще не было придумано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:11 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerА за этим делом откройте RFC и прочитайте, что в случае http с ненулевой вероятностью вообще не удастся определить, передан ли файл до конца или оборван на середине. Пользователи всяких качалок типа ReGet-а хорошо помнят такие проблемы.Качалки, которые не в состоянии определить допустимость многопоточного скачивания, никак не могут быть проблемой протокола. P.S. Когда меня запарила работа ftp, на который приходилось выгружать дампы базы для анализа разработчиками, я начал выкладывать их на нашем сайте и передавать коротенькое: Код: plaintext 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:15 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovКачалки, которые не в состоянии определить допустимость многопоточного скачивания, никак не могут быть проблемой протокола Многопоточность тут не при чём. Проблемой протокола является допустимость молчаливого завершения сеанса как признака успеха. И оверхед в 25% тоже является не то чтобы проблемой, но недостатком протокола. Basil A. Sidorovя начал выкладывать их на нашем сайте и передавать коротенькое: Угу :) То есть фактически начали руками закрывать дырку :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:21 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerПроблемой протокола является допустимость молчаливого завершения сеанса как признака успеха. Допустимо, но так же допустимо серверу при отправке указать в HTTP-заголовке размер передаваемых данных. Тогда клиент проконтролирует размер принятого и сделает вывод: успех или обрыв. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:31 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TДопустимо, но так же допустимо серверу при отправке указать в HTTP-заголовке размер передаваемых данных. Именно что "допустимо", а не "обязательно". В результате чего регулярно попадаются реализации, которые этого не делают. Писать руками свою реализацию http меня как-то ломает, а рисковать тем, что в результате обновления библиотеки или перехода на другой веб-сервер или чего-то подобного приложение вдруг начнёт пропускать сломанные файлы - я бы не стал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:37 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerМногопоточность тут не при чём. Проблемой протокола является допустимость молчаливого завершения сеанса как признака успехаТолько в отсутствии заголовка Content-Length. Но, опять-таки, если качалка не отличает штатное и нештатное закрытие сокета - это не проблемы протокола. Даже если передача потоковая - существует Content-Range, который может использоваться как самостоятельно, так и в комбинации с Content-Length.И оверхед в 25% тоже является не то чтобы проблемой, но недостатком протоколаКак вы собрались получить хоть процент накладных расходов на передаче хоть сколько-нибудь крупных файлов?Угу :) То есть фактически начали руками закрывать дырку :)Какую дырку? Мне в любом случае требовалось сообщать где лежит файл, как он называется и какой у него размер. P.S. Единственное преимущество ftp - существование "стандартного ftp-клиента". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerИменно что "допустимо", а не "обязательно". В результате чего регулярно попадаются реализации, которые этого не делают.Вы опять путаете протокол с кривыми веб-приложениями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:46 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerDima TДопустимо, но так же допустимо серверу при отправке указать в HTTP-заголовке размер передаваемых данных. Именно что "допустимо", а не "обязательно". В результате чего регулярно попадаются реализации, которые этого не делают. Писать руками свою реализацию http меня как-то ломает, а рисковать тем, что в результате обновления библиотеки или перехода на другой веб-сервер или чего-то подобного приложение вдруг начнёт пропускать сломанные файлы - я бы не стал. Не надо писать свою реализацию. Просто HTTP не заточен на работу с файлами, точнее если качать именно файл GET запросом, то размер в заголовке будет, а если на стороне сервера не реальный файл, а результат работы скрипта выдаваемый за файл, то сервер размер не добавит в заголовок (он его не знает), скрипт должен сам об этом позаботится раз эмулирует передачу файла. Скрипт - творчество разработчика конкретного сайта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:55 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovP.S. Когда меня запарила работа ftp, на который приходилось выгружать дампы базы для анализа разработчиками, я начал выкладывать их на нашем сайте и передавать коротенькое: Код: plaintext 1. 2. 3. 4. А разве нельзя было уведомлять разработчиков об изменении дампа по почте? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 15:59 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonА разве нельзя было уведомлять разработчиков об изменении дампа по почте?У разработчика есть, условно говоря, баг-трекер. У нас возникает проблема, мы её смотрим, сообщаем всю необходимую информацию и получаем ответ: "Нужен дамп". При этом в работе может находится ещё пара-тройка инцидентов с таким же первоначальным откликом. Об изменении какого дампа мы должны уведомить разработчика? И почему мылом? И даже если уведомить - почему я должен присылать листинг ftp-каталога вместо http-ссылки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:06 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonА разве нельзя было уведомлять разработчиков об изменении дампа по почте? Можно, но так удобнее. Я также делаю. Залил на свой FTP и кинул в аську http-ссылку. Тем более что основная часть переписки в аське. Да и почта нынче очень ненадежный канал из-за всяких-разных вирусо-, спамо-анализаторов и прочих самодельных правил фильтрации, в т.ч. по размеру. Попробуй отправь EXE на ящик @gmail.com Получится только в архиве и с паролем. Тоже самое у некоторых есть в корпоративной почте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:07 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovsoftwarerИменно что "допустимо", а не "обязательно". В результате чего регулярно попадаются реализации, которые этого не делают.Вы опять путаете протокол с кривыми веб-приложениями. Не путаю. Протокол допускает кривые реализации, и это именно его недостаток. Кривые реализации регулярно встречаются, это реальная проблема. Из-за этой проблемы я не стал бы выбирать HTTP, поскольку решение получается не слишком надёжным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:10 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Кстати. Кто-нибудь использовал в своих задачах HTTP методы PUT, DELETE (не в Rest-сервисах а вообще) ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:18 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerНе путаю. Протокол допускает кривые реализации, и это именно его недостаток. Кривые реализации регулярно встречаются, это реальная проблема. Из-за этой проблемы я не стал бы выбирать HTTP, поскольку решение получается не слишком надёжным.Поскольку альтернативой http выставляется ftp, то о динамическом контенте речи, наверное, не будет? А если не будет, то и Apache httpd и Apache Tomcat формируют Content-Length для статического контента без дополнительного участия горе-программиста. Насколько я могу судить по документации nginx - он делает точно так же. IIS, в последнее время как-то не попадался, но "меня опять терзают смутные сомнения", что и он делает точно также. Кривые http-серверы, безусловно существуют и лично я даже читал о проблеме работы одной такой поделки и тогда же продемонстрировал, что у индейца нет "этой странной проблемы". Вот буквально за четверть часа собрал то, что не работало у вопрошавшего и выложил лог успешной работы клиента. Т.е. ваш пример из серии: "А что будет, если и клиент и сервер находятся за NAT-ами, которые не имеют поддержки FTP?". Да, такие ситуации бывают и мне даже доводилось на них попадать, но к технологии это никак не относится. Это относится к вполне конкретному рукопопию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:26 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonКто-нибудь использовал в своих задачах HTTP методы PUT, DELETEТолько CONNECT в виде (готовой) реализации socks-прокси. Но это было лет десять назад. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:28 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Так что? FTP рулит. FTP+текстовый файлик с MD5 решает все проблемы индейцев. И топик можно закрыть. (Шутка) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:30 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovПоскольку альтернативой http выставляется ftp, то о динамическом контенте речи, наверное, не будет? По сути - нет, ТС хотел отправлять файл. По форме - хз, я встречал случаи, когда статический контент в силу неких соображений изображали "псевдодинамическим". Basil A. SidorovА если не будет, то и Apache httpd и Apache Tomcat формируют Content-Length для статического контента без дополнительного участия горе-программиста. Насколько я могу судить по документации nginx - он делает точно так же. Я несколько лет не пользовался http-качалками, может, ситуация изменилась. Пока пользовался - не возвращавшие content-length наблюдал регулярно. Конкретными софтинами и версиями не интересовался. Факт в том, что либо нужно лезть в исходники чужой софтины и чётко проверять, что "точно всегда", либо есть шанс, что в какой-то момент оно тихо уйдёт. Ну например - просто от балды - если файлы переедут на сетевой диск. И никто не заметит, пока не грянет. А при обновлении версий итп риск соответственно растёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:36 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerПротокол допускает кривые реализации, и это именно его недостаток. Кривые реализации регулярно встречаются, это реальная проблема. Из-за этой проблемы я не стал бы выбирать HTTP, поскольку решение получается не слишком надёжным.И, кстати, замените фразу "HTTP протокол" на "реализация SQL-стандарта" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:36 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerПротокол допускает кривые реализации, и это именно его недостаток. Не делая своей серверной части (сайта или веб-приложения) полноценный обмен файлами по HTTP просто невозможен. Классическая настройка безопасности сервера дает пользователю (под которым работает веб-сервер) права только чтения к папке сайта. Т.е. ни веб-сервер, ни скрипт им запущенный при всем желании файл не запишет. Поэтому HTTP не заточен на прием файлов сервером (чтобы они были именно файлами на сервере). Поэтому содержимое файлов заливаются в БД, а потом идет эмуляция скачивания файла. Ну а кривая эмуляция это не кривой веб-сервер. У меня есть такой http-файлообменник. Лично я сделал сохранение файлов как файлов, дал права записи на папку. Сохраняет скрипт. Работает стабильно. Обычный хостинг сайтов, за вэб-сервером следит провайдер. Несколько раз менялся хостинг, проблем нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:37 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovsoftwarerПротокол допускает кривые реализации, и это именно его недостаток. Кривые реализации регулярно встречаются, это реальная проблема. Из-за этой проблемы я не стал бы выбирать HTTP, поскольку решение получается не слишком надёжным.И, кстати, замените фразу "HTTP протокол" на "реализация SQL-стандарта" И что? Если хотите, без проблем нагуглите на форуме моё мнение по поводу ANSI SQL. Например, я неоднократно писал про возможность написать на ANSI SQL скрипт, который, будучи выполнен на трёх реально существующих СУБД, даст три разных результата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:37 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerЯ несколько лет не пользовался http-качалками, может, ситуация изменилась. Пока пользовался - не возвращавшие content-length наблюдал регулярноОно и сейчас может "регулярно наблюдаться". Просто потому, что очередной гений программирования решил самостоятельно формировать HTTP-заголовки. Я просто повторю, что это ни разу не проблема протокола - с дуру можно и дуб сломать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:39 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerИ что?При всех недостатках, обычно, не от SQL отказываются, а решают конкретные проблемы конкретной реализации. Причём по разному решают, т.к. серебряную пулю никто, вроде, не отлил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonКстати. Кто-нибудь использовал в своих задачах HTTP методы PUT, DELETE (не в Rest-сервисах а вообще) ? Вроде бы они по дефолту игнорируются вэб-серверами, т.к. это большая дыра: PUT my.php а потом GET my.php. Бинго :) По крайней мере из браузера HTML-формой PUT не пошлешь. Превращается в GET, только сервером или браузером - не разбирался. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:45 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TНе делая своей серверной части (сайта или веб-приложения) полноценный обмен файлами по HTTP просто невозможен. Классическая настройка безопасности сервера дает пользователю (под которым работает веб-сервер) права только чтения к папке сайта.Вот только не надо путать настройки веб-сервера и его доступ к файловой системе.Т.е. ни веб-сервер, ни скрипт им запущенный при всем желании файл не запишет. Поэтому HTTP не заточен на прием файлов серверомТо, что криворукие программисты не освоили POST - их личная проблема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:46 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovПри всех недостатках, обычно, не от SQL отказываются, а решают конкретные проблемы конкретной реализации. Отказываются от ANSI SQL и работают на конкретной, хорошо и чётко специфицированной реализации. Именно так. Разница здесь в том, что потребовать "база Oracle таких-то версий" в общем нетрудно, а вот надеяться на то, что HTTP будет реализации именно "Apache 2.2" я бы не стал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:48 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovТ.е. ни веб-сервер, ни скрипт им запущенный при всем желании файл не запишет. Поэтому HTTP не заточен на прием файлов серверомТо, что криворукие программисты не освоили POST - их личная проблема. Не думаю что POST является эквивалентом PUT. По крайней мере POST предполагает "логику" обработки (трансформации) пересылаемых данных на сервере (формочка). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 16:54 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonНе думаю что POST является эквивалентом PUTМетод POST может быть эквивалентом PUT, эквивалентом GET и вообще чего угодно.По крайней мере POST предполагает "логику" обработки (трансформации) пересылаемых данных на сервере (формочка).Есть такая логическая ошибка, как преждевременное обобщение. Выгрузка файлов через форму в браузере - стандарт для другой стороны. Да, требующий определённой поддержки на стороне сервера. И, да - использующий метод POST. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:01 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerBasil A. SidorovА если не будет, то и Apache httpd и Apache Tomcat формируют Content-Length для статического контента без дополнительного участия горе-программиста. Насколько я могу судить по документации nginx - он делает точно так же. Я несколько лет не пользовался http-качалками, может, ситуация изменилась. Пока пользовался - не возвращавшие content-length наблюдал регулярно. Конкретными софтинами и версиями не интересовался. Факт в том, что либо нужно лезть в исходники чужой софтины и чётко проверять, что "точно всегда", либо есть шанс, что в какой-то момент оно тихо уйдёт. Ну например - просто от балды - если файлы переедут на сетевой диск. И никто не заметит, пока не грянет. А при обновлении версий итп риск соответственно растёт. Наверное вся беда в том что Content-Length является опциональным атрибутом. Если он есть - хорошо. Нет - тоже ладненько. А качалки да.... помню. Как-же. Правда в последнее время интернеты стали быстрее раз в 10-100. Обычное качание браузером с опенсорцных порталов вполне себе быстро. Скачал zip. Прочекал zip-средствами. Вроде всё ОК. А всякий контрафакт качаю из русских торрентов. Настала эпоха Торов, Пир-2-пиров и прочих протоколов самообнаружения контента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:02 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovmaytonНе думаю что POST является эквивалентом PUTМетод POST может быть эквивалентом PUT, эквивалентом GET и вообще чего угодно.По крайней мере POST предполагает "логику" обработки (трансформации) пересылаемых данных на сервере (формочка).Есть такая логическая ошибка, как преждевременное обобщение. Выгрузка файлов через форму в браузере - стандарт для другой стороны. Да, требующий определённой поддержки на стороне сервера. И, да - использующий метод POST. Избыточно как-то. Всё равно http проигрывает ФТП в плане простоты файлообмена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:04 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerРазница здесь в том, что потребовать "база Oracle таких-то версий" в общем нетрудно, а вот надеяться на то, что HTTP будет реализации именно "Apache 2.2" я бы не стал.Там, где можно потребовать версию СУБД ничуть не сложнее потребовать и версию сайта. Но дело даже не в этом. Проблемы, на которые вы ссылаетесь, могут быть только проблемой "реально наколенной поделки". С таким же успехом вы можете наткнуться на горе-админа у которого "oracle по утрам не откликается". Только с вероятностью на порядок большей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:05 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovDima TНе делая своей серверной части (сайта или веб-приложения) полноценный обмен файлами по HTTP просто невозможен. Классическая настройка безопасности сервера дает пользователю (под которым работает веб-сервер) права только чтения к папке сайта.Вот только не надо путать настройки веб-сервера и его доступ к файловой системе. Я писал про те настройки прав которые обычно делаются по дефолту на хостингах сайтов. Basil A. SidorovТ.е. ни веб-сервер, ни скрипт им запущенный при всем желании файл не запишет. Поэтому HTTP не заточен на прием файлов серверомТо, что криворукие программисты не освоили POST - их личная проблема. Поделись выпрямителем :) Как используя только POST и свой скрипт на стороне сервера сохранить файл на сервере так чтобы затем его скачать GETом? Чтобы файл реально появился и его было видно в т.ч. по FTP. На стандартном unix-хостинге сайтов, которых полно предлагается сегодня. Виндовых не надо, возможно там это можно, не сталкивался. Вариант: зайти по FTP и дать права на запись в папку не использовать. Его я знаю, и при переезде сайта каждый раз забываю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:06 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovПроблемы, на которые вы ссылаетесь, могут быть только проблемой "реально наколенной поделки". Не думаю. У меня ведь не было задачи искать такие поделки, я просто качал нужные мне файлы с самых обычных сайтов в интернете. Крайне сомневаюсь, что каждый, допустим, пятнадцатый сайт крутится на "реально наколеночной поделке", это статистически невероятно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:09 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonИзбыточно как-тоЧто значит избыточно??? Стандарту сто лет в обед, реализован во всех браузера и, надо полагать, во всём, что используется для веб-программирования на стороне сервера.Всё равно http проигрывает ФТП в плане простоты файлообмена.FTP выигрывает только наличием "стандартного клиента". Но было бы странно ожидать иного от протокола, реализующего одну-единственную задачу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:10 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovmaytonИзбыточно как-тоЧто значит избыточно??? Стандарту сто лет в обед, реализован во всех браузера и, надо полагать, во всём, что используется для веб-программирования на стороне сервера.Всё равно http проигрывает ФТП в плане простоты файлообмена.FTP выигрывает только наличием "стандартного клиента". Но было бы странно ожидать иного от протокола, реализующего одну-единственную задачу. Давай вернёмся в топику. Автор ищет способы как "передать файлы" по сети. Я ему предлагаю серебрянную пулю. FTP. Дешево. Сердито. В 99.9 случаев работает. Вопросы файрвольности и безопасности пока не рассматриваем. Ведь автор об этом не говорит. Его интересует пока только надёжность. Надёжно? Надежно. Оборвалось соединение? Есть докачка. Клиентов полно. Симметричность. ФТП может как принимать так и отдавать контент. Лаконичность. Я вижу только файлы и каталоги. Без рекламы и джава скриптов. А принять контент в HTTP на уровне протокола по дефолту - никак. Не заложены возможности приёма. Кодить надо. Писать свои CGI скриптики. Со всеми вытекающими. PUT по дефолту заблочен как мы выяснили. Разблочить надо. Да и разблочив еще поискать клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:16 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TПоделись выпрямителем :)Для Java называется servlet-api. Требует вдумчивого изучения RFC, документации конкретного сервлет-контейнера и админки хостера. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:16 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonИзбыточно как-то. Всё равно http проигрывает ФТП в плане простоты файлообмена. Проигрывает до тех пор пока не захочешь реализовать что-нибудь нестандартное. Например отправитель кроме выкладки файла задает его получателей. В случае с FTP придется завести каждому по папке и при передаче положить каждому по копии файла. В HTTP достаточно сохранить один файл и сделать в базе запись что получатель должен скачать такой-то файл, а при входе получателя - показать все что ему предназначается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:16 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovDima TПоделись выпрямителем :)Для Java называется servlet-api. Требует вдумчивого изучения RFC, документации конкретного сервлет-контейнера и админки хостера. Админку хостера исключаем, т.к. это тоже самое что по FTP зайти фарой и галку поставить. Пример на Java можно? Хоть я его и не знаю, но думаю осилю портирование на PHP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:23 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryЕсть задача: передать файл по сети. Есть выбор протоколов для этого: plain TCP, SSH, FTP, HTTP итд Многие из этих протоколов реализуют разные проверки на правильность передачи данных. Например TCP проверяет checksum пакетов, SSH вычисляет hash. Вопросы: 1) каким способом передать файл наиболее надежно по критерию целостности файла 2) каким способом передать файл наиболее быстро 3) нужно ли проверять md5/checksum своим кодом ? 1) SSH File Transfer Protocol (SFTP) Проерять ничего не надо, целостность и безопасность гарантируются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:31 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonА принять контент в HTTP на уровне протокола по дефолту - никак.Я вас умоляю ... В рамках Servlet API: Код: java 1. 2. 3. Всё - поток данных от клиента вам доступен и вы можете делать с ним всё, что угодно. От записи в dev/nul до эзотерических трансформаций. Для разбора форм есть Apache commons-fileupload, если уж приспичило делать вариант, совместимый с браузером.Да и разблочив еще поискать клиента. wput , браузер, да хоть ab из комплекта всё того же Apache httpd. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:32 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TПример на Java можно? Хоть я его и не знаю, но думаю осилю портирование на PHP.Смысл? На PHP, которого я не знаю, есть всё, что вам нужно. Только API другое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:33 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonДавай вернёмся в топику. Автор ищет способы как "передать файлы" по сети. Я ему предлагаю серебрянную пулю. FTP. Дешево. Сердито. В 99.9 случаев работает. Вопросы файрвольности и безопасности пока не рассматриваем. Автор много не договаривает. Например где он хочет разместить FTP-сервер? за натом нельзя, из-за ната только FTP-клиент может работать. Получается нужен хостинг, т.е. уже не дешево, т.е. не бесплатно. HTTP сервер можно за нат поселить и порт замапить. т.е. размещение бесплатно. PS Автор пропал уже давно, надо сворачивать писькомерянье ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:33 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovmaytonА принять контент в HTTP на уровне протокола по дефолту - никак.Я вас умоляю ... В рамках Servlet API: Код: java 1. 2. 3. Всё - поток данных от клиента вам доступен и вы можете делать с ним всё, что угодно. От записи в dev/nul до эзотерических трансформаций. Для разбора форм есть Apache commons-fileupload, если уж приспичило делать вариант, совместимый с браузером.Да и разблочив еще поискать клиента. wput , браузер, да хоть ab из комплекта всё того же Apache httpd. Ну екарный пельмень! Это решение связано с разработкой! Разработкой ПО. Здесь уже планка требований поднята. Хотя-бы тем что нужно ставить джаву и сервлет-контейнер! Эх вы... Как мои студенты. Еще-бы Spring фреймворк предложили. Я ищу простых решений. Как угол дома. Я-то жду. Думаю кто-то вспомнить что еще есть NetCat... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovВсё - поток данных от клиента вам доступен и вы можете делать с ним всё, что угодно. От записи в dev/nul до эзотерических трансформаций. В PHP он тоже доступен. Там это содержимое переменной. Суть в том что я не могу создать файл чтобы записать туда это содержимое, т.к. таковы дефолтные настройки прав доступа к файловой системе. Надо просто их предварительно поменять, т.е. дать права на запись. Заходим фаром по FTP, встаем на папку, Ctrl+A и доставляем недостающие галки. Может на Java-хостингах по другому принято права доступа настраивать, как на PHP+MySQL. Проехали. Мир. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:42 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerНе думаю. У меня ведь не было задачи искать такие поделки, я просто качал нужные мне файлы с самых обычных сайтов в интернете.И я не думаю. Я знаю. Просто потому, что было время, когда я целенаправленно разбирался с HTTP. Не могу сказать, чтобы все полученные знания мне пригодились, но проблемы, с которыми вы сталкивались не имеют ни малейшего отношения к проблемам самого протокола. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:43 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonНу екарный пельмень! Это решение связано с разработкой! Разработкой ПО. Здесь уже планка требований поднята. Хотя-бы тем что нужно ставить джаву и сервлет-контейнер!Самое несложное из того, что требуется для разработки. Даже если использовать громкое слово "ставить". Поймите правильно - я не против FTP. Если нужно решить единственную задачу, у вас есть готовый FTP и вы доверяете квалификации людей, которые его администрируют - не надо никуда дёргаться. Но я категорически против утверждения, что "FTP лучше HTTP". Хотя бы потому, что FTP - протокол прикладного уровня, а HTTP - транспортного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:48 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
А автору какая разница. Почитал наш топик. Погоревал. Поплакал. Плюнул и записал файл на CD-R и отправил почтой. Ямщиком. На лошадях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:53 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovНе могу сказать, чтобы все полученные знания мне пригодились, но проблемы, с которыми вы сталкивались не имеют ни малейшего отношения к проблемам самого протокола. Судя по всему, у нас разное понимание, что такое "проблемы протокола". Протокол HTTP для хорошей работы в рамках задачи "передача файлов" нуждается в разумной и доброй воле разработчика инструментальных средств. Я полагаю это проблемой протокола и считаю, что было бы куда лучше, если бы разработчики хорошо специфицировали этот момент и не дали возможности сделать "по стандарту, но плохо". Вы полагаете это проблемой конкретных инструментальных средств. Ну, по аналогии, я полагаю, что ПДД должны запрещать ездить ночью без фар, а Вы считаете, что пусть разрешают - а вменяемые люди сами будут их включать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:54 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Лишить лицензий тех кто http-PUT не поддерживает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:57 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovХотя бы потому, что FTP - протокол прикладного уровня, а HTTP - транспортного. Эмм... эта точка зрения как минимум не самая распространённая. Чаще принято считать, что транспортный уровень - это TCP, а FTP&HTTP - равно протоколы прикладного уровня. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 17:58 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerПротокол HTTP для хорошей работы в рамках задачи "передача файлов" нуждается в разумной и доброй воле разработчика инструментальных средств. Я полагаю это проблемой протоколаВы не может предъявлять вашу претензию к транспортному протоколу. К прикладному - можете. К транспортному - нет. Претензии к использованию возможностей транспорта для решения конкретной прикладной задачи должны предъявляться к реализатору. Или надо разбирать конкретную проблему. У меня такой опыт есть . Не я обнаружил эту ошибку, но именно я внёс определённую лепту в её решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 18:01 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerЭмм... эта точка зрения как минимум не самая распространённаяМогу только плечами пожать. С таким подходом и PPP - плохой протокол, поскольку там даже MIME-типов нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 18:03 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovМогу только плечами пожать. Пожмите. Лично я не понимаю, почему если я делаю telnet на двадцатый порт и набираю команды, то я попадаю в протокол прикладного уровня, а если делаю на восьмидесятый и набираю другие команды - то в транспортного. И не думаю, что Вы сумеете объяснить это так, чтобы я согласился. Basil A. SidorovВы не может предъявлять вашу претензию к транспортному протоколу. Это какое-то религиозное утверждение. Лично я считаю, что могу предъявлять обоснованные претензии к протоколам любого уровня. Basil A. SidorovПретензии к использованию возможностей транспорта для решения конкретной прикладной задачи должны предъявляться к реализатору. Если мне нужно сделать автомобиль, я возьму круглые колёса и предъявлю претензии к квадратным. Ну не подходят они мне. Вы же предлагаете взять квадратные, а потом предъявлять претензии не к ним, а к тому, кто их неправильно использовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 18:13 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
mayton Вопросы файрвольности и безопасности пока не рассматриваем. Ведь автор об этом не говорит. Его интересует пока только надёжность. в корне не согласен. Нельзя забывать про безопасность. Если даешь возможность приема, т.е. по сути права на запись в том или ином виде, то будь добр знать о побочных эффектах. Например твой почти идеальный ftp: есть куча хостингов готовых работать бесплатно с предоставления минимального набора ресурсов. Там есть в т.ч. ftp-сервер. Если за безопасность не заморачиваться то вот оно то что надо. Только кто мешает не знающему о безопасности дать свои логин с паролем через форум или вписать в инишник своей проги и прогу раздать? Типа а чего такого, ничего ценного там нет. Только форум читают не только ламеры и кроме FTP есть связанный с ним HTTP который закаченное запустит ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 18:28 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerЛично я не понимаю, почему если я делаю telnet на двадцатый порт и набираю команды, то я попадаю в протокол прикладного уровня, а если делаю на восьмидесятый и набираю другие команды - то в транспортногоДавайте предадим анафеме все общеизвестные порты, окромя двадцать первого. Какая, в конце-концов, проблема выбрать протокол общения по запросу от клиента или прочитать возможности сервера по строке приветствия? Ну а если серьёзно, то укажите, пожалуйста, какую прикладную задачу решает HTTP? Если подойти к вопросу непредвзято, то это именно транспорт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 20:43 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonДавай вернёмся в топику. Автор ищет способы как "передать файлы" по сети. Я ему предлагаю серебрянную пулю. FTP. Дешево. Сердито. В 99.9 случаев работает. Вопросы файрвольности и безопасности пока не рассматриваем. Автор много не договаривает. Например где он хочет разместить FTP-сервер? за натом нельзя, из-за ната только FTP-клиент может работать. Получается нужен хостинг, т.е. уже не дешево, т.е. не бесплатно. HTTP сервер можно за нат поселить и порт замапить. т.е. размещение бесплатно. PS Автор пропал уже давно, надо сворачивать писькомерянье Да нет, я все читаю с интересом. Проблемы размещения и безопасности меня волнуют только для общего ознакомления. В моей задаче файл передается разными нодами внутри защищенной сети. Однако, мало ли что.. Не понимаю зачем мне выбирать FTP или HTTP, если после них придется писать вручную проверку целостности файла. Получается, лучший выбор - SSH, если в нем действительно такая гарантия есть. Если архитектура позволяет. Если нет - то видимо все равно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2014, 23:11 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryВ моей задаче файл передается разными нодами внутри защищенной сети. Простое копирование чем не устроило? Напрямую или через расшаренную папку на сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 07:50 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytryНе понимаю зачем мне выбирать FTP или HTTP, если после них придется писать вручную проверку целостности файла. Получается, лучший выбор - SSH, если в нем действительно такая гарантия есть. Если архитектура позволяет. Если нет - то видимо все равно. В SSH нет файловых транзакций. И если ты во время копирования нажал Ctrl+C или рубанул окошко ФАРа как я уже выше рассказывал то никакой ССШ тебе не детектирует битый файл. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 15:04 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonВ SSH нет файловых транзакций. И если ты во время копирования нажал Ctrl+C или рубанул окошко ФАРа как я уже выше рассказывал то никакой ССШ тебе не детектирует битый файл. Верно, у принимающего останется кусок, но если сам рубанул, сам и должен догадаться что ничем хорошим это не кончилось. На случай обрыва связи во время передачи нужно проверять что передача успешно завершена. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 15:21 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Ну и кроме шифро-трафика это ничем не отличается от ФТП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 15:32 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Вот именно поэтому контрольные суммы нужны не для контроля процесса передачи, а для возможности быстро сравнить уже имеющееся с эталоном. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 16:10 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovДавайте предадим анафеме все общеизвестные порты, окромя двадцать первого. Судя по последним репликам, мы совершенно не понимаем друг друга. Basil A. SidorovНу а если серьёзно, то укажите, пожалуйста, какую прикладную задачу решает HTTP? Ну, если не ходить далеко, то она написана в названии - гипертекст трансфер. Ровно как FTP решает прикладную задачу файл трансфер. И даже это подсказывает, что разумнее выбрать для задачи файл трансфера Basil A. SidorovЕсли подойти к вопросу непредвзято, то это именно транспорт. Если подойти к вопросу разумно, то надо дать определения "транспорта", "прикладного" итп. Лично мне очевидно, что Вы пользуетесь какими-то своими определениями, отличающимися от определений авторов TCP-стека. Также у меня есть ощущение, что разница, которую Вы видите, обусловлена тем, что с HTTP Вы привыкли общаться через оболочку (браузер), а про FTP привыкли думать как про "безоболочечный" (хотя никто не мешает стукнуться к нему через тот же браузер). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 16:44 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Сейчас заказчику передаём версию. Через.... svn(!). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 16:56 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerНу, если не ходить далеко, то она написана в названии - гипертекст трансферВот именно - передача. При этом для разметки гипертекста HTTP опирается на MIME-RFC, хотя и с некоторыми девиациями.Ровно как FTP решает прикладную задачу файл трансфер. И даже это подсказывает, что разумнее выбрать для задачи файл трансфера И, опять-таки, я ещё раз озвучу свою позицию: Я не возражаю против использования FTP для передачи файлов, но категорически против формулировки "HTTP - хуже" или "HTTP - непродуманный протокол". HTTP - гибкий протокол, который в состоянии решить практически любую транспортную задачу. В том числе - беспроблемную передачу больших двоичных файлов. Вы же начинаете предъявлять к протоколу странные претензии. Совершенно необоснованные. Точно таким же образом я могу предъявить высосать из пальца претензию авторам FTP протокола, которые неточно определили сценарии получения файлов, что иногда приводит к невозможности использовать, например, wget в качестве FTP-клиента. Претензия из такой же реальной жизни, как и ваша.Если подойти к вопросу разумно, то надо дать определения "транспорта", "прикладного" итп. Лично мне очевидно, что Вы пользуетесь какими-то своими определениями, отличающимися от определений авторов TCP-стека.А почему, собственно, мы буквоедствуем в рамках модели IP-сетей?Также у меня есть ощущение, что разница, которую Вы видите, обусловлена тем, что с HTTP Вы привыкли общаться через оболочку (браузер), а про FTP привыкли думать как про "безоболочечный" (хотя никто не мешает стукнуться к нему через тот же браузер).Не знаю, на чём основано ваше ощущение, но оно ошибочно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 17:06 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovВот именно - передача. С этой точки зрения и FTP - транспортный. Basil A. SidorovВы же начинаете предъявлять к протоколу странные претензии. Совершенно необоснованные. Попробую объяснить. Однажды, уже очень давно, я провёл пол-дня за отладкой большого куска чужого кода. Наконец, выяснилось, что причиной моих проблем была написанная неким гениальным человеком строка Код: plaintext Когда я её нашёл, я полез в стандарт ANSI, и прочитал там, что мать его так, стандарт официально разрешает компилятору понимать такую строчку и как i = i + 1; и как i = i. Компилятор, которым пользовался автор, действовал по первому варианту, а компилятор, под который собирал я - по второму. Так вот: я, конечно, не сказать чтобы хорошего мнения о человеке, который написал эту строчку. Но то, что стандарт допускает подобное разночтение, я считаю конкретным косяком стандарта. По сути, в стандарте написано следующее: мы закладываем некоторое дерьмо, а вы, все, кто будете программировать, смотрите, чтобы в него не вляпаться. Вы пытаетесь объяснить мне, что стандарт хороший, а виноват целиком прог. Я же считаю, что стандарт должен предписывать однозначную интерпретацию и не давать прогу возможности подложить такую свинью. Basil A. SidorovТочно таким же образом я могу предъявить высосать из пальца претензию авторам FTP протокола, которые неточно определили сценарии получения файлов, что иногда приводит к невозможности использовать, например, wget в качестве FTP-клиента. Я не очень понимаю, о чём Вы, но ничуть не против обоснованной претензии, особенно если она будет иметь отношение к задаче топикстартера. Лично у меня с FTP достойных упоминания проблем не было. Basil A. SidorovА почему, собственно, мы буквоедствуем в рамках модели IP-сетей? По дефолту. Хотите уйти от дефолта - давайте свои определения, и не забудьте упомянуть, что Вы говорите о "транспортном по-сидоровски" протоколе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 17:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
softwarerС этой точки зрения и FTP - транспортныйНет. Именно в силу заточенности на конкретную прикладную задачу. И в силу того, что требования к каналу передачи самые общие - "прозрачный" восьмибитный. И наоборот. HTTP не конкретизирует прикладную задачу, но детально описывает обмен сообщениями, использование посредников и кучу "транспортных" деталей. Поэтому буквоедство в стиле "оба протокола прикладные, т.к. находятся на верхнем уровне моделей IP/ISO" формально, да - правильное, но бесполезное.Когда я её нашёл, я полез в стандарт ANSI, и прочитал там, что мать его такА ещё стандарт не определяет конкретный порядок вычисления аргументов функции и допускает другие неоднозначности. Только это ни разу не проблема стандарта. Есть ситуации, когда меня более чем устраивает возможность написать: Код: java 1. И лично я слабо понимаю, зачем лезть в стандарт? Неопределённость префиксных и постфиксных операторов упомянуты, вроде, в любом учебнике.Но то, что стандарт допускает подобное разночтение, я считаю конкретным косяком стандарта"Компилятор языка C служит для трансляции исходного текста в объектный код. Хотите персональных ремней безопасности - программируйте на языке ADA". Как говорится - ни убавить, ни прибавить.Вы пытаетесь объяснить мне, что стандарт хорошийЯ пытаюсь донести до вас ту простую мысль, что приведённые вами примеры "недостатков" HTTP - неудачны. Мягко говоря.Я не очень понимаю, о чём ВыЕсть два варианта получить файл: 1. Сделать get /абсолютный/путь/файл 2. Сменить удалённый каталог и сделать get файл Так вот, прав на каталог может не быть, а в стандарте эта неопределённость никак не отражена.По дефолту. Хотите уйти от дефолта - давайте свои определения, и не забудьте упомянуть, что Вы говорите о "транспортном по-сидоровски" протоколе."Не держись устава, яко слепой стены". Когда мне потребуется рассмотреть все уровни модели - я воспользуюсь вашей рекомендацией. До тех пор, пока мы остаёмся на (только) верхнем уровне модели - я имею полное право различать разные классы выскоуровневых протоколов. Именно в силу того, что они находятся на одном уровне, но решают разные задачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 22:30 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonНу и кроме шифро-трафика это ничем не отличается от ФТП. Отличается тем, что ssh проверяет целостность сам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2014, 23:58 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Мы совсем про суслика забыли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2014, 19:00 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
DymytrymaytonНу и кроме шифро-трафика это ничем не отличается от ФТП. Отличается тем, что ssh проверяет целостность сам. Целостность чего? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2014, 19:00 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
"Хочешь сделать хорошо - сделай сам" (С) Народная мудрость. Нет смыла искать идеальное решение среди универсальных. Лично у меня переход на ssh снял проблему битых файлов. Допилю свою udp-передавалку - будет идеально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.09.2014, 19:35 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
очень часто антивирусы портят именно битые rar архивы, может в этом дело? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2014, 09:56 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima T"Хочешь сделать хорошо - сделай сам" (С) Народная мудрость. Нет смыла искать идеальное решение среди универсальных. Лично у меня переход на ssh снял проблему битых файлов. Допилю свою udp-передавалку - будет идеально. тройной facepalm... есть же готовая https://github.com/bittorrent/libutp ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2014, 18:05 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
nolockyесть же готовая https://github.com/bittorrent/libutp Отстой так-то. Изучал. Пока писал уже столкнулся с тем что торенты провайдеры банят по простой причине: пакеты до сотни байт, Максимум нагрузки на оборудование с минимумом пользы. Нормально идет пакет до 1372 байт. У меня КПД выше. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.09.2014, 19:48 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Basil A. SidorovИ, опять-таки, я ещё раз озвучу свою позицию: Я не возражаю против использования FTP для передачи файлов, но категорически против формулировки "HTTP - хуже" или "HTTP - непродуманный протокол". HTTP - гибкий протокол, который в состоянии решить практически любую транспортную задачу. В том числе - беспроблемную передачу больших двоичных файлов. Я реализовывал передачу больших (до 30ГБ) двоичных фаилов через http get и put. когда стоял вопрос о выборе FTP/HTTP то иммено HTTP отдали предпочтение. очень гибкий и относително маленький оверхеад. Работает и по сей день, про проблемы с передачей пока не слыхал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2014, 16:06 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima Tnolockyесть же готовая https://github.com/bittorrent/libutp Отстой так-то. Изучал. Пока писал уже столкнулся с тем что торенты провайдеры банят по простой причине: пакеты до сотни байт, Максимум нагрузки на оборудование с минимумом пользы. Нормально идет пакет до 1372 байт. У меня КПД выше. Банили во времена DSL-модемов. Да и то не банили а закрывали порт. Сейчас во времена гигабита и uPnp очень сложно детектировать торрент-сокет. Ну или сама задача выходит за рамки конфигурирования сети. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2014, 16:08 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Незаслужено оставляем без внимания позитивы http. прозрачную компресию, шифрование, раширение вебдав. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2014, 16:14 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonБанили во времена DSL-модемов. Да и то не банили а закрывали порт. Сейчас во времена гигабита и uPnp очень сложно детектировать торрент-сокет. Ну или сама задача выходит за рамки конфигурирования сети. У меня L2TP поверх изернета проводного. Почитай как я разбирался ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2014, 16:30 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Dima TmaytonБанили во времена DSL-модемов. Да и то не банили а закрывали порт. Сейчас во времена гигабита и uPnp очень сложно детектировать торрент-сокет. Ну или сама задача выходит за рамки конфигурирования сети. У меня L2TP поверх изернета проводного. Почитай как я разбирался ОК. Почитаю. Только сходу скажу что я не знаю что такое L2TP. Или мне понадобиться время чтобы осмыслить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2014, 16:33 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
maytonТолько сходу скажу что я не знаю что такое L2TP. L2TP - вид ВПНа, к данному вопросу никак не относится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.10.2014, 16:41 |
|
||
|
Нужно ли проверять checksum файла, переданного по сети?
|
|||
|---|---|---|---|
|
#18+
Совсем забыли про rsync . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.10.2014, 07:07 |
|
||
|
|

start [/forum/topic.php?all=1&fid=16&tid=1341200]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
135ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
176ms |
get tp. blocked users: |
2ms |
| others: | 205ms |
| total: | 566ms |

| 0 / 0 |
