Форум: "Сети";
Текущий архив: 2004.06.20;
Скачать: [xml.tar.bz2];
ВнизПересылка огромных файлов по локальной сети Найти похожие ветки
← →
HellWaiter © (2004-04-26 07:39) [0]Доброе время суток уважаемые мастера!!!
Моя программа служит для передачи файлов по локальной сети, состоящей из 25 компов. Использую для этой цели компоненты NMStrmServ и NMStrm. С небольшими файлами (до 20М) проблем нет, если суммарный объём всех файлв больше - всё виснет. У меня есть идея: запаковать (программно) архиватором файлы в многотомный архив (по 1М) и отправлять их отдельно, причём после каждого прийма клиентом очередного тома, отправлять серверу запрос на следующий и т.д. Может у когонибудь есть идеи получше? Программу пишу на Delphi6.
← →
Rouse_ © (2004-04-26 08:17) [1]Ну так отправляй по одному файлу, и каждый раз пусть клиент делает запрос на следующий файл...
← →
Verg © (2004-04-26 09:09) [2]
> У меня есть идея: запаковать (программно) архиватором файлы
> в многотомный архив (по 1М) и отправлять их отдельно, причём
> после каждого прийма клиентом очередного тома, отправлять
> серверу запрос на следующий и т.д. Может у когонибудь есть
> идеи получше?
Идеи. В смысле - как бороться с глючностью FastNet (NM....) ? Или как передавать файлы?
← →
FireMan_Alexey © (2004-04-26 09:36) [3]1. А переупаковывать архивы это случайно не увеличивать их размер? :)
2. Почему именно только NMStrmServ и NMStrm?
3. Почему 1Мбайт, а не сразу 4Кбайт!?
Здесь на сайте очень много примеров использования
TClient(Server)Socket, там реализована процедура SendStream!
Объявляеш скажем MyFile:TFileStream;
Делаешь Socket.SendStream(MyFile); и только ловиш ошибки, если они есть. Процедура сама уничтожит твой поток MyFile, после передачи.
А с другой стороны ловиш данные ReciveBuffer в обработчике событий OnClientRead и записываешь их в Stream.
Наверное все :)
← →
HellWaiter © (2004-04-26 11:28) [4]С файлами небольших размеров работает. 20 мегабайт отправляются без проблем, немного больше 20М не пересылаются всё виснет, а мне надо гигабайты пересылать. Пробовал уже многотомным архивом потомно отправлят, не идёт и всё тут. Опять теже 20М отправляет без проблем (даже заметить еле успеваю), а больше (ну к примеру 27М) уже "опаньки", всё вешается.
> 1. А переупаковывать архивы это случайно не увеличивать их размер? :)
Я упаковываю чтобы с деревом каталогов заморачиваться. Упаковываю без сжатия, так быстрее.
> 2. Почему именно только NMStrmServ и NMStrm?
А что, TClientSocket и TServerSocket менее глюкавы?
> 3. Почему 1Мбайт, а не сразу 4Кбайт!?
1Мбайт это размер одного тома, если по 4Кб делать томов слишком много будет, а это лишние итерации при отправке/получении и последующем удалении.
← →
jhtiger (2004-04-26 13:58) [5]Ну а почему бы не воспользоваться FTP компонентами TIdTrivialFTP & TIdTrivialFTPServer. FTP на то и существует, чтобы файлы посылать и принимать.
Я думаю, проблемы с размером файлом не должно возникнуть.
Да, ты хоть 1Гб отправляй.
← →
Карелин Артем © (2004-04-26 16:20) [6]jhtiger (26.04.04 13:58) [5]
TrivialFTP вроде как передает файлы по UDP. Может быть нехорошая ситуация при потере пакетов. Клиент и сервер индейские вроде как лучше для передачи просто файлов.
← →
Петров Денис © (2004-04-26 19:44) [7]>> Я упаковываю чтобы с деревом каталогов заморачиваться.
>> Упаковываю без сжатия, так быстрее.
А смысл?
>> А что, TClientSocket и TServerSocket менее глюкавы?
Да. Собственно, если учесть их ограничения, они достаточно стабильны. Конечно, веб-сервер для поисковой машины на них не напишешь, но для большого числа задач они вполне подходят.
И что за нездоровая тяга для решения достаточно простой задачи использовать какую-нибудь гадскую глюкавую библиотеку?
Чем не угодили TServerSocket, TClientSocket и TSocketStream?
Какой смысл копаться в FastNet и искать, где же та заветная строка, которую надо исправить, чтобы передавались файлы больше 20 Мб?
← →
HellWaiter © (2004-04-27 03:14) [8]>> Я упаковываю чтобы с деревом каталогов заморачиваться.
извеняюсь, ошибочка вышла :)
Я упаковываю чтобы с деревом каталогов НЕ заморачиваться.
Так, проще. Ведь даже при обычном копировании сначала сканируется всё дерево дтректорий, это тоже занимает время.
ок, спасиба за совет, буду переделывать на TServerSocket и TClientSocket.
← →
FireMan_Alexey © (2004-04-27 09:08) [9]>Петров Денис
>Конечно, веб-сервер для поисковой машины на них не напишешь, но >для большого числа задач они вполне подходят.
А как ты представляешь работу всех твоей поисковика без сокетов?
← →
FireMan_Alexey © (2004-04-27 09:11) [10]Извиняюсь очепяточка вышла!
>Петров Денис
Как ты представляешь работу вообще с протоколами(UDP,ТСР) без сокетов? И почему же нельзя написать поисковик на TClient(Server)Socket?
← →
Петров Денис © (2004-04-27 09:48) [11]>> Как ты представляешь работу вообще с протоколами(UDP,ТСР)
>> без сокетов?
Жестоко. Кто сказал, что я каким-то образом представляю работу с TCP или UDP без сокетов? Повторяюсь: "если учесть их ограничения, они достаточно стабильны. Конечно, веб-сервер для поисковой машины на них не напишешь, но для большого числа задач они вполне подходят". Где тут написано, что я представляю работу с TCP без сокетов?
Объясню свои слова. Если посмотреть в реализацию TServerSocket, то там можно найти, во-первых, вызовы API-функции select, она имеет свои ограничения, связанные с количеством одновременно обрабатываемых сокетов.
Кроме того, если мне не изменяет память, в этих классах реализована модель ввода-вывода WSAEventSelect, что тоже вполне терпимо, но, если вдруг предстоит написать веб-сервер для какого-нибудь Яндекса, который обрабатывает ... тучу запросов в секунду и на котором висит огромное число подключений, эта модель не подойдет.
Для такой задачи лучше всего использовать модель портов завершения, или, на худой конец, перекрытый ввод-вывод.
Страницы: 1 вся ветка
Форум: "Сети";
Текущий архив: 2004.06.20;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.076 c