Цитата(annushka89 @ 8.5.2009, 17:19  ) |
| это понятно, как рационально выбрать буфер? |
чем больше, тем лучше
твоя задача максимально нагрузить ядро при минимальном количестве системных вызовов
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Программирование под Unix/Linux > передача файлов через сокеты |
| Автор: annushka89 8.5.2009, 16:15 |
| самая обычная клиентская и серверная програма(самая простая и передача через 127.0.0.1) как можно передавать файлы через сокеты(стандартными функциями)? как я поняла, размеры передаваемых файлов через сокеты напрямую зависят от размеров входных буферов, так как же, например, мне передавать файлы, размеры которых гораздо больше размеров входных буферов? конечно, можно буфер сделать и по 1 мб, и 10 мб, но это же нерационально и смешно. Как будет зависеть скорость передачи файлов? 1)Специалисты, помогите советом и привидите пожалуйста протой пример как это организовать 2)как это делают профессионалы(может есть уже готовые классы и стандарты для этой функциональности), помогите, поделитесь опытом пожалуйста всем спасибо |
| Автор: MAKCim 8.5.2009, 17:05 |
| annushka89, передавай данные порциями максимально возможной при данном размере выходного буфера длины Добавлено через 48 секунд annushka89, передавай данные порциями максимально возможной при данном размере выходного буфера длины |
| Автор: annushka89 8.5.2009, 17:19 |
| это понятно, как рационально выбрать буфер? может есть специальные протоколы? ответьте пожалуйста на вышезаданные вопросы |
| Автор: MAKCim 8.5.2009, 17:43 | ||
чем больше, тем лучше твоя задача максимально нагрузить ядро при минимальном количестве системных вызовов |
| Автор: annushka89 8.5.2009, 20:59 | ||
т.е. вы хотите сказать, что буфер можно и 10 мб сделать? по-моему - это просто смешно, и нерациональное использование памяти!!! пришла к выводу, что более подходящий вариант - это 1024 байт(размер буфера) хорошо, скажите, есть ли специальные протоколы по передачи файлов, может приведете пример заранее спасибо |
| Автор: MAKCim 9.5.2009, 00:59 | ||||
аргументируйте ;) Добавлено через 2 минуты и 49 секунд
File Transfer Protocol все зависит от задачи если клиент и сервер самописные, то никакой протокол по сути не требуется |
| Автор: annushka89 9.5.2009, 22:30 | ||||
под буфер придется выделять память, можно выделить и 1000 байт, и 1000000 байт - разница существенная, и хочется как-то разумно распределять ресурсы |
| Автор: MAKCim 10.5.2009, 09:38 | ||
это не аргументация ;) какая цель программы? передача файла - это основная функция или нет? |
| Автор: SneG0K 10.5.2009, 09:46 |
| annushka89, смотри, по протоколу TCP можешь мередавать хоть 100 ГБ - он сам разбивает файл (по 8 кб помоему) Чезер UDP прийдеться уже самому разбивать файл на кусочки (по 64 кб) |
| Автор: MAKCim 10.5.2009, 10:05 | ||
| SneG0K, вопрос не в этом при большом буфере можно записать через один системный вызов бОльшее количество данных это лучше по двум причинам 1. уменьшение количества переключений R3<->R1 2. уменьшение общего количества времени блокирования процесса, связанного с латентностью переключения контекста Добавлено через 3 минуты и 1 секунду
ну вообще максимальный размер одной порции передаваемых данных находится в пределах от PMTU до ~64K |
| Автор: annushka89 10.5.2009, 18:35 | ||
| цель программы - максимизировать скорость передачи файла что такое PMTU? Добавлено через 2 минуты и 21 секунду
скажите как это понять R3<->R1 и я использую неблокирующие сокеты, т.е. снимаю блокировку |
| Автор: annushka89 10.5.2009, 18:57 |
| скажите пожалуйста, еще как посчитать траффик(кол-во принятой/переданной инфомации в байтах) т.е. нужно ли учитывать все служебные байты, которые прибавляются к пакетам на уровнях, ниже TCP или же считать, сколько передала "полезной информации" |
| Автор: MAKCim 10.5.2009, 21:18 | ||||||||
path MTU (Maximum Transmit Unit) минимальный среди MTU всех сегментов сети, через которые проходит пакет, прежде чем дойти до адресата
переключение user level <-> ядро
тогда mmap + send размер буфера 2 * 64K 64K - максимальный размер IP дейтаграммы
от задачи зависит имхо, нет |
| Автор: fry 10.5.2009, 21:31 |
| Если принимать размер буфера как "максимально возможный". Если разбивать данные например с размером кусков порядка метра, то как они будут обрабатываться ОС? Я думаю, что ОС копируя из буфера пользовательского пространства данные: 1. скопирует все (что маловероятно) и будет занимать данными ОЗУ довольно большое время( все зависит от объема внутреннего ОЗУ сетевухи и скорости передачи данных по сети) 2. скопирует лишь часть данных в сетевуху, что во первых забьет ее буфер и во вторых пользовательскому пространству все равно придется ждать сетевуху (или ОС как кому нравится) для продолжения копирования данных. В это время, если использовать для выделения просто область из кучи, придется "держать" (не высвобождать) выделенное пространство до копирования самого последнего байта. Если данные варианты лучше чем разбуение на несколько системных вызовов, то пользуйте, как говориться, на здоровье. Конечно можно обойтись без дополнительной буферизации, но надо ли это?(все равно быстрее не передашь и ОЗУ будет занята до полной передачи) К слову кадр Ethernet может передать около 1,5 КБ данных, остальной объем будет автоматически разбит самой ОС. |
| Автор: MAKCim 11.5.2009, 09:08 | ||
так и есть |
| Автор: annushka89 11.5.2009, 12:09 |
| спасибо Вам большое, решила буфер использовать размером 128 кбайт |
| Автор: fry 11.5.2009, 14:06 |
| Думаю можно попробовать отправить на обработку через write и посмотреть сколько данных примет ОС. ИМХО не думаю что крайне большие буферы имеет смысл использовать. |
| Автор: GrayCardinal 12.5.2009, 10:53 |
 Не думаю что стоит вручную указывать размер (приемного) буфера. TCP на то и придуман, чтобы "это дело" контролировать и выбирать оптимальный вариант... |
| Автор: MAKCim 12.5.2009, 12:20 | ||
TCP не контролирует размер входных/выходных буферов сокета  он может окно изменять и масштабировать его, но в рамках значений размеров буферов |
| Автор: GrayCardinal 12.5.2009, 17:32 |
MAKCim,  |