netj

В борьбе между научным подходом и желанием простоты и интуитивности потока сознания (я про код на PHP) побеждает желание простоты (т.к. даёт возможность не изменять свои знания), которое в реале нифига не достигается (потому что для того, чтобы система что-то могла, в ней должна быть для этого реализована возможность, хоть явно, хоть неявно), но создаёт устойчивую иллюзию: штука в том, что к обучению и процессу изучения нового относятся эмоционально и со страхами наказания за ошибки, заложенные в детстве, вместо того, чтобы вырубить то, что на результат в реальном мире влияет крайне плохо (эмоции и страхи). А т.к. в людях заложен страх нового с одной стороны, ещё куча страхов с другой и постоянная борьба возникает между эмоциями и разумом (срабатывает внутренняя защита системы управления на эмоциях от вмешательства разума, своего рода иммунитет на уровне BIOS от вмешательства более высокоуровневой ОС), не удивительно, что прижились POP (почта), x86, PHP, Basic, Pascal, и, в особенности, язык всех детей - указания пальцем на желамое (мышкой на кнопку на фоне красивой картинки), вместо озвучивания символьным языком взрослых, и т.д.

Ivan_83, сами когда-нить сетевые протоколы разрабатывали и реализовывали, или даже весь стек протоколов? Сигнатуры - это вообще нонсенс. В условиях, когда в пакеты вкладываются описания и данные, т.е. это блочные, а не потоковые протоколы, никаких сигнатур нафиг не нужно, потому что тот же размер данных указывается значением до начала блока - взять хотя бы тот же ip и udp, а состояние автоматов, взаимодействующих по протоколу отслеживается внутри них самих и меняется по мере прохождения управляющих сообщений типа SYN, ACK, которые в данных выглядят обычным значением, может ещё и засунутым в 2-4 бита. Тот же TCP отслеживается потому, что стандартизирован и фильтр может у себя отслеживать состояние взаимодействия, дублируя действия взаимодействующих автоматов и реагируя на управляющие сообщения. Просто в TCP немного иным образом реализована концепция подтверждения, чем в uTP, ну есть ещё немного других моментов. А в целом - задачи решаются те же, что и в TCP.

А как же вы работаете?Как в ИТ, и, особенно, в администрировании и управлении программно-аппаратными средствами можно вообще что-либо делать гарантированно (ибо решения эти инженерные, а не исследование неизвестного) и проверяемо и при этом ничем не руководствуясь? Как вообще можно получать результат гарантированно от инженерных решений, которые работают как автоматы (как настроишь, как скомандуешь - так и работают), если не разбираться? Откуда возьмутся знания, если не разбираться и не читать? Может вы ещё теорему Пифагора на компьютере проверять будете опытным путём? Все моменты, имеющие значение для решения проблемы изложил в коменете выше, особенно - назначение полей и их значение для протокола и процесса обмена данными. Остальное - в документации, естественно на английском (как вообще можно что-либо в ИТ делать без английского?) Проверяли? Может дело в том, что изложено нелогично (часто, очень часто сталкиваюсь), неполно, непонятно для тех, кто не в теме, без раскрытия терминов и т.д., без объяснения реальной проблемы и целей, которая достигается в том числе при помощи пользователей?Может проблема в том, что вы переносите своё поведение и свой стиль решения проблем на остальных (подразумевается, что сами не очень читаете и не очень стремитеьс разбираться)? Например, если взгляните на форумы трекеров, там много тем, посвящённых различным аспектам настройки клиентов. И люди и пишут, и читают, и обсуждают, потому что им это нужно, особенно, когда возникают проблемы и вообще, когда хотят понять, как с этим трекером взаимодействовать. Кроме того, сами модеры форумов, обычно, в правилах пользования и заглавных топиках сообщают важную инфу. Только не нужно воспринимать всё так, что все прям сразу должны куда-то подорваться и начать делать. Нет. Так не бывает - это культура и знания, медленно распространяющиеся, но неизбежно распространяющиеся. То, что вчера казалось нововведением, уже завтра может оказаться нормальным положением дел. Кроме того, тех же разработчиков можно попросить устнавиливать означенные настройки по-умолчанию при установке приложения. Аналогично, на форумах поддержки операторов можно давать сообщения, да ещё дофига способов донести до пользователей определённую информацию, что имеет смысл, только если сам разбираешься и делаешь со своей стороны то, что нужно, а не тупо требуешь и ожидаешь исполнения от пользователей.

