Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

idFTP и большие файлы

Страницы: 1 2 >
yuriks © (2006-10-25 12:14:00)
Для закачки файла с FTP сервера использую idFTP.

Для отображения хода выполнения закачки использую OnWork

procedure TForm1.FTPWork(ASender: TObject; AWorkMode: TWorkMode;
AWorkCount: Integer);

количество считанных байт - AWorkCount
но оно Integer а не Int64
то-есть не подходит для больших файлов (> 2Gb)

Как решить проблемку ?

Anatoly Podgoretsky (2006-10-26 09:18:00) [1]
Кстати можно поговорить ошибка ли это и так ли переводится термин, с моей точки зрения нормально, это не количество переданых байт, а количество выполненых единиц работы. Вот только использую везде где можно Integer, вместо Int64, авторы сознательно загоняют себя в угол.
А вот насчет AWorkCount - не нужно это да, количество единиц работы это показатель в попугаях, который не применить, если только не чесать левое ухо правой рукой. Вместо AWorkCount, правильнее ABytesTransfered типа Int64 и если замахнуть на 22 век, то еще AUnitSize
Но пока Int64 хватает, что бы измерить всемирный трафик за день или чуть более, он гдето порядка 500 пентабайт ежедневно. За три года возрос в 17 раз.

Anatoly Podgoretsky (2006-10-26 09:12:00) [2]

> Да я и не возражал)

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

Сергей М. (2006-10-26 08:44:00) [3]

> Anatoly Podgoretsky © (25.10.06 19:01) [36]

Да я и не возражал)

Здесь суть в том, что в теле метода TIdFTP.Get() организован цикл, в каждой итерации которого "закачивается" очередная "порция" файла размером не больше IOHandler.RecvBufferSize (Integer). И по идее параметр AWorkCount должен информировать о размере этой текущей "порции", а не аккумулировать предыдущие размеры. Об этом и в справке говорится. Т.е. акумуляция в AWorkCount - это ошибка разработчиков, но она вовсе не мешает организации прогресс-индикации транспорта файла - параметр AWorkCount для этого попросту не нужен .. либо можно выделять из него лишь дельту, которая никогда не превысит предельное положительное значение для Integer, и аккумулировать эти дельты в своей собственной Int64-переменной.

Anatoly Podgoretsky (2006-10-25 19:01:00) [4]
Значит согласен с моим предложением работать не с байтами, а с килобайтами, соответственно можно за раз брать столько гигабайт, сколько нужно.

Сергей М. (2006-10-25 17:59:00) [5]

> Anatoly Podgoretsky © (25.10.06 16:43) [34]

> Нельзя, размер Integer

Можно.
И для этого тот самый параметр AWorkCount: Integer нахрен не нужен, хоть Integer он хоть Int64.

Anatoly Podgoretsky (2006-10-25 16:43:00) [6]

> Progressbar.position - вот тебе и прогресс !

Нельзя, размер Integer, читай про переход к террабайтам, для этого единица должна быть не байт, а килобайт, если 2 террабайт не хватит, тогда переходим к пентабайтам, а единица равна 1 мегабайт

Anatoly Podgoretsky (2006-10-25 16:42:00) [7]

> Ему, автору, прогресс-позишн нужно иметь в момент OnWork
> ..

Ну и что? Прогресс бар никак не связан ни с байтами, ни с гигабайтами, если размерности в 2 гигабайта не хватает, то перейти к размерности 2 терабайта.

Сергей М. (2006-10-25 15:43:00) [8]

> yuriks (25.10.06 15:27) [31]

Ну и?
Вот тебе и итерация - OnWork вызывается в цикле.

Даже если "глюк" в этом индейском компоненте, ты берешь эти самые 32к (дифолт) , суммируешь с Progressbar.position - вот тебе и прогресс !

В чем проблема-то ?

yuriks (2006-10-25 15:27:00) [9]
Например, если размер файла 2,5 Gb = 2684354560 b
то OnWork будет вызыватся 2684354560 / 32768 = 81920 раз

А значения AWorkCount будут такими
32768
65536
98304
...
2147450880
-2147483648
-2147450880
...

Сергей М. (2006-10-25 15:19:00) [10]

> yuriks (25.10.06 15:18) [29]

Сколько раз у тебя вызывается OnWork ?

yuriks (2006-10-25 15:18:00) [11]
Сергей М., по моему как раз ты и не вьезжаеш !

Сергей М. (2006-10-25 15:18:00) [12]

> Anatoly Podgoretsky © (25.10.06 15:16) [26]

Ему, автору, прогресс-позишн нужно иметь в момент OnWork ..

Въехал ?

Anatoly Podgoretsky (2006-10-25 15:17:00) [13]
Это тебе надо въехать прежде чем делать такие необдуманые заявления.

Anatoly Podgoretsky (2006-10-25 15:16:00) [14]
Сергей М. © (25.10.06 15:15) [24]
Нормальная движется, но медленнее, чем на 8 мб файле.

Сергей М. (2006-10-25 15:15:00) [15]

> Anatoly Podgoretsky © (25.10.06 15:14) [23]

ты бы хоть въехал что ли в сабж для начала)...

Сергей М. (2006-10-25 15:15:00) [16]

> для меня "нормально" качать как ти сказал "за один прием"

Ну и нахрен тебе тогда OnWork-событие, спрашивается ?)

Оно ж как раз и существует для прогресс-индикации, как это обозначено в справке.

Ну и какая нахрен прогресс-индикация м.б., если recv() запросит сразу весь многогигабайтный объем данных ?

думай головой-то... думай ... чешим репу-то)...

Anatoly Podgoretsky (2006-10-25 15:14:00) [17]

> что ни один "нормальный" FTP-клиент не будет запрашивать
> к передаче "за один прием" такой большой объем данных.

Не вижу никаких проблем, часто качаю по 4-8 гб за раз.

yuriks (2006-10-25 15:11:00) [18]
Ладно, забудь.
Решу по другому !

yuriks (2006-10-25 15:10:00) [19]

> Не смотря на [15] смею утверждать. что ни один "нормальный"
> FTP-клиент не будет запрашивать к передаче "за один прием"
> такой большой объем данных.

Вот я и говорю что для меня "нормально" качать как ти сказал "за один прием" один файл размером > 2Gb !

Сергей М. (2006-10-25 15:06:00) [20]
Ну что там м.б. не понятно ? для FTP-клиента существуют просто файлы, а их содержимое (будь там хоть "iso-шка", хоть "хрено-шка") FTP-клиенту по-барабану, потому как читай спецификацию FTP.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »