скорость отправки

Хочу сделать обмен файлами с максимальной скоростью.



У меня есть такая идея-вызывать send максимальное количество раз,

если она вернет SOCKET_ERROR,а WSAGetLastError-WSANOBUFS,то уменьшить кол-во вызовов send в секунду,скажем,на 30% и сделать небольшую паузу,а через некоторое время попробовать снова поднять скорость.



У кого-нибудь есть другие мнения?

 

TransmitFile

 

А неблокирующие сокеты ?!

 

TransmitFile не подходит. :-(

Сокеты и так неблокирующие.



Ладно,задам вопрос по-другому: как сервер (FTP или HTTP) решает,сколько байт

отправлять в единицу времени?То есть,как выбирать оптимальную скорость отправки

пакетов?

 

Наверное через настройки протокола, как же иначе.

 

Протокол TCP в первую очередь и создавали ради оптимизации скорости передачи. Почитай сам RFC на TCP - там много чего интересного.



В общих чертах - начинаем увеличивать скорость передачи данных в 1.2 раза каждый интервал времени (например, раз в 5 секунд), если вдруг пакеты "затормозились" - сокращаем скорость в два раза и затем по-новой. Получается наподобие игр в догонялки с пропускной способностью канала.



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



В общем, читай - "алгоритм Нейгла (Nagle)" и "окна TCP".

 

Это всё,насколько я понял, на уровне протокола TCP.

А как это сделать на уровне Winsock ?

 

Как насчет UDP и собственного квитирования ... ?

 

2TermoSINteZ



Вот про сетевой адаптер ты немного неправ. Ты отправляешь пакеты в локальную сеть. Ее пропускная способность обычно достаточно высока. А где-то на магистральных каналах, например, в 5 хопах от тебя случилось переполнение по суммарному объему трафика. И вот маршрутизатор копит, копит пакеты у себя в буфере (от 64 кб до нескольких Мегабайт), но если переполнение не рассосалось за скажем 5 секунд, он начинает пакеты дропать.



И в гетерогенных сетях типа Интернета твой сетевой адаптер никогда не узнает об этом дропании, поскольку механизмы сигнализации о переполнениях еще более ли менее разработаны в рамках сетей одного протокола, типа FrameRelay, ATM Или MPLS, а вот на стыке разных канальных протоколов на сегодняшний день полный бардак.



Путь решения этой задачи только один - от верхнего уровня, то есть пляшем от недоставки пакета. Чистый UDP вообще никогда не узнает, о том, что его пакет дропнулся из-за переполнения по трафику. TCP узнает отсутствием квитка приема. Ну и конечно же ты сам можешь что-нибудь прикрутить поверх того же UDP или даже IP с какой-нибудь лавинной отправкой (более/менее интеллектуальной конечно), а затем доотправкой недошедших пакетов на основании битов в пакете-квитке.

 

OLS

Зато udp летают шустрее tcp.

 

2Noname:



Я где-то говорил обратное ?!

 

NoName

а теперь подумай ПОЧЕМУ

 

чего?

 

TermoSINteZ

хм.. интересная гипотеза

если много мелких сообщений -- безусловно. потому что tcp -- это протокол с установкой соединения, а udp -- без оной.

 

2TermoSINteZ:

сколько на своем веку трафика перевидал и очередей приоритезации на маршрутизаторах понастраивал - а твою мысль ни разу на практике не встречал



И даже если ты ручками поле Class-of-Service настроишь для подобных пакетов в момент отправки с компьютера, нормальный маршрутизатор все равно его нулю выставит ("выбелит"), а "раскраску" сам произведет по своим правилам приоритетов. То же самое с полем ToS в IEEE 802.1q . Ибо производители маршрутизаторов уже достаточно пообжигались на всяких левых программках, которые каналы передачи данных парализуют своими с потолка взятыми приоритетами, и теперь по умолчанию максимальный приоритет передачи имеет только ICMP и служебные пакеты протоколов маршрутизации.

 

может было проще сказать ICMP & IGMP?

 

... ну почему, я последнее время с OSPF-ом в основном работаю, а в сетях побольше BGP-пакеты с приоритетом бегают