Господа zkvomsk, BETEPAH, Lynx10, gab, _INF_, AlKov, вы разобрались в назначении полей протокола uTP и их применении для обнаружения пакетов с данными uTP, что показывается для всех только при помощи tcpdump, а затем каждый сам переведёт в соответствующую запись для собственного фильтра, что описано в моём коменте ранее? 1. Всё ещё продолжают писать положение полей относительно ip. Если размер заголовка будет не 20, а 24 байта, выражение будет адресоваться не к тем данным. Поэтому адресация должна быть только относительно udp для uTP. 2. В коменте наглядно показано, почему шаблоны "7F FF FF FF 00 03" и "00 38 00 00" бессмысленны и что означают. 3. В коменте чётко показано, что фильтровать и фильтровать ли, и к чему будет приводить фильтрация - есть случай, когда она может привести к обратному эффекту. 4. Комент писался не от балды и эмпирическим путём и наблюдениями за хексом пакетов, а в результате анализа приведённой документации по uTP, а затем - проверке многочисленными экспериментами, в которых было точно известно, где пакеты от uTP протокола.

Пример несоблюдения видел, например 0x61 в байте полей version/type. Но как это влияет на отлавливание установления соединений, если преимущественно для этого большинство должно говорить на одном языке?Можете привести другие несоответствия? Если отличаются по части установления соединения, то каким образом они это могут делать так, чтобы принимать uTP соединения от версий, начиная с 1.8? Взял версию 1.8.4 и документацию к ней. В ней тот же пункт опций, что и в документации к 2.0.1, но ничего нет про управление разрмером пакета: В настройках поставил 31.Взял выражение для tcpdump - и поймал кучу пакетов. Для версии 1.8.4 работает. Если есть где 1.8, могу попробовать протестить с ней. Кстати, версий до 1.8 сейчас не так уж и много, а проблема pps обозначилась намного позже, чем вышла версия 1.8.4. Т.е. как-бы при чём тут версии, которые реализуют uTP по-другому, если они были и раньше, сейчас их меньше основной массы, и раньше проблемы pps не было?

