Увеличение скорости отправки данных за счёт скорости приёма
У меня ADSL-подключение, и я каждый раз испытываю сложности, когда мне нужно отправить кому-нибудь большой файл. Потому что скорость отправки примерно в 10 раз ниже, чем скорость скачивания из инета.
Почему бы не увеличить скорость отправки за счёт скорости приёма? Я придумал хитрый способ это сделать, не переделывая оборудование (в этом интерес задачи), но пока что не уверен в его эффективности. Этот пост — не заявка, а просто попытка проверить теорию. Может быть, всё это ерунда?
Примеры из жизни
Представьте себе очень пьяного посетителя ресторана и очень (т)резвого официанта. До такой степени, что пока посетитель будет произносить «Картофель, запеченный в духовке с овощами и сыром», официант уже успеет перебрать все блюда из меню, и человеку останется лишь сказать «да» в нужный момент. Очевидно, что скорость заказа увеличивается случайным образом (если повезёт, то нужное блюдо окажется в начале произнесённого списка, а если нет?)
Другой пример: автодополнения в Яндексе. Пишем «при», мгновенно вылезает подсказка «призрак оперы мюзикл», кликнуть по которой быстрее, чем набивать весь текст по буквам. Здесь тоже нет гарантии, что среди 10 подсказок сразу появится нужная, однако по мере набора текста вероятность отгадывания повышается.
Проверка теории
Допустим, нам надо передать число 493.
Примерно так это число выглядит в битах, если не использовать сжатие:
0100.1001.0011 — 12 битов
Пусть скорость отправки = 1 бит в минуту.
Нам надо отправить 12 битов, и обычно это заняло бы 12 минут.
Чтобы увеличить скорость отправки минимум в 3 раза, за первые 4 минуты мы должны успеть получить на вход все возможные варианты, и успеть ответить «да, это оно».
Сработает ли метод, если мы можем отправлять «да/нет» только в дискретные промежутки времени?
Чтобы это понять, вспомним официанта: допустим, у нас есть 4 минуты, и мы можем говорить «да» строго по часам, раз в минуту: в конце первой минуты, второй, и так далее. Таким образом, четырьмя ответами мы можем выбрать всего лишь из 16 блюд методом бинарного поиска (от 0000 до 1111 в двоичной системе).
Мы НЕ можем сказать «да» именно в тот момент, когда официант произносит нужное нам блюдо, и это плохо.
Знаете, как за 10 вопросов на «да/нет» отгадать число от 1 до 1000?
Твоё число больше 500?
Да → Больше 750?
Нет → Больше 250?
И так далее, пока не отгадаем.
Это и есть метод бинарного поиска.
Но выбора из 16 вариантов явно недостаточно, чтобы определить число 493. Нам нужен выбор минимум из 1000.
Условия применимости
Придуманный метод может сработать только в таком случае:
— нет жёсткой синхронизации ответов по времени (мы можем говорить в любой момент),
— скорость приёма колоссально превышает скорость отправки (официант говорит гораздо быстрее нас).
Вернёмся к задаче
0100.1001.0011 — 12 битов
За первые 4 минуты мы должны успеть получить на вход все возможные варианты, и успеть ответить «да, это оно».
Самый простой способ: перебор всех вариантов от 0 до 999, это нужно успеть сделать за первые 3 минуты, чтобы, если наше число = 999, то наш ответ «Да» в конце 3-й минуты закончился как раз к концу 4-й минуты. Напомню, что наш ответ длится 1 минуту.
Наше число = 493, и мы ответим «Да» уже на 2,5 минутах, а начиная с 3,5 минут мы будем отгадывать уже следующее число.
По итогам расчётов, ситуация получилась из области фантастики:
скорость приёма = ( 9 битов × 1000 ) / 3 минуты = 3000 битов в минуту,
то есть, в 3 тысячи раз больше скорости отправки.
За 3 минуты к нам придёт такая последовательность:
0000000000
0000000001
...
1111111111
(1000 пакетов по 9 битов)
Вывод: отгадывания эффективны в человеческом мире, где есть слова, образы, смысл, но почти бесполезны в мире компьютеров. Идея оказалась провальной :)
P.S. Ещё вариант: пока канал отправки свободен, его можно задействовать в фоновом режиме, отправляя какой-нибудь контенто-зависимый алфавит (который будет генериться в зависимости от того, над чем я работаю — фото, видео, текст), а затем этот алфавит будет использоваться для отправки данных, за счёт этого сократится объём и время передачи. Очевидно, что заметного прироста скорости не будет.
