форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
Сообщение от opennews (ok) on 28-Сен-15, 11:10
После более года разработки для ядра Linux доступна (http://multipath-tcp.org/pmwiki.php?n=Main.Release90) новая версия (0.90) расширения MPTCP (http://multipath-tcp.org) (MultiPath TCP), которое позволяет организовать (http://multipath-tcp.org/pmwiki.php/Users/ConfigureRouting) работу TCP-соединения с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, привязанные к разным IP-адресам. Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP. Новая версия выполнена в виде патча для ядра Linux 3.18. Бинарные пакеты собраны (http://multipath-tcp.org/pmwiki.php?n=Users.AptRepository) для Ubuntu 14.04 (amd64) и Debian Squeeze  (amd64, i386). Multipath TCP может использоваться как для расширения пропускной способности, так и для увеличения надёжности. В качестве одного из практических применений Multipath TCP для обычных пользователей упоминается возможность организации передачи данных на смартфоне, с использованием одновременно линков WiFi и 3G. Для серверных систем Multipath TCP может обеспечить сокращение расходов за счёт использования нескольких дешевых линков вместо одного более дорогого. В новой версии: -  В состав включен  алгоритм управления перегрузкой TCP Balia (https://tools.ietf.org/html/draft-walid-mptcp-congestion-con...) (Balanced Linked Adaptation Congestion Control Algorithm), специально реализованный для MPTCP и учитывающий балансировку потока через несколько разнородных линков; -  Добавлена поддержка  режима быстрого открытия TCP-соединений FastOpen (https://tools.ietf.org/html/draft-barre-mptcp-tfo-01) для Multipath TCP.  TCP FastOpen позволяет сократить число шагов установки соединения за счёт комбинирования в один запрос первого и второго шагов классического 3-этапного процесса согласования соединения, и давая возможность отправки данных на начальном этапе установки соединения (данные посылаются одновременно с SYN-сегментом); -  Улучшена поддержка опций настройки TCP-сокета; -  Возможность настройки метода контроля перегрузки для отдельных потоков через опцию настройки сокета TCP_CONGESTION; -  Поддержка неотслеживаемой (stateless) установки соединений (например, TCP SYN-Cookies); -  Возможность использования   TCP SYN-Cookies для защиты web-серверов от SYN-флуда; -  Добавлены дополнительные счётчики  MIB/SNMP  для статистики и отладки; -  Поддержка мониторинга за состоянием MPTCP через команду  "netstat -s" (требуется установка модифицированной версии (http://multipath-tcp.org/pmwiki.php/Users/Tools) пакета net-tools); -  Проведение работы по оптимизации производительности. URL: http://multipath-tcp.org/pmwiki.php?n=Main.Release90 Новость: http://www.opennet.me/opennews/art.shtml?num=43054
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–7 +/–
Сообщение от Snaut (ok) on 28-Сен-15, 11:10
>>> давая возможность отправки данных на начальном этапе установки соединения (данные посылаются одновременно с SYN-сегментом); отличная дыра для ddos. теперь серверу мало того, что надо будет открыть соединение - так еще и обработать что находится внутри пакета.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	4. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+1 +/–
	Сообщение от Аноним (??) on 28-Сен-15, 11:31
	ЭТО (tcp fast open) уже относительно есть в классическом tcp, и даже работает, и даже дефолтно. http://kernelnewbies.org/Linux_3.13#head-159ff61ea3acfd67b88...
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	6. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–4 +/–
	Сообщение от Snaut (ok) on 28-Сен-15, 11:35
	> ЭТО (tcp fast open) уже относительно есть в классическом tcp, и даже > работает, и даже дефолтно. > http://kernelnewbies.org/Linux_3.13#head-159ff61ea3acfd67b88... ну подобное нужно для real-time систем. на кой оно по дефолту не понятно
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	8. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от XXasd on 28-Сен-15, 12:39
	то есть пользователи не real-time -- должны страдать? :-)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	10. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–1 +/–
	Сообщение от Аноним (??) on 28-Сен-15, 12:47
	Если он сам хочет страдать - никакое отсутствие fast-open ему помешать не в силах.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

3. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
Сообщение от анон on 28-Сен-15, 11:25
А в меинлаин не хотят впихнуть?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+1 +/–
Сообщение от б.б. on 28-Сен-15, 11:34
в смысле, в основном ядре этого разве нет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+3 +/–
	Сообщение от Alex (??) on 28-Сен-15, 11:57
	MPTCP? Пока нет. Вообще штука очень интересная, особенно с учётом того, что даёт возможность очень просто строить распределённую балансировку.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–3 +/–
