LINUX.ORG.RU

зависит от ситуации, из очевидного - либо порезать на чанки и попробросать по фтп, либо, как уже тут упомянули, п2п

shty ★★★★★
()
Последнее исправление: shty (всего исправлений: 1)
Ответ на: комментарий от shty

порезать на чанки

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

В торрентах чанки хэшируются независимо, это позволяет докачать только битый кусок.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

ограничение до 1,2 тб при хешировании

ммм, это легко исправить. А в самом протоколе, на сколько я понимаю, проблем нет. По крайней мере не в торрент-файлах.

true_admin ★★★★★
()

услашать советы в реализации передача

Дварковать влендишным способом.

redgremlin ★★★★★
()
Ответ на: комментарий от anonymous

почему не подойдут? Торренты докачку из-коробки держат. Направление трафика (upload/download) роли не играет, аплоадер это сидер, даунлоадер это личер.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

Правда, идея посчитать хэши для 5тб не находят отклика в моём сердце. Во всяком случае если это не скоростной сторадж.

true_admin ★★★★★
()
Ответ на: комментарий от anonymous

*хотя бы потому, что эти 5 тб возможно будут генерировать «на лету» и писать на удаленный сервак, то есть изначально хешировать возможно и нечего.

anonymous
()
Ответ на: комментарий от anonymous

например, какой-нибудь бредогенератор md5 радужных таблиц в GPU ферме.

anonymous
()

чую где то подвох в организации архитектуры, ТЗ огласите плз

MikeDM ★★★★★
()
Ответ на: комментарий от r_asian

что это делает в web-Development

что за грязные намёки? :). В общем, проглядел, а щас как-то поздновато переносить...

true_admin ★★★★★
()

передача больших(~3-5Tb) файлов по сети

Лет эдак через 10 эту тему откопают и таки будут долго ржать. Примерно так же, как над обсуждениями середины 90х о топовых компутерах. Так что, как вариант, одна из реализаций - подождать десяток лет.

Yazaban
()
Ответ на: комментарий от Yazaban

Поройтесь по ЛОру где-то есть топик образца 2001 года, где человек пишет, что не может загрузить двухпроцессорный сервак на пентиум3, потому как для этой «супермашины» нет таких ресурсоемких задач.

anonymous
()

а откуда куда надо передавать, с какой целью, в какой сети (интернет или ЛВС)?

Harald ★★★★★
()
Ответ на: комментарий от true_admin

думается мне что сеть много медленней стораджа в любом случае. так что вполне можно считать хеши в расслабленном режиме.. типа посчитал для десятка кусочков, сиди кури..

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

так что вполне можно считать хеши в расслабленном режиме..

это супер-вариант, но торрент-файл так не создашь. И вообще я бы через rsync+ssh синкал, надо только с параметрами поиграться чтобы каждый раз при обрыве связи все хэши не пересчитывал. По-моему, --partial --inplace --append решают проблему.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

да, rsync + ssh для передачи будут наверное лучшим решением в если остаться рамках «не городить велосипед» и учесть что нужно лишь разбить файл через split скажем и наслаждаться результатом...

AndreyKl ★★★★★
()
Ответ на: комментарий от AndreyKl

а зачем разбивать файл через split? К тому же это долго и потребует дополнительные 3-5TB под хранение.

Кстати, ssh умеет компрессию (помимо контроля целостности передаваемых данных), так что можно весьма ускорить передачу если данные хорошо сжимаются.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

а зачем разбивать файл через split? К тому же это долго и потребует дополнительные 3-5TB под хранение.

я просто боюсь осилит ли rsync файл в 3-5 тб.. ман не читал, код не глядел.

AndreyKl ★★★★★
()

HTTP/1.1+chunked

Контроль целостности на уровне tcp, есть возможность плевать чанки по мере чтения файла.

melkor217 ★★★★★
()

Можно воспользоваться возможностью протокола HTTP/1.1 слать данные chunk-ами - при этом ограничений на длину HTTP-сообщения явно не накладывается. Инициирующий скачку данных узел шлет на сервер HTTP-сообщение, в котором указывает какую порцию данных он хочет получить (заголовок Range) либо без этого указания, если данные нужны полностью. Сервер в ответ отдает вышеуказанным методом требуемые данные.

Вероятно, необходимо будет предусмотреть управление передачей со стороны клиента (например, отправка запроса на прекращение передачи), посему обмен с сервером будет носить асинхронный характер.

Исходя из того, что свободных библиотек для асинхронного и потокового HTTP что-то особо не видно (можете меня поправить) и «всяк кулик свое болото ...», рекомендую взять это - все необходимое там имеется.

illy
()

Попробуй передавать их по радио. Первое что пришло в голову. Если очень важно именно по сети - попробуй передавать под видом трансляции. Как эфиры новостей всяких.

carthrbc
()
18 ноября 2012 г.
Ответ на: комментарий от Megamozg

выраниваня последователностей геномов

P.S. Вариант со сжатием очень радует так-как там гора повторяющихся одинаковых байтов...

big_buka
() автор топика
Ответ на: комментарий от true_admin

чанки сделать побольше и всё. время тут особо не подкрутишь

visual ★★★
()

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

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от Yazaban

Лет эдак через 10 эту тему откопают и таки будут долго ржать.

Не-а. Темпы прогресса стремительно снижаются. Темы 2002-го года сегодня смеха не вызывают. А вот темы 1992-го в 2002-м — вызывали :)

Сегодня же даже на железе 2002-го ещё вполне жить и работать можно, хотя и не с полным комфортом.

Так что, в 2022-м, если не будет каких-то революций, то, скорее всего, нынешние темы будут восприниматься как сегодня темы, где-то, 2005-го.

KRoN73 ★★★★★
()
Ответ на: комментарий от Rosko

А какое отношение Топ-500 имеет к ЛОРу и, соответственно, вопросам десктопа/простого сервера?

Топ-500 зависит почти линейно от линейного же Мура.

Десктоп/мелкий сервер зависит от запросов и задач.

Считать, что разница в вышеупомянутом железе между 1992-м и 2002-м такая же, как между 2002-м и 2012-м может человек только крайне далёкий от темы или тролль :)

KRoN73 ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

Я лишь предположил. Более того, ТС намекает, что данные непожаты.

madcore ★★★★★
()
Ответ на: комментарий от Chaser_Andrey

В теме видел уже вопрос: «А что, сопсна, передаём», поэтому в Вашем посту отреагировал на «причин» :)

helios ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.