Комментарии 42
Ммм… Я всегда считал, что PAK priority работает не для транзитного в data plane трафика, а для трафика, выходящего из control plane в data plane. Если это так — то для трафика телеграма этот механизм бесполезен.
Не исключаю, что я считал неправильно, но, например, http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html говорит как раз о том, что «The RIP and OSPF routing processes that run on the core CPU of a router mark all traffic they originate with both IP precedence 6 and pak_priority». Тут важно, что это именно процессы контрол-плейна, создающие трафик. А разбирать транзитный трафик в датаплейне на предмет развешивания на них неуправляемых приоритетных флагов, было бы не только трудоемко, но и несколько опрометчиво.
Не исключаю, что я считал неправильно, но, например, http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-congestion-management-queueing/18664-rtgupdates.html говорит как раз о том, что «The RIP and OSPF routing processes that run on the core CPU of a router mark all traffic they originate with both IP precedence 6 and pak_priority». Тут важно, что это именно процессы контрол-плейна, создающие трафик. А разбирать транзитный трафик в датаплейне на предмет развешивания на них неуправляемых приоритетных флагов, было бы не только трудоемко, но и несколько опрометчиво.
Вы всё верно пишите. PAK_priority — сугубо внутренняя функция маршрутизатора.
Наиболее важные пакеты, генерируемые control plane'ом маршрутизатора, маркируются внутренним идентификатором pak_priority. Такие пакеты маршрутизатор будет стараться передавать в первую очередь и не отбрасывал при переполнении исходящей очереди. Флаг pak_priority в отличии от IPP/DSCP может назначаться не только IP-пакетам. Что очень важно для передачи пакетов(кадров) IS-IS, ARP, PPP и пр.
Pak_priority работает только для исходящих пакетов.
В самой сети pak_priority флаг никак не фигурирует. Он не представлен ни в одном заголовке пакета. Там работают флаги IPP/DSCP.
Что касается статьи уважаемого crypby, было бы интересно посмотреть не на порт, который использует телеграм, а на значения IPP/DSCP. Т.е. как раскрашиваются пакеты. Именно это зачастую определяет то, как данный пакет будет обрабатываться в сети (при использовании модели DiffServ). Промежуточное устройство смотрит на значения IPP/DSCP в пакете и уже на основании их принимает решения, как его обработать в плане QoS (в какую очередь поместить, как дропать в случае переполнении и пр.).
При этом в сети интернет значения IPP/DSCP чаще всего игнорируются или же просто сбрасываются, чтобы обычные пользователи не могли влиять, как им вздумается, на обработку пакетов промежуточными устройствами.
В связи с этим у меня есть больше сомнения, что использование порта 520 с закосом под RIP, хоть как-то способствует лучшей проходимости трафика через сеть интернет.
Наиболее важные пакеты, генерируемые control plane'ом маршрутизатора, маркируются внутренним идентификатором pak_priority. Такие пакеты маршрутизатор будет стараться передавать в первую очередь и не отбрасывал при переполнении исходящей очереди. Флаг pak_priority в отличии от IPP/DSCP может назначаться не только IP-пакетам. Что очень важно для передачи пакетов(кадров) IS-IS, ARP, PPP и пр.
Pak_priority работает только для исходящих пакетов.
В самой сети pak_priority флаг никак не фигурирует. Он не представлен ни в одном заголовке пакета. Там работают флаги IPP/DSCP.
Что касается статьи уважаемого crypby, было бы интересно посмотреть не на порт, который использует телеграм, а на значения IPP/DSCP. Т.е. как раскрашиваются пакеты. Именно это зачастую определяет то, как данный пакет будет обрабатываться в сети (при использовании модели DiffServ). Промежуточное устройство смотрит на значения IPP/DSCP в пакете и уже на основании их принимает решения, как его обработать в плане QoS (в какую очередь поместить, как дропать в случае переполнении и пр.).
При этом в сети интернет значения IPP/DSCP чаще всего игнорируются или же просто сбрасываются, чтобы обычные пользователи не могли влиять, как им вздумается, на обработку пакетов промежуточными устройствами.
В связи с этим у меня есть больше сомнения, что использование порта 520 с закосом под RIP, хоть как-то способствует лучшей проходимости трафика через сеть интернет.
Телеграм не забанят, так как использование стандартного порта протокола RIP (520) никак не влияет на обработку этого трафика на промежуточных устройствах, тем более в сети интернет. Он ничем не будет выделяться среди другого трафика. Приоритет определяется значениями IPP/DSCP, при условии, что сеть настроена их учитывать. А сеть интернет по своей природе, как мы знаем, best effort (весь трафик обрабатывает с одинаковым приоритетом).
Добрая половина этой статьи рассказывает про приоритезацию пакетов протокола динамической маршрутизации, что к пакетам телеграм не имеет абсолютно никакого отношения. Их связывает только то, что wireshark идентифицировал телеграм, как RIP. А сделал он это, так как увидел там порт с номером 520. А это совсем не означает, что все будут думать также.
Добрая половина этой статьи рассказывает про приоритезацию пакетов протокола динамической маршрутизации, что к пакетам телеграм не имеет абсолютно никакого отношения. Их связывает только то, что wireshark идентифицировал телеграм, как RIP. А сделал он это, так как увидел там порт с номером 520. А это совсем не означает, что все будут думать также.
я надеюсь, что этот телеграм нахрен забанят на магистральных каналах
Жаров, перелогиньтесь.
А мне норм. Я вчера машину смотрел по объявлению. Каробка без нареканий зашита двигателя капот обклеен противо ударной пленкой не прокуриный салон музыка с хорошим качественым телевизорам люк вовсю крышу без ключивой доступ. продает собственик. возможен обмен на грузовечка трех тоника не дороже 500 соотвецтвено с вашей доплатой. (там еще текст есть, если кому не верится, могу дать. ссылку. машина очень битая на самом деле, так что не реклама :-) )
Нормальный заголовок.
Нормальный заголовок.
Когда гоняешь кучу UDP трафика на портах протоколов маршрутизации, это может выглядеть как подозрительная активность и тебя забанят. Так же что там с фрагментацией пакетов?
MTU не превышай и фрагментации не будет. По моему опыту достаточно знать MTU подключения конечной точки, т.к. оно меньше за счет всяких VPN при подключению к инету. В самом инете стандартные 1500 отлично проходят.
Для определения MTU из конкретной точки достаточно посыла десятка пакетов с IP_DONTFRAGMENT на эхосервер в инете.
Для определения MTU из конкретной точки достаточно посыла десятка пакетов с IP_DONTFRAGMENT на эхосервер в инете.
Не разделяю восхищение "находчивостью". Ни что иное, как злоупортебление. Учитывая, что RIP таки всё же уже по большей части rip, особенно в интер-нетворкинге, может быть и подропано на некоторых пограничных маршрутизаторах. Другое дело, что у Телеграма может быть какой-то следующий fallback механизм связи на обычных портах.
Если здесь бывают ребята из команды Telegram, мне хотелось бы донести до них следующее:
Прикручивать новые полезные фишки в ваш мессенджер — хорошее дело, но не первоочередное, ПМСМ. А в качестве первоочередного я бы предложил изменить способ авторизации новых пользователей, убрав оттуда требование ввести номер своей мобилы, и придумать что-то не столь деанонимизирующее пользователя. Задача не слишком сложная — ведь, скажем, команда, разрабатывающая Токс, смогла же её решить! А до тех пор вы не заманите в свои пользователи тех, кто реально заботится о своей приватности, а также тех, кто по каким-то личным причинам не желает иметь мобилу (таких в мире всё ещё немало).
Прикручивать новые полезные фишки в ваш мессенджер — хорошее дело, но не первоочередное, ПМСМ. А в качестве первоочередного я бы предложил изменить способ авторизации новых пользователей, убрав оттуда требование ввести номер своей мобилы, и придумать что-то не столь деанонимизирующее пользователя. Задача не слишком сложная — ведь, скажем, команда, разрабатывающая Токс, смогла же её решить! А до тех пор вы не заманите в свои пользователи тех, кто реально заботится о своей приватности, а также тех, кто по каким-то личным причинам не желает иметь мобилу (таких в мире всё ещё немало).
А разве телеграм позиционируется как анонимный im?
Анонимные im — удел меньшинства готового обмениваться публичными сертификатами, общим секретом, придумывать свои механизмы синхронизации истории переписки и хранения приватного ключа. Широкой аудитории такие сложности не нужны, телеграм — это компромис между безопасностью и удобством пользования, что и обусловливает его популярность
Анонимные im — удел меньшинства готового обмениваться публичными сертификатами, общим секретом, придумывать свои механизмы синхронизации истории переписки и хранения приватного ключа. Широкой аудитории такие сложности не нужны, телеграм — это компромис между безопасностью и удобством пользования, что и обусловливает его популярность
Анонимные im — удел меньшинства готового обмениваться публичными сертификатами, общим секретом, придумывать свои механизмы синхронизации истории переписки и хранения приватного ключа.
Достаточно добавить альтернативный способ авторизации — пусть без удобств по синхронизации переписки, но зато без требования номера. Обычные пользователи будут по-прежнему выбирать авторизацию по номеру — для них ничего не изменится.
> Задача не слишком сложная — ведь, скажем, команда, разрабатывающая Токс, смогла же её решить!
Как бы нам решить, что же делать с противостоянием пчёл против мёда.
Тут нечего решать. Номер телефона здесь — абсолютно лишняя сущность, которая, естественно, приватность лишь понижает катастрофически, а не повышает.
Как бы нам решить, что же делать с противостоянием пчёл против мёда.
Тут нечего решать. Номер телефона здесь — абсолютно лишняя сущность, которая, естественно, приватность лишь понижает катастрофически, а не повышает.
Не заметил особого качества — чудовищное эхо отбило всё желание пользоваться
Вы звонили на телефон в той же комнате что ли?
Почему-то при подключении через WiFi тоже наблюдаю эхо. При звонках через мобильный интернет, качество отличное.
Вы звоните, наверное, через 2.4gHz WiFi. А соединение через секунд 10-20 после разговора подстраивается даже под самый плохой коннект. На крайний случай, после звонка всегда можно поставить 1* и написать в комменте echo. Вас заметят ;)
как же команде Telegram удалосьА им и не удалось. Подтверждаю эхо в 1 из 3 случившихся звонков. Разговаривал правда не долго, зато перезванивать пришлось, ибо звонок из сети опсоса в мой вайфай был вообще глухой. В двух других случаях через однояйцевого опсоса с обеих сторон никакой подстройки не потребовалось, звук был сразу нормальный. Мессенджер он и есть мессенджер. Счёт 2:1.
Та же ерунда, услышал достаточно раздражающее эхо. При том, через 5 минут общался с тем же собеседником по скайпу, используя те же каналы связи — и все было ок.
Не совсем понятно в какой момент снят дамп.
Вы должны понимать, что сигнализация и голос это разные понятия.
Сигнализация идет по порту RIP?
Голос идет по порту RIP?
Все вместе идет по порту RIP?
Может с помощью RIP идет выбор ближайшего шлюза?
Мессадж разработчикам:
Было бы интересно помочь ребятам, можно ли поднять до вашего шлюза SIP trunk и присвоить каждому корп. абоненту 5 знаков? Может это можно даже как-то монетизировать.
Было бы здорово встретиться, может получилось бы заключить коммерческий договор на оказание услуг.
Компания в 5к абонентов по всему миру.
Вот про скайп было больно :)
Ivan_83 ваш посыл относительно телеграма ясен. Но не понял только что вы бы использовали в качестве мессенжера? Судя по позитивным упоминаниям, то Net Meeting, но он вроде скопытился в последних версиях Windows.
Мне например, не нравится токс тем что все реализации под IOS через несколько минут после переключения в другое приложение обрывают соединение, а а клиент у другого пользователя не может доставить сообщение, потому что клиент не в сети. Получается, чтобы вести переписку нужно заранее договариваться о времени и все пользователи должны сидеть в программе (проверял несколько месяцев назад, после этого пришел к выводу, что токс пока невозможно использовать, для переписки с большинством своих контактов). Хотя он вроде на голову выше многих вышеупомянутых месенджеров.
Мне например, не нравится токс тем что все реализации под IOS через несколько минут после переключения в другое приложение обрывают соединение, а а клиент у другого пользователя не может доставить сообщение, потому что клиент не в сети. Получается, чтобы вести переписку нужно заранее договариваться о времени и все пользователи должны сидеть в программе (проверял несколько месяцев назад, после этого пришел к выводу, что токс пока невозможно использовать, для переписки с большинством своих контактов). Хотя он вроде на голову выше многих вышеупомянутых месенджеров.
Конкретно в этом случае я к тому, что говорить, что скайп круче телеграма — это очень странно.
Если у меня на работе перейдут со скайпа на телеграм — я буду только рад. Телеграм удобнее раз в 100, чем тот же скайп, он не глючит по крайне мере.
Я не говорю, что Телеграм лучший месенджер на века (хотя на мой взгляд, он довольно неплох), но это первый месенджер после скайпа, который смог стать нашумевшим.
Или вы бы лучше работали в скайпе?
Как-то так сложилось, что для меня это так.
Скажем, я не видел групп для IT-сообществ в Viber или FB Messenger.
http://expandedramblings.com/index.php/telegram-stats/ — 100kk на февраль 2016, сейчас наверняка больше.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Занятная приоритизация голосового трафика в Telegram