Продолжение операций копирования после перезапуска приложения

[marat_]

всем привет. кто-нибудь занимался разработкой приложений с возможностью докачки файлов? поделитесь опытом, если несложно. сам делаю на основе ini-файлов. перед закрытием помещаю информацию о файле + указатель на позицию, с которой начать качать. на мой взгляд работает несколько неэффективно. ini были выбраны из-за поддержки во всех системах семейства 2k.

[zubr]

ini-файлы по моему еще с 95-й винды пошли.
Сделай лучше по типу флешгета. То есть пока файл полностью не докачался создаешь свой файл с заголовком, куда прописываешь инфу по копируемому файлу (расположение, название, размер, указатель на позицию). После заголовка уже идет сам копируемый файл. Когда файл скачался, удаляешь из него заголовок и меняешь расширение на исходное.

[Dimka]

ini-файлы по моему еще с 95-й винды пошли.

ini-файлы как раз закончились с Windows 95 как основной способ хранения настроек, начался реестр. Вот в Windows 3.x ini-файлы были типичным способом хранения настроек, реестра не было.

[Джон]

Инфу о файле хранить где-то надо. Где именно - принципиального значения не имеет, а скорее зависит от конкретных условий и удобства. А вот позицию... Ведь размер уже сгруженной инфы известен - это и есть стартовая позиция для продолжения.

[Finch]

Джон, Не всегда верно Докачивать можно и по частям. Например в несколько потоков. Тогда файл как бы будет нарезанный.

[Джон]

Вить, во-первых, marat_ сказал, что сохраняет указатель на позицию. Те он скачивает в один поток.
Во-вторых, если даже скачивать в несколько потоков, то в один файл это всё-равно одновременно нельзя скачать. Те скачивание идёт в несколько файлов, которые потом склеиваются в один. В этом случае размер каждой части и будет стартовой позицией для продолжения. Всё работает.

[Finch]

Джон, Это то я понимаю. Видел в одной качалке. Она сразу делает на диске файл с тем размером, который будет качаться. И заполняет его нулями. Потом просто дописывает те области, которые уже скачаны в те позиции, которые эти области соответствуют.

[Джон]

Сомневаюсь, что можно ОДНОВРЕМЕННО писать в один файл из разных потоков. Просто не представляю, как это можно физически реализовать.

[zubr]

Джон, ничего сложного. Файл открывает, записывает и синхронизирует потоки один (главный) поток. Остальные потоки только сохраняют данные в буфер, а затем передают их в основной поток.

[Джон]

zubr, но это не одновременная запись в ФАЙЛ, а одновременная запись в буфер(-а). Ты повторил то, что я написал про несколько файлов. Так что не подходит.

[marat_]

интересная дискуссия получилась. качаю в один поток. но несколько потоков вполне могут писать в один файл. дело не в этом, мне хотелось узнать о других способах, реализациях. делаю как и все: выделяю место для файла, мечу его темпом, переписываю в позицию, после окончания снимаю флаги, переименовываю и помещаю по месту назначения. в реестре инфу хранить смысла нет, количество файлов на скачку неограничено, а реестр может быть фиксированного размера. с ини работаю потому, что ещё с 3.1 есть удобные функции чтения\записи, оптимизированные самими мелко-мягкими, и не нужно велосипед собирать из останков телевизора (цитата).

[Джон]

но несколько потоков вполне могут писать в один файл

Как?

[Dimka]

Джон, см. выше

Джон, ничего сложного. Файл открывает, записывает и синхронизирует потоки один (главный) поток. Остальные потоки только сохраняют данные в буфер, а затем передают их в основной поток.

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

[Джон]

Вы сговорились что ли?

dimka, см. ещё выше

скачивание идёт в несколько файлов, которые потом склеиваются в один

Ещё раз повторяю вопрос:

КАК МОЖНО ОСУЩЕСТВИТЬ ЗАПИСЬ В ОДИН ФАЙЛ (не в буфера!) ОДНОВРЕМЕННО ИЗ НЕСКОЛЬКИХ ПОТОКОВ?
И для полного счастья - КАК В ЭТОМ СЛУЧАЕ УПРАВЛЯТЬ ТЕКУЩЕЙ ПОЗИЦИЕЙ(ПОЗИЦИЯМИ)?

А шаманство с промежуточными буферами/файлами и прочей промежуточной лабудой меня не интересует, ибо ёжику понятно.

[Алексей++]

КАК МОЖНО ОСУЩЕСТВИТЬ ЗАПИСЬ В ОДИН ФАЙЛ (не в буфера!) ОДНОВРЕМЕННО ИЗ НЕСКОЛЬКИХ ПОТОКОВ?

критические секции тебе в помощь

[Dimka]

Джон, угу, именно критические секции. Каждый поток помнит свою позицию перед записью в критической секции устанавливает текущую позицию файла. Не понимаю, чего тут невозможного?

По поводу отсутствия буферов - невозможно. Хотя бы потому, что пакет IP или окно TCP уже подразумевает наличие буфера.

[Джон]

Я же не про синхронизацию тредов спрашиваю.

Гы, те все потоки остановились и ждут пока ОДИН закончит. Те одновременно пишет только ОДИН тред, а остальные отдыхают (если только не пишут в свои собственные буфера, которые потом сливают в рез. файл, но это не подходит). Ну и что? Где же тогда преимущество при сгрузке в несколько потоков?

Я вижу решение только с промежуточными буферами, каждый из которых в конечном счёте представляет собой единичный объект с сохранением своей собственной инфы в файл (или если угодно буфер), те нет никакой принципиальной разницы - качать один файл источника в разные буфера, или качать файлЫ источника в свой собственный буфер. Всё решает только след. шаг - оставить всё как есть, или склеить буфера в один.

[marat_]

получилась несогласованность терминов:
1. поток как единица исполнения с системе
2. поток как непрерывная последовательность байт
скачивание в несколько потоков - значит из нескольких позиций скачиваемого файла идёт загрузка данных. это можно делать как одним тредом, так и несколькими. но писать в файл сразу несколько потоков байт нельзя. а писать в несколько тредов можно.

[zubr]

Гы, те все потоки остановились и ждут пока ОДИН закончит. Те одновременно пишет только ОДИН тред, а остальные отдыхают (если только не пишут в свои собственные буфера, которые потом сливают в рез. файл, но это не подходит). Ну и что? Где же тогда преимущество при сгрузке в несколько потоков?

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

[Вад]

Джон, многопоточная закачка, насколько я понимаю, нужна при узком канале,
1. если канал узкий на стороне клиента, максимально возможную ширину канала забирать, успешнее конкурировать с другими задачами на клиенте.
2. если ширина канала для одного потока закачки на сервере ниже, чем пропускная способность самого канала до клиента: скажем, сервак поставил n кбит/c, а у тебя 100*n кбит/c. Тогда делаем много каналов и качаем быстрее.
Запись на диск при этом в любом случае будет происходить быстрее, даже при синхронизации доступа к файлу из нескольких потоков, сеть наверняка будет медленнее (если это не гигабитный канал, конечно).

[Джон]

писать в несколько тредов можно.

Только при условии, что каждый тред сохраняет данные в свой собственный буфер (не важно - файл, виртуальный файл, куско памяти).

zubr, опять ты про буфера!!!

Сброс же целого буфера гораздо быстрее чем побайтовая запись.

Кто делает побайтовую запись - сам дурак.

Да и за счет многопоточности процессорное время, выделяемое на приложение увеличивается (речь о локальной системе).

Выигрыш можно получить реально на мультипроцессорных системах.


Ладно, короче я так понял ответа не будет.

Мне видится такая оптимальная система (ещё раз подчеркну - ГДЕ именно сохранять инфу о состоянии: файл-источник/файл-цель  - неважно):

Одна закачака - один тред: 1- Большинство серверов ограничивают число потока с одного IP 2. При современных скоростях это уже не имеет большого значения.

Данные сгружаются  в буфер (1К 2К 4К и тд - зависит от...), потом буфер скидывается в файл, который сразу сохраняется! - это очень полезно, если прога вылетела, система зависла, вырубили свет и тп, в противном случае скачав 99 999 999 байт из 100 000 000 теряешь все.

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

[Джон]

Вад, с 2 согласен, только практически посмотреть, если уж сервер ограничивает ширину канала, то он ограничивает и число потоков - ибо выигрыша не произойдёт - я запущу как ты говоришь много потогов и всё. Те для сервера это неразумно.

А многопоточная закачка (тн акселераторы) были популярны во времена модемов (не знаю как где, а здесь во второй половине 90х годов), когда вилка доступных скоростей была от 2х (аналог - хорошо) до 7 (ISDN - просто отлично) KB/сек. Сервера могли давать больше плюс каждое новое соединение могло пойти по другому маршруту - более быстрому, а равно как и более медленному.

А сейчас, если я сливаю 100 МБ за 50 сек в один файл одним потоком, а параллельно 2 раза по 100 МБ за 100 секунд, то нафига заморачиваться? Тем более, как я уже сказал - обычно число потоков на один IP ограничено (часто до одного).

[Вад]

Джон, согласен, если канал шустрый, а сервер ограничивает канал по IP, то такой способ не пройдёт. Сам с момента перехода на 100Мбит качаю в один поток.
А медленные каналы всё ещё актуальны: безлимитные тарифы с зарезанием трафика до 64-128-256-...кбит/сек. имеют место быть, и, как я погляжу, знакомые владельцы таких каналов практикуют многопоточную закачку - значит, это им зачем-нибудь нужно Надо будет спросить, зачем
Кстати, с торрентов так качают, говорят Посмотрел, и насколько понял, там практикуется распределённое хранение файла, то есть, закачка идёт по частям у разных клиентов, у которых есть нужная часть файла. Тут многопоточная закачка явно имеет смысл...

[Джон]

Вад, а я и не против многоканального скачивания. Конечно надо смотреть на условия задачи. Для пиринговых систем сам Бог велел такое дело делать. Хотя конечно "дающим" хуже всех приходится.
А я их просто не практикую (даже не знаю кто этим сейчас ещё занимается) Файлообменники гораздо быстрее. У них наборот - качай сколько у тебя дури хватит, но в один поток. Некоторые, если нагрузка небольшая, разрешают больше, но скорость конечно раз в пять меньше.

Но каждому своё. Кстати моя схема не противоречит многопоточному скачаиванию - это один объект, а уж сгружает он часть файла или файл целиком - ему без разницы. Сгружай десятью объектами десять кусков одного файла со смещением в 0,1 от размера файла, а потом склеивай.

[RXL]

Кстати, а нет ли в винде дублирования декрипторов файлов, аналогичного POSIX dup()? В этом случае у каждого дескрптора свой набор внутреядерных структур и друг другу они не мешают.

[Вад]

Джон, насколько я понимаю, чем больше потоков - тем больше "дающих": каждый даёт кусок, который у него есть, и тогда для отдельного "дающего" нагрузка остаётся той же самой, а её продолжительность (исходящий трафик) снижается за счёт скачивания только части (или снижается нагрузка при сохранении продолжительности, если у клиента канал уже). Что касается схемы - не возражаю, просто я хотел сказать, что конкурирующий доступ к файлу не должен особо сказываться на скорости сохранения получаемых из сети данных, поскольку сеть медленнее. А так - да, решение более гибкое, разница не заметна только пока сеть медленнее

marat_, ты в этой теме будешь интересоваться вещами, специфичными для C/C++, или тему можно переносить в более общий раздел?

[RXL]

Еще одним способом совместного доступа может быть memory mapping: каждый поток мапирует свой кусок и работает с ним независимо друг от друга.

[v2]

Добавлю и свои 2 копейки ..