Сообщение от fail on 28-Сен-15, 12:43
>с доставкой пакетов одновременно по нескольким маршрутам через разные сетевые интерфейсы, Ы, "нафейхуа" - одновременно ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+3 +/–
Сообщение от fail on 28-Сен-15, 12:47
...схоже, на попытку выбивания и освоения грантофф - пeреизобрeтением SСTР
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	12. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от anonymous (??) on 28-Сен-15, 13:09
	Утверждается, что оно лучше работает с ущербными роутерами и файрволлами, не знающими ни о чем, кроме TCP и UDP
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	21. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+3 +/–
	Сообщение от Demo (??) on 28-Сен-15, 22:30
	Вот поэтому в Интернете всё как-то кривенько и через ж… Напомнило как мы долго бились с проблемой невозможности связать через Watson-овские бриджи рабочую станцию управления с STM-1 мультиками, хотя локально по 10BASE-2 всё летало "на ура!". В итоге, через пол-дня разбирательств, выяснилось, что все Ethertype-ы кроме IP отфильтровывались бриджами как некорректные. Видимо инженеры Watson-а о CLNP и слыхом не слыхивали. Да что тут говорить о CLNP, если IPX им тоже не знаком. Выросло поколение инженеров, не знающих ничего, кроме IP, будто и не было ничего ни до ни после…
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
Сообщение от orgkhnargh (ok) on 28-Сен-15, 14:30
То есть, если у меня есть 2 свистка по 2 мегабита от разных операторов, то с помощью MPTCP я смогу получить 4 мегабита вкупе и можно будет качество видео на ютубе повыше сделать?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–6 +/–
	Сообщение от slavius on 28-Сен-15, 14:37
	а ты ютубу сначала скажи что ты качаешь в два свистка)) да и повозись чтоб это все собиралось в один файл и кормилось твоему плееру. нет конечно можно наваять скрипт на коленке, но боюсь  что скриптик получится не маленький. придется делать что то типа торрента. кстати для торрента должно быть неплохо. опять же надо проверять.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	16. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Аноним (??) on 28-Сен-15, 16:58
	А разве не в этом смысл MultiPath TCP, чтобы снять эту работу с приклада?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	18. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+1 +/–
	Сообщение от Аноним (??) on 28-Сен-15, 18:12
	«Для сетевых приложений подобное агрегированное соединение выглядит как обычное TCP-соединение, вся логика разделения потоков выполняется силами MPTCP.» Никому ничего объяснять не надо. Главное, чтобы Ютуб понимал MPTCP, но это можно решить при помощи промежуточного прокси-сервера.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	23. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–2 +/–
	Сообщение от slavius on 28-Сен-15, 22:43
	а ты подумал че сказал? ты каким макаром собрался объяснить ютубу что ты качаешь с одного компа но в два потока.? он то увидит 2 ip? и ко всему прочему надо чтоб ютуб отдавал данные пачками и это все дело маркировалось по положению в файле, точь в точь как торрент, или ты собрался смотреть 2 версии одного и того же через свой плеер? тогда в чем суть. что один канал что 2.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	30. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+1 +/–
	Сообщение от Alex (??) on 29-Сен-15, 08:09
	Самовыпились, а. MPTCP именно тем и занимается, что изолирует многоканальность от приложения. Приложение 2 IP не увидит, а вот MPTCP - увидит.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	24. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–3 +/–
	Сообщение от slavius on 28-Сен-15, 22:53
	еще добавлю прокси сервер тебе не разделит потоки и он же создаст ситуацию при которой один поток останется не у дел. фишка в том и есть что с одного компа норазных сетевух и разных ip/ нафига копья ломать тогда, сразу увеличил скорость и все. а вот торрент из этого действительно пользу извлечет. и вообще чисто сетевые проги , работающие на скачку. опять же будет разве что возможность распределения мощностей, но это и раньше можно было сделать при наличии двух сетевух и ip. в чем соль пока не понял, для просмотра видео её пока точно нет.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	26. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+5 +/–
	Сообщение от Ytch (ok) on 29-Сен-15, 01:05
	> еще добавлю прокси сервер тебе не разделит потоки Что ему помешает? Из примера выше - прокси сидит, к примеру, на 10 мегабитном канале до ютуба и оттуда тянет "классически". Одновременно он "знает", что этот контент надо отдавать как multipath на ip1 и ip2, но это одно и то же логическое tcp-соединение (прокси, само собой, multipath должен поддерживать). Почему он не сможет задействовать 2 канала по 2 мегабита (ip1 и ip2) для отдачи того что тянет по 10 мегабитному с ютуба тем самым вдвое поднимая скорость скачивания видео с точки зрения клиента? Грубо и крайне упрощенно - почему он не может кидать последовательные куски данных, приходящих с ютуба попеременно то на ip1, то на ip2. Всё что нужно ему "понимать", что ack приходящие и c ip1 и с ip2 в рамках этого соединения это один и тот же "интегральный" ack. Посылает seq1 на ip1, seq2 на ip2, seq3 на ip1 (несмотря на то что seq2 туда не отправлялся), seq4 на ip2 (несмотря на то что seq3 туда не отправлялся) - главное, что если, к примеру придет ack4 c ip2, то он должен "понять", что это подтверждение всем seq1-4 независимо от того куда те были отправлены. При этом загружены оба канала, то есть пропускная способность выросла вдвое (для ясности не будем рассматривать "неодинаковость" каналов, пропадания пакетов и прочую классическую сетевую муть, с которой все это естсественно справляется). Это очень-очень упрощенно, естественно. И нет никакой разницы видео это или ещё что-то, в одну сторону или в обе сразу идет передача, и даже вообще не важно что за протокол работает поверх tcp. > нафига копья ломать тогда, сразу увеличил скорость и все. А, так можно просто поднять скорость канала и всех делов? Как просто все решается... > а вот торрент из этого действительно пользу извлечет Торрент и так может извлечь пользу из наличия двух каналов безо всяких MultipathTCP - ему, по самой его сути, не надо брать данные из одного соединения. Как и простое скачивание с http (при помощи range) тоже может и без этих фокусов с MultipathTCP загрузить 2 независимых канала скачиванием разных частей одного и того же без необходимости вообще модифицировать сервер. Это как раз случаи когда от MultipathTCP ни холодно ни жарко с точки зрения загрузки канала(ов). Фишка в том что тут потенциально можно так использовать вообще любой протокол поверх tcp причем вообше незаметно для прикладухи. > это и раньше можно было сделать при наличии двух сетевух и ip. Разных ip. В разных сетях. И при этом получается (для клиента) одно(!) tcp-соединение, что позволяет использовать существующие протоколы поверх tcp, даже не предполагающие множественных подключений к одним и тем же данным.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	46. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–3 +/–
	Сообщение от slavius on 30-Сен-15, 01:08
	а теперь подумай хорошенько и скажи как ты планируешь собирать файл в кучу с двух потоков и еще ко всему прочему в нынешней ситуации в сети. ты что же под этот мртср всю инфрасируктуру сети  и стеков переделать хочешь? ты хоть понимаешь что для такого надо как минимум чтобы прокси знал как разбивать куски данных на несколько потоков и нормально их маркировать, чтоб потом собрать воедино? короче минимум у твоей прокси должна быть система маркировки пакетов по типу торрента и на уровне хоста тоже самое, что бы стек мог правильно прочесть маркировку и собрать файл воедино. чем не торрент? в третьих тогда уж надо принудить ютюб чтоб он ввел стандартизацию на разбивку видео на кластеры данных в видео и чтобы это поддерживалось в проге на стооне клиента. тогда да будет существенное повышение производительности загрузки файлов. но .... ты видел волка в бане парившись)))
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	47. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от angra (ok) on 30-Сен-15, 05:05
	Почитай уже для самообразования https://en.wikipedia.org/wiki/OSI_model Оно конечно не ложится напрямую на tcp/ip стек, но хотя бы даст понимание, что такое различные уровни сетевых протоколов. А вот когда(или если) разберешься, то перечитай внимательно предыдущий пост, там тебе все доступно объяснили.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	50. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–1 +/–
	Сообщение от slavius on 30-Сен-15, 09:49
	увы читал)) и поэтому говорю. модернизировать придется как минимум видеопередачу или так любимый тобой прокси. иначе никак.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	51. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от angra (ok) on 30-Сен-15, 13:54
	Читал, но ничего не понял? Бывает, может еще рано, а может вообще не твое это. В таком случае я бы посоветовал не влезать в дискуссии на тему сетевых протоколов, рассуждай о том, в чем разбираешься.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

	52. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Ytch (ok) on 30-Сен-15, 23:48
	> а теперь подумай хорошенько и скажи как ты планируешь собирать файл в > кучу с двух потоков и еще ко всему прочему в нынешней > ситуации в сети. Подумать всё-таки придется тебе (ну или забей и дальше не читай). Поток (для приложения, что сервера, что клиента) будет один(!). В этом суть выигрыша от технологии mptcp. > ты что же под этот мртср всю инфрасируктуру > сети  и стеков переделать хочешь? Тебе не зря намекали чуть выше почитать про стек протоколов, модель OSI и все такое. Тут дополняется ТОЛЬКО протокол транспортного уровня (tcp), протоколы всех остальных уровней (и выше и ниже) не затрагиваются (от слова совсем). Никакая "инфраструктура" не пострадает. > ты хоть понимаешь что для > такого надо как минимум чтобы прокси знал как разбивать куски данных > на несколько потоков и нормально их маркировать, чтоб потом собрать воедино? А как ты думаешь, сейчас, в рамках одного простого tcp-соединения, данные разбиваются? А маркируются? Хинт: tcp умеет собирать в целостный поток пакеты, пришедшие не в том порядке. И это там с самого начала так, by design. Поясню: передающее приложение отправило пакеты 1, 2, 3; на приемный комп они пришли в таком порядке - 1, 3, 2; принимающее приложение получит 1, 2, 3 (как и было отправлено). Так оно работает уже сейчас. Ещё один хинт: данные между приложениями (и между несколькими соединениями одного приложения), кстати, тоже каким-то чудом не перепутываются. > короче минимум у твоей прокси должна быть система маркировки пакетов по > типу торрента и на уровне хоста тоже самое, что бы стек > мог правильно прочесть маркировку и собрать файл воедино. чем не торрент? Тем, что торрент работает уровнем выше. И вот чтоб по аналогии работали другие приложения их надо серьезно перерабатывать (и клиенты и серверы). А с MPTCP они смогут (условно) также, но их не надо будет даже перекомпилировать. > в третьих тогда уж надо принудить ютюб чтоб он ввел стандартизацию > на разбивку видео на кластеры данных в видео и чтобы это > поддерживалось в проге на стооне клиента. Это было б надо если б узким местом были серверы и балансировщики гугла или каналы непосредственно к ним подходящие. Но скорости ограничиваются не там, а обычно гораздо ближе к клиенту. Поэтому достаточно распараллелить поток по разным каналам (причем его снова можно собрать в один позже и ускорение все равно будет). Так что от гугла ничего подобного не требуется, а распараллелить все равно получится. Можешь считать это колдунством, но достаточно чтоб ядро ОС где крутится сервер и на клиенте поддерживало MPTCP. Либо в ядре ОС прокси сервера (само приложение прокси сервера тоже может оставаться без изменений) и ядре ОС клиента.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	53. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от angra (ok) on 01-Окт-15, 02:02
	> А как ты думаешь, сейчас, в рамках одного простого tcp-соединения, данные разбиваются? > А маркируются? Хинт: tcp умеет собирать в целостный поток пакеты, пришедшие > не в том порядке. И это там с самого начала так, > by design. Поясню: передающее приложение отправило пакеты 1, 2, 3; на > приемный комп они пришли в таком порядке - 1, 3, 2; > принимающее приложение получит 1, 2, 3 (как и было отправлено). Так > оно работает уже сейчас. Ещё один хинт: данные между приложениями (и > между несколькими соединениями одного приложения), кстати, тоже каким-то чудом не перепутываются. Ну ты ему еще мозг взорви рассказом про MTU и фрагментацию пакетов. Мало того, что пакеты могут приходить не в том порядке, так еще и разорванными на части, которые тоже в свою очередь могут прийти не в том порядке. Не забудем, что пакеты или фрагменты могут биться или теряться в процессе пересылки и происходит ретрансмиссия, опять нарушая порядок. И все это без каких-либо торрентов собирается воедино уже десятки лет и приложений этот процесс вообще не касается. Черная магия, не иначе.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	39. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Аноним (??) on 29-Сен-15, 18:39
	> в чем соль пока не понял Это точно.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	15. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–3 +/–
	Сообщение от Bobik on 28-Сен-15, 14:39
	Нет.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	19. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+2 +/–
	Сообщение от Аноним (??) on 28-Сен-15, 18:12
	> Нет. Ламера ответ.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+1 +/–
	Сообщение от bugmenot (??) on 28-Сен-15, 17:46
	Да.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	29. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Alex (??) on 29-Сен-15, 08:07
	Именно так, если на стороне ютуба будет поддержка MPTCP.
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	40. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от orgkhnargh (ok) on 29-Сен-15, 21:59
	> Именно так, если на стороне ютуба будет поддержка MPTCP. То есть, работать будет примерно как бондинг, но внешний сервер поднимать отдельно не надо?
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	41. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Alex (??) on 29-Сен-15, 22:05
	> То есть, работать будет примерно как бондинг, но внешний сервер поднимать отдельно > не надо? Это и есть бондинг, только на уровне отдельного виртуального соединения TCP, состоящего фактически из нескольких :)
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	42. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Alex (??) on 29-Сен-15, 22:07
	Если проще - то "да". С некоторыми оговорками, например, что каналы вполне могут быть совершенно разноскоростными и с разным уровнем потерь.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

	54. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Bobik on 02-Окт-15, 13:52
	Оговорка одна ютуб ету херню не поддержывает и по етому работать оно не будет, а рассуждать можно много очом.
	Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

20. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–1 +/–
Сообщение от Аноним (??) on 28-Сен-15, 18:54
лучше бы sctp внедряли где попало
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Demo (??) on 28-Сен-15, 22:33
	> лучше бы sctp внедряли где попало SCTP богомерзкой телефонией попахивает, а это сегодня не в трэнде.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	27. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–1 +/–
	Сообщение от Crazy Alex (ok) on 29-Сен-15, 01:57
	И правильно, что не в тренде. Телефонисты что-то понятное и удобное в эксплуатации отродясь сделать не могли. И до сих пор не могут - одна идея "телефонного номера" фиксированной длины чего стоит.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	28. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Ytch (ok) on 29-Сен-15, 03:07
	> Телефонисты что-то понятное и удобное в > эксплуатации отродясь сделать не могли. Ну не совсем так, мягко выражаясь. У них было множество весьма неплохих инженерных решений на разных этапах развития (последние пару десятилетий не считаем). Вообще, по моим наблюдениям, они делают что-то хорошее и остроумное только при очень ограниченных технических ресурсах. Когда они переходили на цифру и цифровые мультиплексирования разных поколений в разное время все ещё было неплохо и с идеями и с реализациями, но речь тогда шла про "их епархию" - коммутацию каналов, хоть и в цифре. Да и вычислиловка ещё была слабовата и дороговата - приходилось думать. Хотя склонности к лютому overengineering'у у них всегда проявлялись, но технические возможности их как-то сдерживали и было более или менее норм (я сейчас про чисто технические, инжернерные решения - не касаясь инфраструктурных дел и всякого прочего). Вот когда они полезли в сети с коммутацией пакетов и вычислительные ресурсы стали позволять не особо проявлять инженерную смекалку, тут да, их прорвало и из них поперли тонны откровенно переусложненного и дико неудобного г$*на (в смысле предлагаемых решений). И тут всем на руку оказалось что на этом поле не они одни могут играть. > И до сих пор не могут Вот сейчас, в последние лет примерно 20 - да, соглашусь. Сплошной шлак какой-то. > - одна идея "телефонного номера" фиксированной длины чего стоит. Ну, во-первых, это традиция и это (было)удобно и людям и технически (ещё со времен шаговых искателей), а во-вторых, это, извините, неправда и очень давно (номерам 01, 02, 03..., например, "сто лет в обед"). Для широкого круга, да, они это не делали в разное время по разным причинам - да и сейчас не факт что большинство с энтузиазмом воспримет идею - они вынуждены рассчитывать и на бабушек в том числе, а уж в этой среде традиции ого-го как сильны )), даже несмотря на то, что некоторые "продвинутые" бабушки вполне себе, например, справляются со skype, но юмор в изменении принципов формирования телефонных номеров вряд ли оценят. С мобильными ещё как-то можно было б, но там фиксированные длины номеров это уже такая мелочь по сравнению с остальным дерьмом "под капотом". Да и нет у "телефонистов" уже той "власти" над "умами и коммуникациями" (и это хорошо, имхо) - подобные трюки лет 15-20 назад они ещё может и могли б провернуть, а сейчас я сильно сомневаюсь.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	36. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Аноним (??) on 29-Сен-15, 15:43
	X.400 (невзлетевшая типа электропочта), X.500 — это все а) невообразимейший ужас; б)телефонисты. Вы поинтересуйтесь на досуге, какие строковые кодировки для использования в X.509 сертификатах были разрешены (например, здесь: https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt , да там весь документ интересный).
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	48. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от t28 on 30-Сен-15, 09:28
	> X.400 (невзлетевшая типа электропочта) Не надо "ля-ля". Всё работает, где надо.
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	31. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+3 +/–
	Сообщение от Alex (??) on 29-Сен-15, 08:13
	> И правильно, что не в тренде. Телефонисты что-то понятное и удобное в > эксплуатации отродясь сделать не могли. И до сих пор не могут > - одна идея "телефонного номера" фиксированной длины чего стоит. А то, что у IPv4/v6/Ethernet/whatever адрес фиксированной длины, тебя не смущает?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	37. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–2 +/–
	Сообщение от Crazy Alex (ok) on 29-Сен-15, 16:01
	Не смущает. Это адрес для машины, а не для человека. Вот если бы фиксированной длины (да ещё контекстно-зависимой от моего положения) были имена в скайпе или имена доменов - смущало бы, и ещё как.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	43. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+1 +/–
	Сообщение от Alex (??) on 29-Сен-15, 22:07
	А для человека у телефонистов есть телефонный справочник. Аналог DNS, по сути. Книжка такая толстая.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	32. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+1 +/–
	Сообщение от Alex (??) on 29-Сен-15, 08:14
	Кстати в ISDN номера далеко не фиксированной длины.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	38. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–1 +/–
	Сообщение от Crazy Alex (ok) on 29-Сен-15, 16:03
	И всё равно везде всё прибито гвоздями к номерным планам с фиксированной длиной номера, префиксами выхода и подобной мутью. Хотя, например, доменная система смотрелась бы куда лучше и на современных ресурсах ни малейших проблем по ресурсам не составила бы.
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	44. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+1 +/–
	Сообщение от Alex (??) on 29-Сен-15, 22:09
	> И всё равно везде всё прибито гвоздями к номерным планам с фиксированной > длиной номера, префиксами выхода и подобной мутью. Хотя, например, доменная система > смотрелась бы куда лучше и на современных ресурсах ни малейших проблем > по ресурсам не составила бы. Ну в интернетах всё прибито к IPv4 фиксированной длины точно так же. С IPv6 всё вообще ужасно, оно ещё и не человеко-запоминаемо. DNS DNS'ом, а прямые адреса вбивать всё равно приходится. Даже ендюзерам иногда.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	49. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от t28 on 30-Сен-15, 09:37
	> И всё равно везде всё прибито гвоздями к номерным планам В The Internet-е так же. Адресация гвоздями прибита к Route Database, и пока Regional Registry не заапрувит и не внесёт ваши данные в базу, полноценно пользоваться своими префиксами вы не сможете.
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

25. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	–2 +/–
Сообщение от InventoR (??) on 28-Сен-15, 23:27
Мне не интересен трафик, мне интересно, эта штука наконец поможет сбалансировать и сделать отказоустойчивость в managment интерфейсе кластера, пусть даже прокса? Строить агрегацию на базе разных свичей обьеденых в стек это безумие, а вот поставить два простых свича и построить managment с этой штукой было бы здорово.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	35. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Demo (??) on 29-Сен-15, 10:48
	Нормальный Management должен быть OOB.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

33. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+3 +/–
Сообщение от Alex (??) on 29-Сен-15, 08:23
Есть у MPTCP ещё одна хитрость при использовании нескольких операторов: всякие СОРМы и прочие будут ссать кровавыми слезами, потому что трафик собрать воедино скорее всего не получится. А с TLS - еще хуже.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Петушок on 29-Сен-15, 10:02
	> Есть у MPTCP ещё одна хитрость при использовании нескольких операторов: всякие СОРМы > и прочие будут ссать кровавыми слезами, потому что трафик собрать воедино > скорее всего не получится. А с TLS - еще хуже. Неуловимый, ты никому не нужен
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	45. "Выпуск MPTCP 0.90 (Multipath TCP) для Linux"	+/–
	Сообщение от Alex (??) on 29-Сен-15, 22:10
	> Неуловимый, ты никому не нужен Мне вообще давно пох, нужен я или нет )
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема