Artem Chuprina wrote:
Нет, если занизить скорость исходящего, это не повлияет. Они и так исходящий почти не используют - пакеты подтверждения намного меньше пакетов с содержимым. Размер TCP-шного окна уменьшать эффективно (ограничение скорости на клиенте именно так и реализовано, насколько я понимаю), но принудительное уменьшение окна без ведома выставившего его процесса - дело такое, от этого трафик может возрасти... Либо придерживать пакеты подтверждения - отправлять их не сразу, а чуть погодя. Но логика принятия решения тут будет весьма сложной, и я сомневаюсь, что существуют готовые средства...
В случае с TCP-трафиком можно отбрасывать пакеты или выставлять флаги ECN, тогда сервер уменьшит свое окно. Это делают алгоритмы семейства RED, но они предназначены только для борьбы с переполнением очереди на клиенте, а не для приоритизации или создания гарантированной полосы пропускания для входящего трафика. Думать о QoS на хилом канале в домашних условиях -- это смешно и не стоит того, чтобы тратить время. Нужно просто использовать меньше конкурирующих приложений и выставлять в них ограничения полосы пропускания.
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
