[dmitry1970]

Отделение на SCE сигнатуры 118095888 (bittorent event-driven UDP) в отдельный сервис и блок этого сервиса к падению PPS не привело.

 

У меня привело. Странно.

[Гость bear]

если всё на москву валить ничего не спасет

[halver]

Отделение на SCE сигнатуры 118095888 (bittorent event-driven UDP) в отдельный сервис и блок этого сервиса к падению PPS не привело.

 

У меня привело. Странно.

Если с соответствующим падением трафика пропорционально PPS - значит не то режете.

[Alex780]

118095888 (bittorent event-driven UDP) было еще в pp19 - оно не работало.. трафик шел как other udp, pp20 все никак не соберусь опробовать

[Гость nuclight]

Ivan_83 не только тролль, но еще и кучу заведомо ложной информации выдает.

 

Разработчикам надоело ждать TCP-ACK от каждого пакета

 

Это совершенно не так. TCP умеет присылать ACK не на каждый пакет, и это давно используется. А uTP жестко регламентирует посылку ACK именно на КАЖДЫЙ, и как можно быстрее (они так замеры задержки производят), т.е.в обратную сторону будет гарантированный поток мелких пакетов без данных с тем же PPS, что и в прямую сторону.

 

а тсп отдаёт поток последовательно, и возникают задержки, когда например нет 2-3 пакета а уже 50-60 свалилось, но стёк не отдаёт - ждёт пока приедут потерянные. В тоже время торренту фиолетова последовательность, ибо и так запрашивает кусками и собирает из кусков.

 

Опять неверно. Разработчики ВМЕСТО этой очевидной для конкретного протокола торрентов оптимизации - реализовали такой же SOCK_STREAM поверх него, какой дает TCP, и пустили тот же протокол, что у торрентов ходит и поверх TCP. И оно точно так же будет ждать реордеринга пакетов.

 

Странно что SSH вообще появился, когда есть telnet и ssl/tsl.

 

Да вот нифига. Это как раз SCTP здесь в роли SSH, а изобретатели uTP сделали что-то типа telnet over L2TP IPSEC.

 

В SCTP из привлекательного только мультихомность

 

Ну щазз. Разработчику протокола массового приложения как раз на мультихомность глубоко положить (откуда она у массового юзера?), а вот куча других вкусных фич - решают. Это, во-первых, сразу фрейминг на дейтаграммы (поток TCP нужно на них ручками бить), во-вторых, параллельная доставка нескольких потоков сразу (нет проблемы FTP по 21 и 20 порту, может бегать по одному), в-третьих, поддержка Unordered delivery дейтаграмм. То есть, как раз для торрента, собирающего из кусков, подошло бы прекрасно: посылаются параллельно несколько блоков, получателю в приходят в произвольном порядке, если из какого-то блока один пакет потерялся - остальные, в отличие от TCP, от этого не тормозят.

Одна только "маленькая" проблема - Windows не поддерживает SCTP.

 

С другой uTP всё равно лучше TCP, выше я писал что можно слать большие аски - даже аски не нужны, просто запрос на нужные куски.

 

Так МОГЛО бы быть. Но разработчики проявили идиотизм вообще кругом. Эта возможность не использована.

 

Вообще, на их месте следовало пропихнуть TCP LEDBAT в реализации стеков, а не изобретать свой велосипед. Ну да, конечно, это проще, искать 5 рублей подфонарем, где светлее, ага...

---

@nuclearcat:

 

к сожалению их идеи преследуют цели, ... В итоге обе стороны тратят усилия на совершенно бесполезную для обоих сторон войну. Но если у провайдеров (особенно местечковых, без жирных каналов) это вопрос выживания, то у авторов ПО больше вопрос принципа.

 

Им в таком разе следует ответить другой идеей из принципа - нефиг изобретать ломающие другим работу велосипеды, если ничего не понимаешь в протоколах Интернета. Можно давить uTP уже чисто из этого принципа :)

 

---

@vitalyb:

 

Если в uTorrent'ном swarm'е появляется другой клиент с "неограниченной" возможностью к аплоаду - он всех забивает и никто вообще не может сидировать кроме него. "Другой" клиент есстессно работает по TCP.

Т.е. протокол по дизайну "хорошо" качает (ну, в смысле задержек, "дружелюбности" к интерактивному трафику), но плохо раздает если где-то пересекается с TCP трафиком у пиров. А т.к., к счастью, не все единовременно перешли на uTP, TCP трафику в битторенте быть и uTP всегда по сравнению с ним будет "ущербным". Разумеется, если все раздают по TCP, то качать по uTP будет почти некому.

 

Вообще-то с точностью наоборот. На utorrent.com появились сообщения, что на ряде трекеров ввели баны uTorrent 2.0 после того, как выяснилось, что в swarm'е он преимущественно выбирает пиров с uTP - и другие клиенты с TCP могут ждать часами.

---

По остальному - насчет фильтрации DHT и uTP на FreeBSD внутри PPTP GRE можно прочитать тут: http://nuclight.livejournal.com/125372.html

[piupiu]

Почитали вас.

Для оценки количества решили тегировать и дропать в ipfw

Работает на 7.2 RELEASE amd64

 

Получилось следующее:

#!/bin/sh

kldload ng_bpf
kldload ng_tag
kldload ng_ipfw

/usr/sbin/ngctl -f- <<-SEQ
        mkpeer ipfw: bpf 61 ipfw_hook61
        name ipfw:61 bpf_utp_filter
        mkpeer bpf_utp_filter: tag matched tag_utp
        name bpf_utp_filter:matched tag_utp_tagger
SEQ

ngctl msg bpf_utp_filter: setprogram { thisHook=\"ipfw_hook61\" ifNotMatch=\"ipfw_hook61\" ifMatch=\"matched\" bpf_prog_len=12 bpf_prog=[ { code=48 jt=0 jf=0 k=0 } { code=84 jt=0 jf=0 k=240 } { code=21 jt=0 jf=8 k=64 } { code=48 jt=0 jf=0 k=9 } { code=21 jt=0 jf=6 k=17 } { code=40 jt=0 jf=0 k=6 } { code=69 jt=4 jf=0 k=8191 } { code=177 jt=0 jf=0 k=0 } { code=64 jt=0 jf=0 k=20 } { code=21 jt=0 jf=1 k=2147483647 } { code=6 jt=0 jf=0 k=65535 } { code=6 jt=0 jf=0 k=0 } ] }
ngctl msg bpf_utp_filter: setprogram { thisHook=\"matched\" ifMatch=\"ipfw_hook61\" bpf_prog_len=1 bpf_prog=[ { code=6 jt=0 jf=0 k=96 } ] }
ngctl msg tag_utp_tagger: sethookin { thisHook=\"tag_utp\" ifNotMatch=\"tag_utp\" }
ngctl msg tag_utp_tagger: sethookout { thisHook=\"tag_utp\" tag_cookie=1148380143 tag_id=61 }


ipfw add netgraph 61 udp from any to any iplen 0-61
ipfw add deny udp from any to any tagged 0-61


# to test outgoing - tcpdump -pni Out_Interface "ip[40:4]=0x7FFFFFFF" and "ip[44:1]=0xab" and ether src Ext_If_Mac

[TikiMe]

то что сейчас вы делаете, ведь в корне не правильно...

про ддос и ограничение доступа - что 1 юзверь мог положить оборудование среднестатистического прова, это ведь ой как постараться надо, другое дело в совокупности, но это уже не волнует единичного абонента; я конечна понимаю что проблема появилась резка и сразу эффективно отреагировать не получается, но долго стопорить на этом решении, это чревато...

З.Ы. прочитав от начала до конца тему, изначально было какое-то возмущение по поводу того, что провы в тихаря, что-то делают, ограничивают своих абонентов, при этом некоторые абоненты заметив некую не функциональность программ и тп, ведь могут себе мозг сломать решая эту проблему, а пров будет отнекиваться что нечем не препятствует :\

хотел было жалобу на своего прова накатать, но дочитав тему до конца понял что это пока больше вынужденная мера, посмотрим через некоторое время, если не изменится ничего, то пусть уже роспотребнадзор с ним разбирается.

Изменено 3 марта, 2010 пользователем TikiMe

[Ivan_83]

Это совершенно не так. TCP умеет присылать ACK не на каждый пакет, и это давно используется. А uTP жестко регламентирует посылку ACK именно на КАЖДЫЙ, и как можно быстрее (они так замеры задержки производят), т.е.в обратную сторону будет гарантированный поток мелких пакетов без данных с тем же PPS, что и в прямую сторону.

В TCP приложению не доступно управление отсылкой асков, насколько помню включается в реестре сразу для всей системы.

uTP может сейчас и отсылает аск на каждый пакет, но это уже само приложение решает.

Я не утверждал что uTP сейчас работает так, ИМХО они придут к этому.

 

 

изобретатели uTP сделали что-то типа telnet over L2TP IPSEC

Проба пера :)

Помню я тоже как то пролетел с исходными условиями: написал качалку многопоточную с виндовых шар, с докачкой (типа регета). Расчёт был на то что данные будут передаватся медленне, чем их будет писать на диск принимающая сторона (тогда больше сотки не было нигде у смертных, а я рассчитывал чуть ли не под модемы), и нужно было максимально быстро выдирать файл. В итоге у меня задавалось колличество потоков чтения для одного файла, например 4. Выделялся буфер, ставился асинхронный запрос на чтение, по его завершении полученный буффер сданными ставился в асинхронную запись, и выделялся новый буффер под чтение и опять ставился в запрос на асинхронное чтение (по завершении записи на диск буфер освобождался). И так в несколько потоков шло чтение/запись (thread в винде был 1, имеются ввиду логические потоки данных).

А потом (лет через 5) я на гигабите попробовал - программа ушла в свап, ибо винт так быстро записывать не мог, как такой же читать.

Так же и авторы - потестили на своей сетке и небольшой выборке и было всё шикарно, а потом нашлись слабые места на большой выборке.

 

Ещё поэкспериментируют немного, и за пол года-год доведут до ума.

Сложность в том чтобы не перегружать канал принимающей стороне, остальное ерунда.

Изменено 3 марта, 2010 пользователем Ivan_83

[marikoda]

то что сейчас вы делаете, ведь в корне не правильно...

про ддос и ограничение доступа - что 1 юзверь мог положить оборудование среднестатистического прова, это ведь ой как постараться надо, другое дело в совокупности, но это уже не волнует единичного абонента; я конечна понимаю что проблема появилась резка и сразу эффективно отреагировать не получается, но долго стопорить на этом решении, это чревато...

З.Ы. прочитав от начала до конца тему, изначально было какое-то возмущение по поводу того, что провы в тихаря, что-то делают, ограничивают своих абонентов, при этом некоторые абоненты заметив некую не функциональность программ и тп, ведь могут себе мозг сломать решая эту проблему, а пров будет отнекиваться что нечем не препятствует :\

хотел было жалобу на своего прова накатать, но дочитав тему до конца понял что это пока больше вынужденная мера, посмотрим через некоторое время, если не изменится ничего, то пусть уже роспотребнадзор с ним разбирается.

Раньше по ветке была цитата из "Правил оказания", в данной ситуации провайдер юридически прав. Для верности можно составить внутреннюю бумагу, вроде "комиссия в составе директор, главный инженер, админ проанализировала проблемы с оборудованием и включила фильтрацию согласно пункта правил такого то", это на случай, если кто-то спросить, почему фильтруется.

[TikiMe]

то что сейчас вы делаете, ведь в корне не правильно...

про ддос и ограничение доступа - что 1 юзверь мог положить оборудование среднестатистического прова, это ведь ой как постараться надо, другое дело в совокупности, но это уже не волнует единичного абонента; я конечна понимаю что проблема появилась резка и сразу эффективно отреагировать не получается, но долго стопорить на этом решении, это чревато...

З.Ы. прочитав от начала до конца тему, изначально было какое-то возмущение по поводу того, что провы в тихаря, что-то делают, ограничивают своих абонентов, при этом некоторые абоненты заметив некую не функциональность программ и тп, ведь могут себе мозг сломать решая эту проблему, а пров будет отнекиваться что нечем не препятствует :\

хотел было жалобу на своего прова накатать, но дочитав тему до конца понял что это пока больше вынужденная мера, посмотрим через некоторое время, если не изменится ничего, то пусть уже роспотребнадзор с ним разбирается.

Раньше по ветке была цитата из "Правил оказания", в данной ситуации провайдер юридически прав. Для верности можно составить внутреннюю бумагу, вроде "комиссия в составе директор, главный инженер, админ проанализировала проблемы с оборудованием и включила фильтрацию согласно пункта правил такого то", это на случай, если кто-то спросить, почему фильтруется.

лучше составьте заранее, оно вам может пригодиться :) иба единичному абоненту вы предъявить нечего не сможете, а он вам сможет.

и не надо скрывать такие движухи, надо поворачивать это в выгоду, типа для стабильности сети блаблабла был произведены такие-то действия, юзвери тока рады будут резка улучшившемуся качеству инета, тем более это почти на глаз видно.

З.Ы. "хомячки" в большинстве своем, зверьки добродушные, все поймут ;)

[SinCitizen]

З.Ы. "хомячки" в большинстве своем, зверьки добродушные, все поймут ;)

Но есть, к сожалению, меньшинство, которых иначе как скунсами не назовешь, им только дай какой-нибудь повод, пусть даже положительный...

[marikoda]

лучше составьте заранее, оно вам может пригодиться :) иба единичному абоненту вы предъявить нечего не сможете, а он вам сможет.

и не надо скрывать такие движухи, надо поворачивать это в выгоду, типа для стабильности сети блаблабла был произведены такие-то действия, юзвери тока рады будут резка улучшившемуся качеству инета, тем более это почти на глаз видно.

З.Ы. "хомячки" в большинстве своем, зверьки добродушные, все поймут ;)

Здравая мысль.

[TikiMe]

З.Ы. "хомячки" в большинстве своем, зверьки добродушные, все поймут ;)

Но есть, к сожалению, меньшинство, которых иначе как скунсами не назовешь, им только дай какой-нибудь повод, пусть даже положительный...

эти тоже нужны, чтоб дисбаланса не было и жизнь сказкой не казалась :D

как вы к ним, так и они к вам, все взаимосвязано... мир и взаимопонимание рулят :)

З.Ы. причем единицам уступки то можно делать, на картину в целом это не повлияет, зато абонент не будет чувствовать себя ущемленным.

Изменено 3 марта, 2010 пользователем TikiMe

[vitalyb]

Вообще-то с точностью наоборот. На utorrent.com появились сообщения, что на ряде трекеров ввели баны uTorrent 2.0 после того, как выяснилось, что в swarm'е он преимущественно выбирает пиров с uTP - и другие клиенты с TCP могут ждать часами.

По ссылке автор поста жаловался, что его с биткометом забанили потому что он никому не давал сидировать. Возможно это 2.0.1-беты, которых уже "исправили" в этом плане?..

 

[vIv]

"Ваш софт действует неадекватно, звонить каждому абоненту мы не можем, поэтому немножечко поправили настройки и теперь его попытки вести себя неадекватно исправляются с нашей стороны. Кстати, на это требуется какое-то время (около 2-3 минут), но если Вы готовы потратить своё время, то мы вам подскажем, как настройки исправить, чтобы этой паузы не было" После чего правим параметр uTorrent и снимаем в нём галку, - по телефону. "Теперь перезапустите свой софт, скорость должна вставать на возможный максимум немедленно".

 

Юзера надо любить даже тогда, когда он какает там, где вы этого не ждёте. Юзер, - он по определению не специалист, ему помогать надо. Даже если иногда и без его явной о том просьбы.

[terekhov]

"Ваш софт действует неадекватно, звонить каждому абоненту мы не можем, поэтому немножечко поправили настройки и теперь его попытки вести себя неадекватно исправляются с нашей стороны. Кстати, на это требуется какое-то время (около 2-3 минут), но если Вы готовы потратить своё время, то мы вам подскажем, как настройки исправить, чтобы этой паузы не было" После чего правим параметр uTorrent и снимаем в нём галку, - по телефону. "Теперь перезапустите свой софт, скорость должна вставать на возможный максимум немедленно".

 

Юзера надо любить даже тогда, когда он какает там, где вы этого не ждёте. Юзер, - он по определению не специалист, ему помогать надо. Даже если иногда и без его явной о том просьбы.

Браво! :) А теперь еще 15к раз, из низ 30% вообще не одупляют что от них хотят, 10% "не абонент" (читай нужно перезвонить), и еще процентов 10-15 будут уверять, что у них ничерта нет :)

 

Разместив тему о uTorrent v.2 на местном форуме, отписалось туда ТРОЕ, хотя просмотров около 300. И это из 15к :)

Резать и еще раз резать. Клиент всегда прав, но инфантилен, медлителен и монописуален.

[TikiMe]

"Ваш софт действует неадекватно, звонить каждому абоненту мы не можем, поэтому немножечко поправили настройки и теперь его попытки вести себя неадекватно исправляются с нашей стороны. Кстати, на это требуется какое-то время (около 2-3 минут), но если Вы готовы потратить своё время, то мы вам подскажем, как настройки исправить, чтобы этой паузы не было" После чего правим параметр uTorrent и снимаем в нём галку, - по телефону. "Теперь перезапустите свой софт, скорость должна вставать на возможный максимум немедленно".

 

Юзера надо любить даже тогда, когда он какает там, где вы этого не ждёте. Юзер, - он по определению не специалист, ему помогать надо. Даже если иногда и без его явной о том просьбы.

Браво! :) А теперь еще 15к раз, из низ 30% вообще не одупляют что от них хотят, 10% "не абонент" (читай нужно перезвонить), и еще процентов 10-15 будут уверять, что у них ничерта нет :)

 

Разместив тему о uTorrent v.2 на местном форуме, отписалось туда ТРОЕ, хотя просмотров около 300. И это из 15к :)

Резать и еще раз резать. Клиент всегда прав, но инфантилен, медлителен и монописуален.

мы вроде как в правовом государстве живем... и на вас найдется прошаренный абонент который отобьет желание резать ;)

всякая инициатива и самовольность наказуема, тем более если она НЕ подкреплена весомыми бумажками.

З.Ы. со стороны этот форум реально кажется источником всемирного зла, а все потому что вы не ставите своих абонентов в расчет и не информируете их о своих действиях, не уж то это так трудно делать... или думаете пронесет, не заметят и им пофиг что их в расчет не ставят?

это даже не к конкретно к этому случаю относится, я о ситуации в целом - дело принципа.

Изменено 4 марта, 2010 пользователем TikiMe

[UglyAdmin]

З.Ы. со стороны этот форум реально кажется источником всемирного зла, а все потому что вы не ставите своих абонентов в расчет и не информируете их о своих действиях, не уж то это так трудно делать... или думаете пронесет, не заметят и им пофиг что их в расчет не ставят?

Представьте, что у Вас есть автобус или несколько, и Вы перевозите пассажиров из пункта А в пункт Б.

Количество пассажиров растет небыстро, всё посчитано и в общем рентабельно.

А теперь представьте, что пассажиры берут с собой всё больше и больше багажа, причём не в сумках/чемоданах, за которые требуется заплатить, а навешивают на себя. И даже специальное ателье шьёт специальные модели одежды со встроенными карманами, крючочками и прочими прибамбасами, чтобы подвесить пакеты/сумки под пальто и не платить за багаж.

В итоге - пассажиры в двери пролазят с трудом, что увеличивает время остановок; на сиденье не помещаются, что уменьшает количество перевозимых пассажиров, а платить хотят столько же или даже меньше, поскольку из-за первого пункта поездка стала занимать больше времени...

 

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

 

Абоненты - наша кормовая база, мы следим чтобы эта база не уменьшалась. Но кто сказал, что мы должны их любить?

[BiWiS]

Угли, я тут както писал схожий пример с таксистом, но его к сожалению потерли ;-))

Людям не хочеться знать затраты провайдера. Им надо чтобы в глухой тайге и-нет стоил столько же, сколько и в Москве/Питере, и плевать им на расходы по доставке этого и-нета в тайгу)))

Так же плевать и на то, что действие программы одного пользователя как бы не причиняют вреда оператору... Но действия в группе лиц уже причиняют. Об этом они не думают :)

[TikiMe]

З.Ы. со стороны этот форум реально кажется источником всемирного зла, а все потому что вы не ставите своих абонентов в расчет и не информируете их о своих действиях, не уж то это так трудно делать... или думаете пронесет, не заметят и им пофиг что их в расчет не ставят?

Представьте, что у Вас есть автобус или несколько, и Вы перевозите пассажиров из пункта А в пункт Б.

Количество пассажиров растет небыстро, всё посчитано и в общем рентабельно.

А теперь представьте, что пассажиры берут с собой всё больше и больше багажа, причём не в сумках/чемоданах, за которые требуется заплатить, а навешивают на себя. И даже специальное ателье шьёт специальные модели одежды со встроенными карманами, крючочками и прочими прибамбасами, чтобы подвесить пакеты/сумки под пальто и не платить за багаж.