Согласно uTorrent transport protocol, и протокольной части по полю type, version, размерам udp-части и размерам uTP-пакета, который должен быть в случае ST_SYN, при помощи tcpdump можно набрать пакеты установления соединения по uTP, которые можно придержать с отправкой, но не убивать, что лучше, чем вслепую убивать неизвестно что, а если это окажется ещё и пакет данных, то пойдут мелкие пакеты о неподтверждённых пакетах. tcpdump -nnptx -s 72 udp[8] = 0x41 and udp[24:2] = 1 and udp[26:2] = 0 and \( \(udp[9] = 0 and udp[4:2] = 8+20\) or \(udp[9] != 0 and udp[4:2] = 8+20+2+udp[29]\)\) udp[8] - поля version = 1 и type = 4 (абзац по ST_SYN и абзац по version), внимание на "0x" udp[24:2] - seq_nr = 1 (абзацы по ST_SYN и примеру инициализации соединения) udp[26:2] - ack_nr = 0 (абзац по ack_nr, а из "last received" следует 0) udp[9] - extension (0 - в отсутствии расширения связным списком, и другие значения - иначе) udp[4:2] - размер udp-части всего пакета udp[29] - поле len (абзац по extension) - размер расширения при его наличии когда udp[9] = 0, udp[4:2] - размер udp-части всего пакета, должен совпадать с 8+20, 8 - заголовок udp, 20 - пакет uTP когда udp[9] != 0 (пока видел 0, 1 и 2), udp[4:2] -размер udp-части всего пакета, должен совпадать с 8+20+2+udp[29], 2 - размер полей расширения extension и len Приводимый тут пример с 0x7fffffff выпадает на поле timestamp_difference_microseconds. Судя по значению, это некоторая константа типа максимального знакового целового значения, которая, может означать неопределённость разницы. Она может выпадать в случае ST_STATE при подтверждении получения пакетов. По сравнению с другими пакетами выпадает крайне редко. Следовательно убивание этих пакетов будет приводить попытке повторной передачи потерянной части, а при полной невозможности этого, вероятно, отказываться от передачи. Наблюдаемое число 0x38 (с учётом контекста) в примерах выше - в действительности начальный размер окна (поле wnd_size), который равен 0x380000, а последовательность байт этого поля в сетевом порядке 0038 0000. Судя по тому, что с моего хоста шли только такие начальные размеры и параметр uTorrent net.utp_initial_packet_size я выставил в 8, т.е. максимальный, а по мере передачи, это поле меняется в сторону уменьшения, использовать его также бесполезно для распознавания пакетов. Кроме того максимальный начальный размер окна и выключение управления размером пакета (net.utp_dynamic_packet_size) приводит к обмену пакетами максимального размера, а не по 150 байт. Все мелкие пакеты (20-40 байт) - это управляющие пакеты: инициация соединения, подтверждение получения, закрытие соединения, разрыв соединения. По ST_DATA проверка на udp[8] = 1 и совпадение размеров пакетов может оказаться ненадёжной (отсутствуют дополнительные условия seq_nr и ack_nr), пробовать, конечно, можно, если добавить проверку на попадание размера пакета в конкретные диапазоны, основанные на 150, 300, 450 и т.д. (точные размеры нужно узнавать и проверять). Проверял всё описанное по траффику через задание порта работы uTorrent 2.0.1 и анализу 4000 пакетов. Узнать всё по данному вопросу не могу в принципе - сырцы закрыты. Если реализовать отслеживание состояния соединения, т.е. адекватно протоколу изменять seq_nr, ack_nr, а также учитывать connection_id, который будет узнаваться из пакетов установления соединения ST_SYN, то можно будет точнее распознавать пакеты остальных типов. Итого, очень хотелось бы, чтобы с одной стороны пользователи отключили динамическое управление размером пакетов, задав net.utp_initial_packet_size=8, а админы в ответ на это и в обмен на приведённую инфу по распознаванию пакетов не резали наобум, и вообще, не резали, но тормозили эти пакеты до приемлемой для обеих сторон скорости, что должно приводить к паузам между последовательностями передач пакетов ST_DATA.

Так и есть. А разве я говорил что-то о безлимитных? Изначально вопрос был: Т.е. я бы и рад за конкретный объём траффика платить, да адекватно потреблению это не получается.Анлим сделали не от хорошей жизни, а от описанных проблем с оплатой фиксированного траффика и с целью увода внимания потребителя от реальной цены трафика через иллюзию непосредственной оплаты и физической реализации через мультиплексированный канал (о которой задумываются лишь доли процентов потребителей), где вторая, скрытая, сторона медали - оплата косвенная через цену товара, включающего цену рекламы и затрат на её доставку потребителю: только на анлиме потребитель не очень будет задумываться о незапрошенном траффике, а значит - ему можно будет куда легче загнать рекламу и другие монетизирующие средства использовать. Да и иметь дело с юрлицами, монетизирующими траффик, которых намного меньше потребителей, куда проще и оперировать ценами там можно совсем другими.

Ок.Но остальных проблем оплаты траффика фиксированного объёма это не отменяет :)

Именно поэтому я выяснил, к сожалению, не сразу, реальные возможности купленного мною роутера ZyXEL-P334WT и впоследствии оставил его работать только в качестве свича. Сообщение на торрентах в том числе и для того, чтобы показать наличие проблем в дешёвых железках незадумывающимся пользователям, и что далеко не всегда и не все проблема из-за операторов.Вместо ZyXEL-P334WT собрал роутер на PC-ой плате и 2-ух сетевухах, воткнул на него RHL без графики и только с нужными компонентами, настроил схемы работы устройств и фильтры на iptables и модулях в результате долгой прокурки манов и других русскоанглийских ресурсов и типовых задач и поднял на нём интересующие меня сервисы (тоже собирал их из сырцов), или прокинул через роутер сервисы через NATP, бегающие на других машинах моей сети. И всё стало прекрасно: никаких подвисаний, никаких тормозов запросов, только когда днс-сервера провайдера почему-то ложаться, но в целом - семья об интернете в доме не задумывается, а просто пользуется им в любой точке жилища. Осталось только видеопоток научиться прокидывать, а то ZyXEL-P334WT больше одного потока с выключенным фаером не тянул, и то еле-еле. А что касается сетевых протоколов, так я сам сетевые специализированные протоколы разрабатывал и клиент/серверные решения на них, а также - движки для организации работы нескольких протоколов разных уровней разных назначений (в том числе и с восстановлением от ошибок при помощи помехоустойчивого кодирования).

там упоминалось про массовое включение электроприборов и поэтому, я Вас очень прошу, встаньте, подойдите к счетчику и посмотрите на него ... посмотрели? увидели как он крутится? замечательно! после этого надо будет объяснять что если бы до сих пор повсеместно была оплата по трафику без всяких анлимов этой темы и других аналогичных ей не появлялось бы или не надо? Счётчик не крутится, а циферки показывает. Но не суть. Кстати, ваш вопрос мог оказаться и неуместным, если бы я поставил собственный электрогенератор, благо есть дешёвые, на электролизе и водороде :) Даже если проводить аналогию с электросетью. 1. Напряжение в сети стандартное - 220-230 вольт. Аналог скорости. 2. Мой счётчик может выдержать нагрузку до 40 ампер. Аналог ширины полосы, т.к. компонента, определяющая мощность. 3. Потребление приборов стандартное и постоянное, а потому имеется выбор в использовании электроприборов, следовательно и возможность влиять на потребление электроэнергии. Электроприборы - аналог сайтов. Современные сайты гонят тучу незапрашиваемого траффика, кучу рекламы. Это как если бы сосед подключился через мой счётчик. Кроме того, рекламодатели не за просто так рекламу показывают, а за плату рекламным сетям, тому же гуглу и яндексу. Как рекламодатели могут отбить деньги? Только через продажу товара, за который заплатит потребитель. Значит, если я куплю рекламируемый в интернете товар, я заплачу за затраты на его рекламу и траффик на эту рекламу (При этом не важно, смотрел эту рекламу или нет). В одном случае (если получил рекламу) я заплачу за одни и те же полученные пакеты дважды, в другом случае (если вырежу рекламу), я заплачу за траффик, который доставил рекламу соседу. 4. Электроэнергия оплачивается согласно потреблённым киловатчасам. При этом никто не ставит ограничения сверху на это потребление и не прости олпатить конкретные объёмы заранее, и не играет в "превышение объёма". Абонент ограничен лишь возможностью электросети работать на определённой мощности. Итого: Ни скорость, ни ширину полосы существующая сеть связи не может гарантировать, в отличие от электросети. А оплата траффика в конкретном объёме приводит к либо к двойной оплате, либо к оплате чужого траффика. При этом почему-то деньги вперёд и за конкретный фиксированный объём траффика, в отличие от потребления электроэнергии по необходимости без планирования затрат. Поэтому пока говорить об однократной оплате траффика конкретного объёма гарантированного качества (скорость/мощность+только запрошенный) невозможно.

