1. Так я же пишу — есть один интерфейс. Так уж получается, что у 90% людей (если не у 99%) обычно один интерфейс.
2. Не всегда. Смотреть выше ip заголовка — так протокол то нестандартный.
3. Многопоточная закачка утилизирует всю полосу пропускания, которую не удается утилизировать одним потоком tcp из-за больших задержек на сети.
Мой первый комментарий в этом треде:«А еще — как виртуальные пути будут другими если ip протокол роутит, не tcp… Только если subflow будут по другому ходить… Не понимаю. „
Я и говорю. Есть один интерфейс на клиенте, открывай потоки, не открывай — все равно пакеты одним маршрутом пойдут, потому что IP. Я это весь топик тут утверждаю. Теперь мое утверждение мне же самому и пришло :)
Я понимаю ваше мнение. И согласен с ним. Я просто одного понять не могу. Как существующая L3 инфраструктура поймет, что перед ней mptcp протокол который надо обрабатывать как то по-особому? Надо пойти почитать RFC. :)
Про много круто — я понял.
Я не понял как это технически реализуют, учитывая, что нижележащий протокол TCP — это IP. А в самом tcp даже ip адресов нет.
Вот смотри, есть приложение. заюзало оно mtcp сокет. Захотело пустить два потока разными путями. Ок. Расщепило у себя на tcp уровне эти два потока, и потом на уровень ip пришли два tcp пакета. IP уровень нацепил одинаковые src-dst адреса и отправил одним маршрутом этот праздник к другой точке.
Короче вывод из статьи и комментариев — коммерческий прогон. На досуге почитаю RFC
Я вот не пойму — а в чем прикол этого протокола? ;)
Вот с точки зрения программиста — ничего не меняется, то есть его интерфейс — послали поток байтов — получили поток байтов — и все? А для сервера, который на «доп» соединении — он с какого места в поток байтов вклиниваться будет?
А еще — как виртуальные пути будут другими если ip протокол роутит, не tcp… Только если subflow будут по другому ходить… Не понимаю.
Я не буду говорить про новые аппаратные платформы, но в 3550 когда выжиралась внутренняя память ASIC-а, те маршруты (и/или) ACL падали на процессор, который тут же умирал под трафиком.
Вот тут и непонятно — как маршрут может завязываться на интерфейс, когда интерфейс вот в таком случае, например, невидно: ip route 10.0.0.0 255.255.255.0 10.1.1.1
И тут логика должна судорожно начать работать, выясняя — каким образом, зная только 10.1.1.1 можно выяснить в какой интерфейс бросить arp запрос. (или уж во все бросать — что уж мелочиться)
Да, согласен с вышеприведенной цитатой. Ничего в ней не противоречит моему знанию классической Cisco IOS. Это я не подумал, что прием каждого пакета порождает прерывание само по себе.
Только смотря на те процессоры, что стоят в старых циско, кажется мне что там не все так драматично, как в современных (вот в современных процессорах переключение контекста — действительно операция мощная). Ну тактов 300-400 на переключение контекста тратиться то точно.
Те неточности, что я увидел «Наверняка кто-то скажет «из списка локальных интерфейсов», и жестоко ошибется. Маршрутизация так не работает.»
На мой взгляд, человеческая логика так не работает. На основании чего можно брать из списка локальных интерфейсов? Я вот не представляю. Здесь напрашивается только один вывод — запрос к таблице маршутизации — и потом послать arp запрос в соответсвии с ответом
"(хотя у process switching’а множество недостатков помимо неоптимальных запросов – например, постоянное переключение шедулера CPU между контекстами, что весьма затратно)"
Насколько я помню, в IOS платформе нет вытесняющей многозадачности. И нет постоянного переключения CPU между контекстами. Основкым преимуществом CEF была особая структура данных (mtrie), которая позволяет быстро давать нужный ответ — куда пихать пакет (что позволяет в обработчике прерывания обрабатывать пакеты), а process switching — такой структуры нет, и таблица маршрутизации не оптимизирована — то есть на каждый пакет выясняется в какой адрес интерфейс пихать, какие L3 и/или L2 заголовки применять и т.д. и т.п.
Я тебя понимаю. Но и их понимаю тоже. В общем случае там сидят люди перед которыми пустой экран и кнопка — введите ФИО номер договора, адрес подключения и номер ошибки.
Пока они эту информацию не введут — не будет перехода на следующий уровень.
А следующий уровень та же самая ерунда, только полей побольше и поспецефичней.
То есть общение с ТП — квест. Выполняй правила квеста — получишь бонус в виде быстрого разрешения проблемы. А то что компьютер к сети подключать — считай это платой за использование своего кастомного оборудования.
Статус ставиться по его ответу. Ответы у него в стиле тех, что я прислал раньше. Менеджеру не звоню — потому что тикет не срочный.
И еще. Менеджеру звонить — я тоже был наивным, звонил пару раз. Менеджер оба раза с пеной у рта защищал своих работников. В итоге через менеджера не удавалось ни повысить срочность тикета, ни перевести на другого инженера. Во втором случае я срочность повысил с помощью русского фронтлайна TAC-а. В итоге моей проблемой занималось 5(!) инженеров. Мне каждый раз назначали инженера, которому оставалось до окончанию смены — 1-2 часа. Каждый новый инженер заново задавал те же вопросы и отчаливал. И приходил следующий. И так происходило пока я не натолкнулся на инженера — энтузиаста (такого же, как автор этой темы). И он мне помог. За что ему большое спасибо.
Так будьте проще, говорите: «у меня не работает Интернет». У них мгновенно включается нужный опросник, и по опроснику вы вместе неторопливо но зато неотвратимо решаете вашу проблему.
У меня опыт такой. Разговор с первой линией — 5-10 минут при условии что все ответы уже заранее подготовлены.
А с инженером иногда бывает и на целый день разговоров. +-5 минут вопроса не решат. В любом случае инженера переспрашивают (и правильно делают)
К вопросу о профессионализме
Cisco TAC, сегодня прислал очередное сообщение. Тикет открыл неделю назад: Если спросить у профи, то эта проблема на две минуты беседы. А так, мы играем пинг в понг, он мне пишет раз в сутки и надеется что я не отвечу а в тикете будет указано что он ждет от меня реакции. Я ему отвечаю сразу, а он уходит «думать» еще на сутки.
Hi Pavel,
How are you doing today?
Let me confirm that so that I can be sure before I give you a definite answer.
2. Не всегда. Смотреть выше ip заголовка — так протокол то нестандартный.
3. Многопоточная закачка утилизирует всю полосу пропускания, которую не удается утилизировать одним потоком tcp из-за больших задержек на сети.
Я и говорю. Есть один интерфейс на клиенте, открывай потоки, не открывай — все равно пакеты одним маршрутом пойдут, потому что IP. Я это весь топик тут утверждаю. Теперь мое утверждение мне же самому и пришло :)
Я не понял как это технически реализуют, учитывая, что нижележащий протокол TCP — это IP. А в самом tcp даже ip адресов нет.
Вот смотри, есть приложение. заюзало оно mtcp сокет. Захотело пустить два потока разными путями. Ок. Расщепило у себя на tcp уровне эти два потока, и потом на уровень ip пришли два tcp пакета. IP уровень нацепил одинаковые src-dst адреса и отправил одним маршрутом этот праздник к другой точке.
Короче вывод из статьи и комментариев — коммерческий прогон. На досуге почитаю RFC
Вот с точки зрения программиста — ничего не меняется, то есть его интерфейс — послали поток байтов — получили поток байтов — и все? А для сервера, который на «доп» соединении — он с какого места в поток байтов вклиниваться будет?
А еще — как виртуальные пути будут другими если ip протокол роутит, не tcp… Только если subflow будут по другому ходить… Не понимаю.
И тут логика должна судорожно начать работать, выясняя — каким образом, зная только 10.1.1.1 можно выяснить в какой интерфейс бросить arp запрос. (или уж во все бросать — что уж мелочиться)
Только смотря на те процессоры, что стоят в старых циско, кажется мне что там не все так драматично, как в современных (вот в современных процессорах переключение контекста — действительно операция мощная). Ну тактов 300-400 на переключение контекста тратиться то точно.
«Наверняка кто-то скажет «из списка локальных интерфейсов», и жестоко ошибется. Маршрутизация так не работает.»
На мой взгляд, человеческая логика так не работает. На основании чего можно брать из списка локальных интерфейсов? Я вот не представляю. Здесь напрашивается только один вывод — запрос к таблице маршутизации — и потом послать arp запрос в соответсвии с ответом
"(хотя у process switching’а множество недостатков помимо неоптимальных запросов – например, постоянное переключение шедулера CPU между контекстами, что весьма затратно)"
Насколько я помню, в IOS платформе нет вытесняющей многозадачности. И нет постоянного переключения CPU между контекстами. Основкым преимуществом CEF была особая структура данных (mtrie), которая позволяет быстро давать нужный ответ — куда пихать пакет (что позволяет в обработчике прерывания обрабатывать пакеты), а process switching — такой структуры нет, и таблица маршрутизации не оптимизирована — то есть на каждый пакет выясняется в какой адрес интерфейс пихать, какие L3 и/или L2 заголовки применять и т.д. и т.п.
Пока они эту информацию не введут — не будет перехода на следующий уровень.
А следующий уровень та же самая ерунда, только полей побольше и поспецефичней.
То есть общение с ТП — квест. Выполняй правила квеста — получишь бонус в виде быстрого разрешения проблемы. А то что компьютер к сети подключать — считай это платой за использование своего кастомного оборудования.
И еще. Менеджеру звонить — я тоже был наивным, звонил пару раз. Менеджер оба раза с пеной у рта защищал своих работников. В итоге через менеджера не удавалось ни повысить срочность тикета, ни перевести на другого инженера. Во втором случае я срочность повысил с помощью русского фронтлайна TAC-а. В итоге моей проблемой занималось 5(!) инженеров. Мне каждый раз назначали инженера, которому оставалось до окончанию смены — 1-2 часа. Каждый новый инженер заново задавал те же вопросы и отчаливал. И приходил следующий. И так происходило пока я не натолкнулся на инженера — энтузиаста (такого же, как автор этой темы). И он мне помог. За что ему большое спасибо.
А с инженером иногда бывает и на целый день разговоров. +-5 минут вопроса не решат. В любом случае инженера переспрашивают (и правильно делают)
Cisco TAC, сегодня прислал очередное сообщение. Тикет открыл неделю назад: Если спросить у профи, то эта проблема на две минуты беседы. А так, мы играем пинг в понг, он мне пишет раз в сутки и надеется что я не отвечу а в тикете будет указано что он ждет от меня реакции. Я ему отвечаю сразу, а он уходит «думать» еще на сутки.
Hi Pavel,
How are you doing today?
Let me confirm that so that I can be sure before I give you a definite answer.
Regards,
Engineer-Customer Support (Wireless)