В итоге - пассажиры в двери пролазят с трудом, что увеличивает время остановок; на сиденье не помещаются, что уменьшает количество перевозимых пассажиров, а платить хотят столько же или даже меньше, поскольку из-за первого пункта поездка стала занимать больше времени...

 

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

 

Абоненты - наша кормовая база, мы следим чтобы эта база не уменьшалась. Но кто сказал, что мы должны их любить?

любить? тут ни о любви речь, а о законах и правилах... вы по правилам делайте и претензий никаких не будет, ога?

 

[mikevlz]

бгггг... По закону 99% торрентоводов пойдут лес валить...

[TikiMe]

бгггг... По закону 99% торрентоводов пойдут лес валить...

а это другая история, не относящиеся к этой проблеме ;)

[SmokerMan]

Угли, я тут както писал схожий пример с таксистом, но его к сожалению потерли ;-))

Людям не хочеться знать затраты провайдера. Им надо чтобы в глухой тайге и-нет стоил столько же, сколько и в Москве/Питере, и плевать им на расходы по доставке этого и-нета в тайгу)))

Так же плевать и на то, что действие программы одного пользователя как бы не причиняют вреда оператору... Но действия в группе лиц уже причиняют. Об этом они не думают :)

Это естественно, а я хочу молоко по 10руб. в ближайшем магазине. и хлеб по той же цене. Конечный пользователь всегда будет хотеть все, качественно и бесплатно, это очевидно.

[weldpua2008]

любить? тут ни о любви речь, а о законах и правилах... вы по правилам делайте и претензий никаких не будет, ога?

где написано что провайдер обязан не резать?Может еще провайдер не имеет права при поступление abuse отключать абонента на профилактику?

А может еще милый провайдер порежет автообновление microsoft, adobe, etc - что бы крякнутые проги не могли обновиться и сказать пользователю - bad license?

А может как считают пользователи Провайдер должен:

 

а).защищать их вирусов - бесплатно и инспектировать всё трафло, что бы зашищать пользователя от всех посягательств

б).не ограничивать весь "нужный" пользователям траффик - например спам, доступ к анонимным прокси - которые позволяют платить за трафло меньше...

в).ни в коем случае не разглашать информацию о пользователе и всячески мешать расследованиям органам

г).если у пользователя кончается место на диске - подгонять 10-15ТБ квоту в надёжном хранилище, причём прокидывать к нему 2-а и более видов доступа...

Или вообще что бы всё содержимое пиратского контента содержалось лишь на винтах провайдера - если что, Я не качал

 

 

Обьясните Мне пожалуйста - у Меня есть cisco catalyst... в нем есть acl. Вопрос - почему Я не могу им (acl) пользоваться, хотя это и приведёт к отсеиванию "зайцев" в сети? У Меня есть OS, или же железка на которой есть acl, firewall - почему Я не могу им(правилом на ограничения какого либо трафика) пользоваться?

 

У Вас есть машина, если Вы кого-то подвозите - Вы едете как хотите или как Вам говорят? Вы нарушаете правила ели Вам говорят что легче подъехать отсюда, ну против движения по односторонней дороге...

 

бгггг... По закону 99% торрентоводов пойдут лес валить...

+1

Безлимитный интернет – это право доступа в интернет без каких-либо ограничений, ни по объему скачанной информации, ни по времени, проведенному в сети. Пользователь вносит фиксированную абонентскую плату, может работать в интернете хоть сутки напролет и качать, если есть такое желание, информацию терабайтами.

это основное определение, а дальше каждый ровайдер подразумевает по своему...

Например "безлимит" часто заканчивается на 100Гбайте, или же Вы вдруг обнаруживаете что безлимит 100Мбит/с только внутри локальной сети, а во внешний мир - 512Кбит и т.д.

 

Нет эталона Мбит/а и так же нет определение безлимитного интернета и нет правил по которым провайдер должен был бы "не резать скорость или порты или трафф или менять QOS, вносить дропы и т.д."...

 

[terekhov]

Кто-то уже приводил выдержку, по которой пров может рубить абонента, если тот мешает нормальному функционированию сети, кто-то приводил правильную последовательность: гендир+тех.дир+админ = акт = блокировка абонента/трафика.

 

О чем можно говорить дальше?