> а теперь подумай хорошенько и скажи как ты планируешь собирать файл в
> кучу с двух потоков и еще ко всему прочему в нынешней
> ситуации в сети.Подумать всё-таки придется тебе (ну или забей и дальше не читай). Поток (для приложения, что сервера, что клиента) будет один(!). В этом суть выигрыша от технологии mptcp.
> ты что же под этот мртср всю инфрасируктуру
> сети и стеков переделать хочешь?
Тебе не зря намекали чуть выше почитать про стек протоколов, модель OSI и все такое. Тут дополняется ТОЛЬКО протокол транспортного уровня (tcp), протоколы всех остальных уровней (и выше и ниже) не затрагиваются (от слова совсем). Никакая "инфраструктура" не пострадает.
> ты хоть понимаешь что для
> такого надо как минимум чтобы прокси знал как разбивать куски данных
> на несколько потоков и нормально их маркировать, чтоб потом собрать воедино?
А как ты думаешь, сейчас, в рамках одного простого tcp-соединения, данные разбиваются? А маркируются? Хинт: tcp умеет собирать в целостный поток пакеты, пришедшие не в том порядке. И это там с самого начала так, by design. Поясню: передающее приложение отправило пакеты 1, 2, 3; на приемный комп они пришли в таком порядке - 1, 3, 2; принимающее приложение получит 1, 2, 3 (как и было отправлено). Так оно работает уже сейчас. Ещё один хинт: данные между приложениями (и между несколькими соединениями одного приложения), кстати, тоже каким-то чудом не перепутываются.
> короче минимум у твоей прокси должна быть система маркировки пакетов по
> типу торрента и на уровне хоста тоже самое, что бы стек
> мог правильно прочесть маркировку и собрать файл воедино. чем не торрент?
Тем, что торрент работает уровнем выше. И вот чтоб по аналогии работали другие приложения их надо серьезно перерабатывать (и клиенты и серверы). А с MPTCP они смогут (условно) также, но их не надо будет даже перекомпилировать.
> в третьих тогда уж надо принудить ютюб чтоб он ввел стандартизацию
> на разбивку видео на кластеры данных в видео и чтобы это
> поддерживалось в проге на стооне клиента.
Это было б надо если б узким местом были серверы и балансировщики гугла или каналы непосредственно к ним подходящие. Но скорости ограничиваются не там, а обычно гораздо ближе к клиенту. Поэтому достаточно распараллелить поток по разным каналам (причем его снова можно собрать в один позже и ускорение все равно будет). Так что от гугла ничего подобного не требуется, а распараллелить все равно получится. Можешь считать это колдунством, но достаточно чтоб ядро ОС где крутится сервер и на клиенте поддерживало MPTCP. Либо в ядре ОС прокси сервера (само приложение прокси сервера тоже может оставаться без изменений) и ядре ОС клиента.
