onet и мистический трафик

[Гість 6636]

ненормальное соотношение, когда с тебя что-то качали

 

[Kuzia]

Это крайне "умное" обоснование ЖУТКОГО СООТНОШЕНИЯ входящего-исходящего трафика.

Никакого "жуткого соотношения" в упор не вижу. Какое по-вашему должно быть соотношение, если с клиента кто-то тянул файл, или если клиент отправил 1К писем? По-моему, Вы просто пытаетесь выдумать очередной повод для дебатов. Похоже сама мысль, что провайдер интранет / интернет (локалка) может оказаться "невиноват", для Вас просто невыносима. Вы же, кажется, ярый приверженец УкрТелекома?

 

[ANTIPUT]

Он яркий приверженец движения "маразм крепчал"

 

[Major]

а пункта доставки трафика - ***.
и спорить тут бесполезно.
И тут каждый решает сам кто напортачил. Прову выгодно сказать что это клиент. Но нет доказательств. Клиент говорит "что за ***? это не я" и предоставляет логи.
Кому верить? За возвращенные деньги респект, но где гарантии что их вернуть в следующий раз?

 

[drew]

Он яркий приверженец движения "маразм крепчал"

или *****

 

[alex444]

Я вот в упор не понимаю, если NAS отчитался о клиенте
====
Thu Mar 20 00:00:06 2008
Acct-Session-Id = "47E02D986BFE"
User-Name = "********"
Acct-Status-Type = Stop
Service-Type = Framed-User
Framed-Protocol = PPP
Acct-Authentic = RADIUS
Acct-Session-Time = 86334
Acct-Output-Octets = 332266325
Acct-Input-Octets = 130798325
Acct-Output-Packets = 465718
Acct-Input-Packets = 422131
=====
что клиент запихал в него 130798325 байт - почему это я (а не клиент) должен знать - зачем клиент запихивал в него эти байты ?
Другое дело, что даже такого клиенту не предоставили, судя по всему, в ответ на его претензию.

 

[Kuzia]

...И тут каждый решает сам кто напортачил. Прову выгодно сказать что это клиент. Но нет доказательств. Клиент говорит "что за ***? это не я" и предоставляет логи.

Доказательства есть, логи RADIUSA. Клиентом никаких логов предоставлено не было. Скриншеты неизвестно чего, сделанные неизвестно когда и где - логами считать нельзя.

Другое дело, что даже такого клиенту не предоставили, судя по всему, в ответ на его претензию.

"Понятную версию такого", клиент наблюдает в своей статистике. Если клиент попросит, дадим ему именно логи RADIUSA.
ps: А вобще NetFlow у нас исправно собирается и в 99% случаев мы можем указать клиенту куда именно ушел его трафик.

 

[De_Wounder]

Вы забыли добавить, что это всего лишь ваше скромное мнение, 99.99% наших абонентов его не разделяют.

Спор наш бесполезен. Ибо к сожалению клиент для вас таки *** а не партнер.

И про авши 99.99 вы лукавите, ой как лукавите. Или привести вам тему из блек листа про вашу сеть?

 

[Kuzia]

Спор наш бесполезен. Ибо к сожалению клиент для вас таки *** а не партнер.
И про авши 99.99 вы лукавите, ой как лукавите. Или привести вам тему из блек листа про вашу сеть?

До создания этой темы, вы много видели сообщений о том, что "Наша Сеть" "крадет" деньги клиентов? Так что это ТОЛЬКО ВАШЕ СКРОМНОЕ МНЕНИЕ, фактами нисколько не подтвержденное.
А насчет того, что спор наш абсолютно бесполезен - целиком и полностью согласен. Человек создавший тему, уже давно никаких претензий к нам не имеет, тему продолжают раздувать люди, нашими клиентами не являющиеся... Интересно, с какой целью? Тут не нужно быть семи пядей во лбу, чтобы догадаться...

 

[BFG-9000]

И чем соотношение смущает?
Нормальное соотношение когда с тебя что-то качали.

Никакого "жуткого соотношения" в упор не вижу. Какое по-вашему должно быть соотношение, если с клиента кто-то тянул файл, или если клиент отправил 1К писем?

Садитесь вдвоем и учите матчасть. Когда для вас перестанет быть великой тайной хотя бы квитирование в TCP-протоколе (а оно есть, и на каждый пакет в идеале равный МТУ будет ответ минимум 36 байт) - тогда вы возможно перестанете писать бред. Кстати заодно узнаете что такое МТУ и чему оно равно в инете и в локалке, разделите размер МТУ на 36 и удивитесь...

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

 

[BFG-9000]

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