Разве я не ясно дал понять, что заданные вопросы не имеют цели собирать лулзы или устраивать срач, что в этих вопросах нет цели найти виноватых,а есть цель понять существующие возможности сети и положение дел, кто и что их определяет, из которых однозначно следуют возможности абонентов, и неважно при этом, за что они заплатили и что им обещали?

Благодарю за напоминание, читал тему, прежде чем ...Вопросы эти подаются как юридические, но в реальности их урегиулирование определяется совсем не юридическими и не "справедливыми" методами. Так что не будем играть в "юриспруденцию" и "права". Смотрим по сути моего сообщения про вопрос о том, какой траффик считается паразитным и будет ли трафик в приведённом примере считаться паразитным. Согласно условиям примера ничего не говорились о целях перегрузки оборудования оператора, а говорилось о полном использовании полосы, которую продали абоненту, по сути же ему продали определённые параметры шейпера и других ограничителей, определяющие возможности абонента использования канала, которые должны совпадать согласно тарифу и договору на оказание услуг. Т.е. никаких нарушений не подразумевалось и действий в отношении оператора и сети тоже. Понятно, что атакующие действия абонентов - угроза - не обсуждаем и не обсуждалось. Вопрос. Если полное использование купленной абонентом полосы приводит к проблемам связи, сразу начинают искать виноватых и виноватым оказывается абонент (хомячок). Почему и как полное использование купленной полосы, купленных возможностей использования канала могло стать угрозой, если таковой не является по определению, а является товаром? Да, понятно, что в реальности выбор простой: или порубить прожорливых, или будут проблемы связи. Но как так получилось, что появились прожорливые только с точки зрения сети, а согласно их намерениям, тарфиам и купленными ими параметрами органичителей оборудования, возможностям использования канала, они таковыми не являются?

Дело не в том, сколько готов заплатить я или каждый потребитель. Дело в том, что всё перечисленное вами - инфраструктура, пропускная способность которой определяется конечными по времени и деньгам затратами на создание, которые в любом случае будут получены, т.к. время пользования много больше, и в том, что в итоге потребитель платит, и напрямую, и опосредованно через оплату товаров. Только вот для любого бизнеса в России любая инфраструктура хоть внутри компании, хоть вне неё всегда считалась объектом затрат и способом экономии со всеми вытекающими. Что же касается оплаты, может кто-нибудь объяснит, почему один и тот же пакет оплачивается потребителем дважды, а то большее число раз? Один раз непосредственно как оплата провайдеру по тарифу, а воторой раз - опосредованно, как оплата за товары, в цену которой включилась реклама в интернете и оплата траффика для этой рекламы. Думаю, ответ на этот вопрос очевиден: тот, кто может подчинить других, и сказать, что теперь все ему должны платить за любой траффик, начинает получать сверхприбыли. Хотя, очевидно, что нормальная оплата может быть только по запрошенному траффику, а не по отданному, а значит между собой любый 2 опа всегда могли бы урегулировать отношения по разнице между объёмом траффика, запрошенным каждым из них, только это убьёт сверхприбыли и сделает очень медленный возврат возврат инвестиций (в этом и есть желаемая многими справедливость) :)

Здесь полоса, та, что физически имеется у оператора (тогда сходится), или, та, которая есть сумма проданных полос каждому абоненту сети оператора (тогда не сходится или я чего-то не понимаю)? Мм, скажем, клиент сделал распределённую систему и раздал код друзьям/товарищам. Они собрали код в модули и запустили, каждый на своём хосте с внешним ипом. Система работает так, что её трафик занимает всю полосу 24/7/365, отведённую каждому её хосту оператором. Трафик от этой распределённой системы будет паразитным?

Не должен, в смысле не должно лечь оборудование и должен суметь пропустить траффик (i/o) от полностью занятых полос каждым абонентом его сети?