Здравствуйте. Подскажите пожалуйста источник. Нужна информация о том, как ограничивать сокет по трафику, чтобы например, сокет мог передавать файл со скоростью не больше N Кб/с. Спасибо.
Здравствуйте, Ded_Pixto, Вы писали:
D_P>Здравствуйте. Подскажите пожалуйста источник. Нужна информация о том, как ограничивать сокет по трафику, чтобы например, сокет мог передавать файл со скоростью не больше N Кб/с. Спасибо.
тоже хотелось бы услышать ответы по сабжу
пока решаю это простым подсчетом по некоторым правилам и считыванием с сокета, получается довольно сносно
хотел бы послушать еще рекомендации по поводу изменения внутреннего приемного буфера сокета
On Mon, 19 Dec 2005 15:30:44 -0000, ilnar <982@users.rsdn.ru> wrote:
[]
> пока решаю это простым подсчетом по некоторым правилам и считыванием с сокета, получается довольно сносно > хотел бы послушать еще рекомендации по поводу изменения внутреннего приемного буфера сокета
Здравствуйте, MaximE, Вы писали:
ME>On Mon, 19 Dec 2005 15:30:44 -0000, ilnar <982@users.rsdn.ru> wrote:
ME>[]
>> пока решаю это простым подсчетом по некоторым правилам и считыванием с сокета, получается довольно сносно >> хотел бы послушать еще рекомендации по поводу изменения внутреннего приемного буфера сокета
ME>Рекоммендация такая: не трогайте размеры буферов.
On Wed, 21 Dec 2005 13:49:10 -0000, ilnar <982@users.rsdn.ru> wrote:
> Здравствуйте, MaximE, Вы писали: > > ME>On Mon, 19 Dec 2005 15:30:44 -0000, ilnar <982@users.rsdn.ru> wrote: > > ME>[] > >>> пока решаю это простым подсчетом по некоторым правилам и считыванием с сокета, получается довольно сносно >>> хотел бы послушать еще рекомендации по поводу изменения внутреннего приемного буфера сокета > > ME>Рекоммендация такая: не трогайте размеры буферов. > > почему?
Потому что изменение размера буфера не поможет тебе управлять трафиком.
Решения различных проблем, которые я видел управляли размерами буферов были лишь костылями к неряшливому дизайну. Если ты увеличиваешь приемный буфер, он рано или поздно переполнится независимо от размера если ты не успеваешь обрабатывать запросы со скоростью их поступления. Изменение размера буфера отсылки TCP не влияет на скорость отсылки, реализации же UDP могут вообще не иметь буфера отсылки.
Здравствуйте, MaximE, Вы писали:
ME>On Wed, 21 Dec 2005 13:49:10 -0000, ilnar <982@users.rsdn.ru> wrote:
>> Здравствуйте, MaximE, Вы писали: >> >> ME>On Mon, 19 Dec 2005 15:30:44 -0000, ilnar <982@users.rsdn.ru> wrote: >> >> ME>[] >> >>>> пока решаю это простым подсчетом по некоторым правилам и считыванием с сокета, получается довольно сносно >>>> хотел бы послушать еще рекомендации по поводу изменения внутреннего приемного буфера сокета >> >> ME>Рекоммендация такая: не трогайте размеры буферов. >> >> почему?
ME>Потому что изменение размера буфера не поможет тебе управлять трафиком.
ME>Решения различных проблем, которые я видел управляли размерами буферов были лишь костылями к неряшливому дизайну. Если ты увеличиваешь приемный буфер, он рано или поздно переполнится независимо от размера если ты не успеваешь обрабатывать запросы со скоростью их поступления. Изменение размера буфера отсылки TCP не влияет на скорость отсылки, реализации же UDP могут вообще не иметь буфера отсылки.
я имел ввиду то, что когда буфер не читается, операционка как-то дает сигнал другой стороне что пока не может принимать очередное, например, изменив размер окна.
On Wed, 21 Dec 2005 14:11:40 -0000, ilnar <982@users.rsdn.ru> wrote:
[]
> я имел ввиду то, что когда буфер не читается, операционка как-то дает сигнал другой стороне что пока не может принимать очередное, например, изменив размер окна.
Я это понял. Чтобы такой механизм работал тебе придется отслеживать такие параметры как RTT — очень хлопотно и ненадежно. Гораздо проще и надежней решение с простым таймером, когда ты не вычитываешь больше, чем нужно за определенный интервал (обычно секунду). Заметь, что и в этои случае, когда данные поступают быстрее, чем ты их вычитываешь, приемный буфер TCP заполнится и отсылающая сторона будет получать win=0, что заставит TCP стэк этой стороны прекратить отсылку сегментов до тех пор, пока окно сново не приоткроется.
Здравствуйте, MaximE, Вы писали:
ME>On Wed, 21 Dec 2005 14:11:40 -0000, ilnar <982@users.rsdn.ru> wrote:
ME>[]
>> я имел ввиду то, что когда буфер не читается, операционка как-то дает сигнал другой стороне что пока не может принимать очередное, например, изменив размер окна.
ME>Я это понял. Чтобы такой механизм работал тебе придется отслеживать такие параметры как RTT — очень хлопотно и ненадежно. Гораздо проще и надежней решение с простым таймером, когда ты не вычитываешь больше, чем нужно за определенный интервал (обычно секунду). Заметь, что и в этои случае, когда данные поступают быстрее, чем ты их вычитываешь, приемный буфер TCP заполнится и отсылающая сторона будет получать win=0, что заставит TCP стэк этой стороны прекратить отсылку сегментов до тех пор, пока окно сново не приоткроется.
понятно, как раз это я и видел
а этим win можно управлять?
MaximE wrote: > > Потому что изменение размера буфера не поможет тебе управлять трафиком. > > Решения различных проблем, которые я видел управляли размерами буферов > были лишь костылями к неряшливому дизайну. Если ты увеличиваешь приемный > буфер, он рано или поздно переполнится независимо от размера если ты не > успеваешь обрабатывать запросы со скоростью их поступления. Изменение > размера буфера отсылки TCP не влияет на скорость отсылки, реализации же > UDP могут вообще не иметь буфера отсылки.
Немного не в тему.
В Виндовсе UDP'шный приемный буфер слишком маленький по дефолту. Пока
scheduler прокрутится, даже на незагруженной машинке, этот буфер легко
может переполниться. Так что UDP'шный приемный буфер есть смысл
увеличить до какой-нибудь разумной величины.