Знать "зачем" - действительно не только не должен, а еще и не имеешь права. Но ведь клиент не просто так сел, прописал тебя дефолтовым гейтом и погнал, верно? Предварительно ты взял с клиента денежку и обязался что-то с запиханными тебе байтиками сделать, верно? Вот и отчитайся клиенту о проделанной работе, а именно: 8946738 байта отправлены туда-то, 78998 - сюда, 7638 - нафиг отброшены как некорректные и т.д... Логично?
Клиент ведь тебе присылает байтики с ЧЕТКИМ указанием, что с ними сделать дальше, вот и веди простейшую бухгалтерию - принято от клиента 87687 байтов для пересылки туда-то и пометочка "выполнено"...
А в противном случае разговор с клиентом вкратце звучит так: "Ты нам должен столько-то бабла, мы тебе вот насчитали, у нас есть специальный счетчик". Не очень интересный монолог...

 

[Alert]

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

 

[Kuzia]

Садитесь вдвоем и учите матчасть. Когда для вас перестанет быть великой тайной хотя бы квитирование в TCP-протоколе (а оно есть, и на каждый пакет в идеале равный МТУ будет ответ минимум 36 байт) - тогда вы возможно перестанете писать бред.

Садитесь, вам двойка с минусом. Сначала утрудите себя почитать, что для Windows систем означают следующие ключи реестра (см. ниже), а уже потом мы будем разговаривать "о вопиющей безграмотности, незнании и непонимании простейших законов сетевого взаимодействия".
TcpAckFrequency
TCPNoDelay
TcpWindowSize
GlobalMaxTcpWindowSize
etc..

Вот и отчитайся клиенту о проделанной работе, а именно: 8946738 байта отправлены туда-то, 78998 - сюда, 7638 - нафиг отброшены как некорректные и т.д... Логично?

Это кажется логичным только Вам. Провайдер предоставляет ДОСТУП. Этот доступ ограничивается либо пропускной способностью, либо объемом переданной информации. За тем, куда клиент отправил данные, воспользовавшись ДОСТУПОМ, провайдер следить не обязан.

 

[De_Wounder]

До создания этой темы, вы много видели сообщений о том, что "Наша Сеть" "крадет" деньги клиентов? Так что это ТОЛЬКО ВАШЕ СКРОМНОЕ МНЕНИЕ, фактами нисколько не подтвержденное.
А насчет того, что спор наш абсолютно бесполезен - целиком и полностью согласен. Человек создавший тему, уже давно никаких претензий к нам не имеет, тему продолжают раздувать люди, нашими клиентами не являющиеся... Интересно, с какой целью? Тут не нужно быть семи пядей во лбу, чтобы догадаться...

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

Более того, повторюсь, я не сисадмин, но кое какое представление о предмете разговора имею. Так вот, каждый фрейм содержит адрес отправителя и адрес источника. Припрохождении вашего шлюза нет никакой сложности отследить куда ушел и откуда пришел фрейм. Тем более не понимаю что такого, чтобы эту инфу пихать в SQL и хранить там пару месяцев. А потм собсно любой студент Хире 3 курса напишет скрипт который сделает выборку по ай-пи и нарисует подробнейшую таблицу куда ушел каждый фрейм.

И не надо кричать про терабайты логов. 10000 пользователей. Скока может занимать 1 лог на одного юзера 50 кб??? пусть 500 кб. Получается примерно 5 Гб. Дофига???? Типа машина долго это делать будет?

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

Так шо технически реализоваь это вполне возможно

 

[De_Wounder]

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

Но абонент захотел подробно псмотреть. Платит 2 грн и вуаля. Оказывается что вы эту статистику таки ведете. Либо же вы берете ее с потолка.

Теперь сосбсно вопрос, почему бы не сделать эту услугу бесплатной? Не думаю что это много доходов вам приносит но все же...

 

[ANTIPUT]

Она платная у всезх провайдеров по одной и той же причине - её заё...ет делать для каждого *****а который считает что его обокрал провайдер.

 

[Renegade]

Более того, повторюсь, я не сисадмин, но кое какое представление о предмете разговора имею. Так вот, каждый фрейм содержит адрес отправителя и адрес источника. Припрохождении вашего шлюза нет никакой сложности отследить куда ушел и откуда пришел фрейм. Тем более не понимаю что такого, чтобы эту инфу пихать в SQL и хранить там пару месяцев. А потм собсно любой студент Хире 3 курса напишет скрипт который сделает выборку по ай-пи и нарисует подробнейшую таблицу куда ушел каждый фрейм.

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

 

[De_Wounder]

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

А разве в сети Онета у юзверей динамические внутренние ай-пи?

Не хотел лезть в эти дебри.

Когда устанавливается ВПН соеденение с ВПН сервером, трафик в инет идет через это соеденение. ВПН сервер выдает динамический внешний ай-пи на время соеденения. Неужели фрейм отправленный через Впн соеденение не содержит свой локальный ай-пи?

 

[De_Wounder]

Она платная у всезх провайдеров по одной и той же причине - её заё...ет делать для каждого *****а который считает что его обокрал провайдер.

А зачем делать эти отчеты руками или кто зае..цца, скрипт??? Повесил скрипт, отладил его, и каждый за 10 сек может получить детальную статистику......

 

[Renegade]

А разве в сети Онета у юзверей динамические внутренние ай-пи?

Внутренний IP нет. Но речь идёт о внешнем трафике.