Изпращане на огромни файлове през локалната мрежа
Добър ден скъпи майстори. Моята програма се използва за прехвърляне на файлове през локална мрежа, състояща се от 25 компютъра. Използвам NMStrmServ и NMStrm компоненти за тази цел. Няма проблеми с малки файлове (до 20M), ако общият обем на всички файлове е по-голям - всичко виси. Имам идея: файловете на архиватора да се опаковат (програмно) в многотомен архив (по 1M) и да се изпращат отделно и след всяко приемане на следващ том от клиента да се изпраща заявка към сървъра за следващ и т.н. Може би някой има по-добри идеи? Програмата е написана на Delphi6.
Е, изпращайте файл по файл и всеки път оставяйте клиента да направи заявка за следващия файл.
> Имам идея: пакетирайте (програмно) с архиватор > в многотомен архив (1M всеки) и ги изпратете отделно, с > след като всеки клиент получи нов том, изпратете > сървърна заявка за следващата и т.н. Някой има ли > по-добри идеи?
Идеи. В смисъл - как да се справя с бъгавия FastNet (NM.)? Или как да прехвърляте файлове?
1. А преопаковането на архивите случайно не увеличава размера им? :) 2. Защо само NMStrmServ и NMStrm? 3. Защо 1MB, а не 4KB наведнъж!?
Тук на сайта има много примери за използване на TClient(Server)Socket, там е внедрена процедурата SendStream! и прихващайте само грешки, ако има такива. Самата процедура ще унищожи вашия поток MyFile след прехвърлянето. От друга страна, вие улавяте данните на ReciveBuffer в манипулатора на събития OnClientRead и ги записвате в потока. Вероятно всичко :)
Работи с малки файлове. 20 мегабайта се изпращат без проблеми, малко повече от 20M не се изпращат, всичко виси, но за менТрябва да изпратите гигабайти. Опитах вече с многотомен архив, изпратен по-късно, не тръгва и това е. Отново същият 20M изпраща без проблеми (дори аз едва имам време да забележа), а повече (е, например 27M) вече са "уау", всичко е затворено. > 1. А преопаковането на архивите случайно не увеличава размера им? :) Стягам багажа, за да се забъркам в дървото на директориите. Опаковам без компресия, по-бързо е.
> 2. Защо само NMStrmServ и NMStrm? TClientSocket и TServerSocket по-малко ли са бъгове?
> 3. Защо 1MB, а не 4KB наведнъж!? 1MB е размерът на един том, ако ще има твърде много томове от 4KB, а това са допълнителни итерации при изпращане/получаване и последващо изтриване.
←→jhtiger ( 2004-04-26 13:58 ) [5]
Е, защо не използвате FTP компонентитеTIdTrivialFTP&TIdTrivialFTPServer. FTP съществува само за изпращане и получаване на файлове. Мисля, че не би трябвало да има проблем с размера на файла. Да, можете да изпращате поне 1GB.
jhtiger (4/26/04 13:58) [5] TrivialFTP вид прехвърля файлове през UDP. Може да има лоша ситуация със загуба на пакети. Индийският клиент и сървър изглеждат по-добри за прехвърляне само на файлове.
>> Опаковам се, за да се занимавам с дървото на директориите. >> Опаковам без компресия, по-бързо е. Какъв е смисълът?
>> TClientSocket и TServerSocket по-малко ли са бъгове? Да. Всъщност, предвид техните ограничения, те са доста стабилни. Разбира се, не можете да напишете уеб сървър за търсачка върху тях, но те са доста подходящи за голям брой задачи.
И какъв вид нездравословно желание за решаване на доста проста задача е да се използва някаква неприятна библиотека с грешки? Какво направиха TServerSocket, TClientSocket иTSocketStream? Какъв е смисълът да се ровим във FastNet и да търсим къде е заветният ред, който трябва да се коригира, така че да се прехвърлят файлове, по-големи от 20 MB?
>> Опаковам багажа, за да не се притеснявам за дървото на директориите. Съжалявам, стана грешка :) Стягам багажа, за да не се занимавам с дървото на директориите. По-лесно е. В крайна сметка, дори при нормално копиране, цялото дърво на dtrackories се сканира първо, това също отнема време.
добре, благодаря за съвета, ще го преправя на TServerSocket и TClientSocket.
>Петров Денис>Разбира се, не можете да напишете уеб сървър за търсачка върху тях, но >за голям брой задачи те са доста подходящи.И как си представяте работата на цялата ви търсачка без сокети?
>Петров Денис Как си представяте работата с протоколи (UDP, TCP) без сокети като цяло? И защо е невъзможно да се напише търсачка на TClient(Server)Socket?
>> Как си представяте работата с протоколи като цяло (UDP, TCP) >> без гнезда?
жестоко. Кой каза, че по някакъв начин си представям работа с TCP или UDP без сокети? Повтарям: "предвид техните ограничения, те са доста стабилни. Разбира се, не можете да напишете уеб сървър за търсачка върху тях, но за голям брой задачи те са доста подходящи." Къде тук пише, че представям работа с TCP без сокети?
Ще обясня думите си. Ако погледнете изпълнението на TServerSocket, тогава можете да намерите там, първо, извиквания към функцията за избор на API, тя има своите ограничения, свързани с броя на едновременно обработваните сокети.
Освен това, ако паметта ми не ме лъже, тези класове реализират I / O модела WSAEventSelect, който също е доста поносим, но ако изведнъж трябва да напишете уеб сървър за някакъв Yandex, койтосе обработва. облак от заявки в секунда и на който висят огромен брой връзки, този модел няма да работи.
За такава задача е най-добре да използвате модела на портовете за завършване или в най-лошия случай блокиран I/O.