Вопросы пинга, варпа, лага и привязка к теории

Re: Re: Re: Re: Придирки не по существу

badboy
Вполне допускаю, что могу и ошибаться. Я знаю о наличии SEQ в TCP-header. Но мне ничего не известно о наличии подобного поля в IP-header или ICMP-header. Дай, пожалуйста, ссылку.

Пожалуйста: RFC-792, p. 14. Echo or Echo Reply Message. Смотри поле "Sequence Number".

Хорошо, поставим вопрос по-другому - готов ли ты утверждать, что большинство или хотя бы значительная часть юзеров фрихоста летают так как ты? И говоря в 100-м канале - warper - другому пилоту имеют перед глазами то же, что и ты в подтверждение своих слов?

Блин. А это какое отношение имеет к теме дискуссии? Забыл? Напомню: "Топик 1". А именно про "пингование фрихоста ".

Хорошее слово - наверняка. Главное, что оно допускает, что "могут и не возникнуть потери пингов". Потому что сработает поставленный на киске cbwfq, или просто wfq, например.

Пусть не возникнут потери. Но перегрузка канала обязательно скажется на RTT. Хочешь поспорить?

А если еще он в паре с грамотно настроенным trafic-shaping... давай предполагай, что будет у тебя на линуксе и что в wb. Я, при случае, готов даже показать, как подобное можно реализовать на cisco (с высокой степенью вероятности получения эффекта: ping reply идет с потерями, а wb играет без проблем. И наоборот).

Да, извращаться можно по-разному, но у меня есть резонное возражение, что ни один sane human не станет настраивать маршрутизаторы так, что они будут предоставлять разные классы обслуживания для icmp echo (reply) и tcp пакетов в "общем" потоке. Под "общим" потоком в данном случае имеется такой, параметры которого не были оговорены заранее.

Ты уверен, что такого механизма нет в реальной конфигурации промежуточных роутреров от тебя до FH?

Пока да, так как наблюдаю 100% корелляцию проблем со связью в wb с показаниями утилиты ping.

Или от большинства пилотов до FH?

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

Отследить проблему нарушения последовательности пакетов можно с достоверностью только снифером, в нашем случае, imho.

Причины возникновения нарушения последовательности прохождения пакетов в сети равновероятно окажут влияние как на tcp пакеты, так и на icmp. Если не рассматривать случаев злонамеренных извращенных настроек.

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

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

Мне следует воспринимать слова, что ты IT-специалист как шутку? А вообще, если серъезно, то я не нашел смайлика выражающего сарказм. Я думал, что будет понятно и так.

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

Другими словами, ты мне, случайно проходящему мимо, предлагаешь растолковать IT-специалисту (наверняка имеющему множество сертификатов от cisco) в чем заключается смысл изложенной им лажи? Изволь, вопрос был "почему вместо TCP в играх используется UDP". В оригинале у operka звучал как: Кстати, а почему многие игры используют UDP, а не TCP/IP?. Твой ответ повторно полностью цитировать не буду, перечитай сам, и пойми как он на него отвечает. Это "конкретно".

- при этом у UDP пакетов шансы быть доставленными вовремя и без потерь (в зависимости от ситуации в WAN) могут быть выше чем у TCP быть доставленными вовремя.

Это к вопросу о лаже из твоего ответа. Помогут тут тебе только сильно извращенные настройки маршрутизаторов. Или резкий откат от пакетов к большим сегментам в случае с TCP при одновременном выбросе из рассмотрения вопросов фрагментации сходного по размерам полного UDP пакета. Очевидно, что рассматривать любой из этих вариантов бессмысленно. Это "детально".

Детально и конкретно?

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

Если угодно услышать конкретную придирку - то что ты назвал "медленные линии" имеет другое название, которое я бы перевел на русский другим словом. В английском варианте это будет звучать imho как low-capacity. Могу покопаться и отыскать точное название.

Но это так... придирка.

Сходил, почитал. Теперь ты почитай, что в моем оригинале было написано "на относительно медленных линиях". Потом подумай, и реши, кто придирается, и по существу-ли.

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

Уже.

Как ты думаешь, UDP был исключительно выбран в виде транспорта тут для того, чтобы, как ты пишешь, "избавиться от повторной передачи неактуальных данных"?

В случае с современными играми через WAN, да. Кстати, оригинальный вопрос был про игры, а не про VoIP в LAN'е.

Или моя фраза "Каждый разработчик конкретной программы думает - что в его варианте лучше и что более корректно вприсывается в его код (идеологически для целей программы)" все же менее категорична и позволяет перейти к конкретике в каждом конкретном случае с конкретной программой?
Она бессмыслена в своей универсальности, если рассматривать ее как ответ на поставленный вопрос. Доволен?

Last edited by badboy on 27th April 2002 at 18:08

Какие-то проблемы?

/usd

 

Re: Re: Re: Re: Придирки не по существу (дополнение)

badboy
Да, кстати, как бы то ни было... Поясни, ты утверждаешь, что механизм seq. для ICMP аналогичен тому, который реализован для TCP?

Где я такое утверждаю? Цитату пожалуйста.

Last edited by badboy on 27th April 2002 at 19:31
Трудно с тобой. Думаешь приятно искать отличия в разных версиях?

/usd

 

Re: Re: Re: Re: Re: Придирки не по существу

Да, RTFM дело полезное... Хотя, опять таки... ладно, не будем углубляться...

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

Думаю, что не ошибусь, если скажу, что ты один из немногих, у кого перед глазами одновременно и пинг и wb. И совсем уж в принципе - речь я собирался вести о том, что если показалось, что кто-то варпит (и вот тут можно добавить, если вы не юзаете систему применяемую usd) - то надо еще десять раз подумать, прежде чем сказать waprer. И всего-то.

Не хочу. Потому что придется спорить уже на конкретном примере, конкретной сети с конкретными девайсами и конкретными настройками роутеров. То есть заниматься тем же, чем я и так занимаюсь конкретно сейчас - анализом продуктивности двух нетворков (одного типичного LAN/IP и другого WAN/DLSW+), и ей-богу мне заморочек и тут хватает, чтобы еще на виртуальный нетворк время тратить. Давай договоримся, что необязательно этот вопрос тут продолжать
для пользы юзеров фрихоста. Все что могу сказать по твоему утверждению - перегрузка канала может сказаться, а может и нет в зависимости от кучи параметров.

Вот как раз очень даже может быть такая конфигурация. Видел сам, спросил зачем, получил исчерпывающий ответ. Потом видел еще несколько раз. Например, чтобы не засирали юзера груженого канала своим ICMP. И очень часто имплементируют это таким образом, что ICMP шейпится и еще к тому же и custom queue-ится. Да еще и приорити расставляется в зависимости от source хоста, который пинговать собрался. И в итоге получится то что я приводил в пример - вполне может оказаться, что играется в полном порядке, а параллельно пущенный пинг дает !!!!.!!!.!!..!

Да ведь просто может быть, что еще ниразу не доходило дело до лимита TS. Ну да бог с ним, это из области туманных предположений.

Или от большинства пилотов до FH?

Ну ты, наверное, не в киске работаешь, потому и не слышал. В бэкбонах, конечно, найти подобную конфигурацию вряд ли удастся, в вот на border роутерах, там где админы заботятся об использовании канала или имеют прямое указание начальства обеспечить максимальный reliability и availability для конкретных протоколов - легко. Могу живые примеры привести только из своей небольшой практики.

Ну вот я как раз имею другой взгляд на этот момент. Ибо хорошо знаю, получение доступа к роутеру злонамеренным настраивателем - вещь крайне редкая. Случаются ошибки конфигурации - да. Тоже редко кстати. А вот динамический роутинг в инете меняется го-о-о-о-ораздо чаще. Может в 5 хопах от фрихоста это не очень видно, но вот от меня, например - частенько.

Там был смайлик с улыбкой во все зубы. А перед ним стояла иконка с растопыренными пальцами. У меня, во всяком случае
так борда отображает.
Короче, если серьезно, то я никогда бы не стал в кругу своих коллег говорить и своей особой одаренности или продвинутости в IT. Черевато, ибо Да и свои пределы я довольно четко представляю.

Во-первых мне сложно было предположить, что ты "случайно проходил" Во-вторых любой диалог на топик я рассматриваю как попытку улучшить что-либо в первых постах, с целью популяризаторского просвещения. Потому я и предложил тебе написать. Только поэтому. Мне ничего разъяснять не надо У меня стойка с несколькими десятками cisco press, минимум два ccie с колоссальным опытом работы за соседними столами и неограниченный доступ на киску, где документации - жуй не хочу, было бы желание ее читать. Ну и свой небольшой опыт впридачу. Это я не в качестве "пальцев", а к тому, что когда мне чего-то непонятно, я всегда найду кого спросить, причем, сам понимаешь, общаться на такие темы за чашкой кофе в личной беседе проще гораздо, чем через инет

Да детально. Теперь смотри дисклаймер Как UF сказал - вы когда границу пересекали - красный флаг видели? Я готов признать, впрочем, что размыто написал. Точнее - не дописал. К кастомеру пришлось ехать и времени не хватило. Показалось, что достаточно. В качестве альтернативы предлагаю тебе ответить на этот вопрос, чтобы у operka и других сложилась ясная картина.

А что от этого меняется? Механизмы то те же самые. Кстати, wb с его реализацией трудно отнести к современным сетевым играм. Как и quake II, кстати. Ну, что имеем, в то и играем.

Универсальные ответы всегда бессмыссленны, если к ним подходит человек соображающий в проблеме больше, чем non-advanced user. Тем не менее, универсальные ответы никто еще не отменял. Вот именно за это я популяризацию терперь не могу - в ее итоге юзеру в принципе вопрос понятен, но тут выплывает из-за поворота коллега и вежливо берет под локоток:
"М-да, коллега... п-гаслушал я тут вашу замечательную лекцию... И вот что хотелось бы отметить..."

Придирки? Проблемы? Сейчас напишу...

ip route 0.придирки.0 0.0.0.0 Null0
ip route 0.проблемы.0 0.0.0.0 Null0

interface (который в интернет)
ip access-group badboy in
ip access-group badboy out

ip access-list extended badboy
deny придирки any any
deny проблемы any any

Ы?

 

Re: Re: Re: Re: Re: Придирки не по существу (дополнение)

Да ну нафиг, какая цитата... Я уточнял просто. Потому как не понял, это ты имеешь ввиду или нет.

Сорри.. привычка читать за собой сказывается.

 

sepukked

 

Re: Re: Re: Re: Re: Re: Придирки не по существу

badboy
Хотя, опять таки... ладно, не будем углубляться...

А почему-бы и нет?

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

Тебе не повезло Я буквоед. Думаю, цитировать "Топик 1" повторно смысла нет.

Не хочу. Потому что придется спорить уже на конкретном примере, конкретной сети с конкретными девайсами и конкретными настройками роутеров. То есть заниматься тем же, чем я и так занимаюсь конкретно сейчас - анализом продуктивности двух нетворков (одного типичного LAN/IP и другого WAN/DLSW+), и ей-богу мне заморочек и тут хватает, чтобы еще на виртуальный нетворк время тратить. Давай договоримся, что необязательно этот вопрос тут продолжать
для пользы юзеров фрихоста. Все что могу сказать по твоему утверждению - перегрузка канала может сказаться, а может и нет в зависимости от кучи параметров.

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

Вот как раз очень даже может быть такая конфигурация. Видел сам, спросил зачем, получил исчерпывающий ответ. Потом видел еще несколько раз. Например, чтобы не засирали юзера груженого канала своим ICMP. И очень часто имплементируют это таким образом, что ICMP шейпится и еще к тому же и custom queue-ится. Да еще и приорити расставляется в зависимости от source хоста, который пинговать собрался. И в итоге получится то что я приводил в пример - вполне может оказаться, что играется в полном порядке, а параллельно пущенный пинг дает !!!!.!!!.!!..!

Еще раз про извращенные настройки. <sarcasm>Расскажи нам, как провайдеры настраивают маршрутизаторы для "прижатия" других типов трафика в пользу icmp eho{reply} (это когда пинги хорошо проходят, а данные нет). А так же для чего они это делают, и какими их словами после этого потребители их услуг называют.</sarcasm>

Если серьезно, то обслуживание всех ip пакетов в "общем" потоке должно осуществляться с учетом поля TOS, безотносительно к их содержимому, будь это icmp, tcp или еще что. Под "общим" потоком здесь понимается такой, параметры которого не были заранее оговорены.

Так что давай договоримся, что провайдеры, без предварительного согласования с потребителями, иногда могут "зажимать" _некоторые типы_ icmp сообщений, таких как echo{reply} в пользу "полезного" трафика. Наоборот - крайне редко, и только при наличии ярко выраженных злых намерений. Если не согласен, приводи аргументы.

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

Ну ты, наверное, не в киске работаешь, потому и не слышал. В бэкбонах, конечно, найти подобную конфигурацию вряд ли удастся, в вот на border роутерах, там где админы заботятся об использовании канала или имеют прямое указание начальства обеспечить максимальный reliability и availability для конкретных протоколов - легко. Могу живые примеры привести только из своей небольшой практики.

Давай живой пример, когда ip пакеты, содержащие icmp echo{reply}, имеют больший приоритет, чем ip пакеты, содержащие tcp. Разумеется, адреса источника и назначения, а также значение поля TOS одинаковы для всех ip пакетов. С внятными объяснениями для чего подобный изврат реализован.

А вот динамический роутинг в инете меняется го-о-о-о-ораздо чаще. Может в 5 хопах от фрихоста это не очень видно, но вот от меня, например - частенько.

Тяжело вам там наверное, все нагрузка перераспределяется небось? Или линки часто вылетают?

Я готов признать, впрочем, что размыто написал. Точнее - не дописал.

Дак а получилось-то что у тебя? Или я не прав?

В качестве альтернативы предлагаю тебе ответить на этот вопрос, чтобы у operka и других сложилась ясная картина.

Я не напрашивался. Но могу, правда без разжевываний:
Выбор основывается на том, что при передаче некоторого потока через сеть, в случае с UDP, время доставки блока данных, составляющего этот поток, зависит только от состояния сети в течении времени доставки и не зависит от состояния сети в прошлом (как в случае с TCP). Эта независимость времени доставки является прямым следствием отсутствия повторных передач неактуальных (в случае с играми) данных.

А что от этого меняется? Механизмы то те же самые.

Упс. А вот тут по-подробнее пожалуйста. Про "те же самые" механизмы применительно к вопросу о решении использовать UDP вместо TCP.

Ы?

Нет, перефразирую: зачем править свои сообщения после отправки, создавая дополнительные неудобства?

/usd

 

Re: Re: Re: Re: Re: Re: Re: Придирки не по существу

Потому что я не вижу смысла вести углубленную дискуссию, выросшую из темы популяризации. Тебе кажется, что я неправ, утверждая, что пинг нельзя считать достоверным способом проверки состояния канала? Опровергни и напиши свое утверждение.

Лично для меня (исходя из теории и моей личной практики) уже одно то, что пинг работает на layer 2, а tcp на layer 3, является доказательством. Во-вторых, если ты склонен рассматривать канал от себя до провайдера, как единственный пример, то я этого делать не склонен. Если тебе нечем заняться в свободное от работы время и есть охота позаниматься интеллектуальным анонизмом ? я тебе скину четыре возможные трейса от меня до фрихоста, дам приблизительное описание каналов и протоколов маршрутизации, сброшу настройки своего роутера (котором не я слава богу рулю) и настройки роутера своего провайдера (им тоже не я рулю, но знаю их по долгу службы), попрошу настройки бордер роутера своего провайдера (того, которым он втыкается в дойч телеком) ? и если после этого ты напророчишь мне хотя бы с 51% вероятностью, что я должен видеть в канале от себя до фрихоста в 19:04 (взято с потолка) каждый день в течение недели, я с удовольствием проведу эксперимент, чтобы блестяще подтвердить или блестяще опровергнуть твое утверждение. (настройки дам после того, как ты подпишешь мне non-disclosure agreement c полной твоей ответственностью в части разглашения).

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

Мне всегда не везет, когда приходится заниматься популяризаторством. Это карма и я к этому привык уже. Но я тоже буквоед, и кроме того я еще и зануда, потому не устану тебя отправлять в свой дисклаймер столько раз, сколько будет надо.

У меня есть деловое предложение. Вместо того, чтобы перекидывать мне мячик с названием Топик 1, мы берем этот топик, меняем в нем одно слово и ты доказываешь его. Идет?

Вот тебе «теорема»:
«Речь пойдет о том, почему можно считать пингование фрихоста (при помощи ICMP PING) с компьютера юзера (вирпила) однозначным доказательством стабильности соединения между компом данного вирпила и фрихостом»

Удачи.

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

Если опять-таки, хочется рассмотреть вопрос актаульный, может быть ? расскажи юзерам подробно и популярно, почему приведенный мной пример пинга пакетами TCP из WB так отличается от приведенного мной пинга пакетами ICMP. Что-то мне подсказывает, что в процессе объяснения ты однозначно ответишь и на topic 1. Если хочешь, я тебе дам материал? Пинги сделанные в разное время суток. В дополнение к ним дам трейсы, сделанные в то же время.

Чиста без сарказма, в натуре (тут "пальцы" и "смайлик", на случай если тебе не видно).
То, что тебе кажется извращенными настройками является обыденной реальностью, основанной на экономике. Ни в одном контракте ты не найдешь пункта, что «обслуживание всех ip пакетов в "общем" потоке должно осуществляться...». Попробуй при заключении контракта на предоставление доступа в интернет внести этот пункт и посмотришь как прореагирует юридический отдел провайдера. В лучшем случае ты добьешься того, что этот пункт будет внесен с дополнением «в AS провайдера». Конечно, если речь идет о так называемом «выделенном» канале, с гарантированной пропускной способностью или VPN тоннеле, то ситуация будет другая, но и цены другие тоже.

CBWFQ является очень популярным и advanced методом решения возможных проблем traffic management, люди работающие у провайдеров это знают. В качестве примера я могу тебе привести минимум трех провайдеров в Чехии, которые используют это решение у себя. И могу привести четвертого провайдера (Арчер, иди сюда, и подтверди) ? в котором CBWFQ имплементирован не был только потому, что мы с Арчером легли поперек порога и сказали ? только через наши трупы. Ибо в тот момент и именно там он был нафуй не нужен. Ибо топология и анализ трафика ? дело великое. Хотя рано или поздно пришлось бы его ставить.

Вот тут ты серьезно ошибаешься. Совет ? позвонить своему провайдеру и спросить, что, согласно твоему контракту они «могут иногда», а что ? «могут всегда и в принципе плевать на все хотели». Ты удивишься тому, как мало первого и как много второго. Вопрос же «предварительного согласования» вообще никогда не рассматривается (если речь не идет о VPN или «гарантированных каналах» опять-таки). Зато мера «информирования» клиента о произведенных изменениях ? популярная. Типа, «мы тут роутинг завернули», поэтому проверьте как у вас будет работать. Если не будет ? пожалуйста обращайтесь в наш коммерческий отдел за разъяснениями и уточнениями контрактов. Какими словами при этом юзеры будут называть провайдера - провайдеру в принципе безразлично. Можно даже с высокой степенью вероятности говорить о том, почему.

Пример хочешь? Помнишь, борда висела у Арчера на адресе wb.czetel.cz? Так вот у этого самого czetel.cz вот именно описанная мной фигня с global-one.cz и произошла в свое время. Можешь представить, каким дерьмом (с моим занудством) я изошел? И что? Пришлось смыть все дерьмо в толчок и идти платить больше.

Легко. WAN с TCP и DLSW+ over FR, высшие приоритеты по queuing только для DLSW+ и ICMP. Telnet имеет третий приоритет и кроме того зажат TS?ом на 10% от емкости канала. Остальной TCP трафик имеет четвертый приоритет и установлен на величину пакета 512. (Хотел бы я посмотреть как они вообще играть оттуда будут). Сделано так для того, чтобы обеспечить приоритет non-routable трафика IBM через WAN, этот трафик в данной сети является более критичным.

Второй пример ? LAN, 12 серверов, IP+IPX, на серверах старые бьзы данных на FoxPro DOS-версии. NetBEUI по полной программе (админы мелкософтники старой школы упертые). WAN соединение с удаленной базой через Public Internet линк 512К. На бордер роутере установлен высший приоритет для ICMP и SNMP, причина - удаленный менеджмент.

Третий пример. Европейский провайдер voice+dialup с каналом 10Mb. Трафик шейпинг на core router?e не имплементирован, потому что канал не забит пока. Поставлены приоритеты и header compression для voice. В качествего голосовых гейтов применяется Clarent (на WinNT платформе), доступ по менеджменту на гейты через psAnywhere, менеджмент осуществляются через Public Internet из точки, удаленной на 8 хопов через одну транзитную AS. Доступ и менеджмент cisco осуществляется через CiscoWorks, HP Openview из Штатов. ICMP+SNMP на бордер роутере имеют высшие приоритеты - для обеспечения гарантированного доступа к девайсам для менеджмента и сбора статистики. Рассматривается вариант выделения для этих протоколов гарантированной полосы пропускания в моменты пиковой загрузки канала (около 80%).

Живые сети, живые клиенты. Хватит примеров?

А живого примера наоборот тебе не надо?

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

Тяжело. И не только нам, а всем практически забугорникам при коннекте на фрихост. Доказательство, что не я один так думаю? (Тут следует вопль в сторону - Арчер, иди сюда, в конце-концов, гад ! Расскажи народу для чего ты поставил прокси, как оно работает и почему играющий через прокси получит дырку от бублика, а не показатели своего стабильного канала при пинге.) Что там где перераспределяется и что вылетает - кофейная гуща, ибо как я говорил выше, провайдер uplink провайдеру downlink ничего не докладывает. Причем я пример обработки таблиц BGP взял не с потолка. Пальцем могу ткнуть, у кого это происходит и в какое время приблизительно. И еще в одно место могу пальцем ткнуть, где проблемы с OSPF c flapping. А iBGP у них поверх этого самого OSPF живет в их AS.

Получилось то, что я написал. Скажу уже не в первый раз - не нравится - напиши лучше.

Оччччень понятно. Operok, тебе понятно? Кому еще понятно, поднимите руки.

Теперь продолжи и объясни, почему же все-таки часть time-sensitive игровых приложений реализована на TCP, а часть на UDP.

Я говорил о том, что механизм UDP для игровых приложений и VoIP ? один и тот же. В ответ на твое замечание, что оригинальный вопрос был по играм, а не по VoIP.

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


Вообще - деловое предложение. Есть у меня неприкрытое желание сократить количество флуда "около". Есть конкретно что поправить в топиках - давай. Копирайты гарантируются. Муссировать далее "около-темы", по-моему, есть отход от "идеологически выдержанной цели" - объяснения широкой массе юзеров в простых словах, что такое "о-о-о!" и что такое "фу-у-у..." в примении к частному случаю "WB over бардак в Инете".

 

Почему нету? Основы TCP/IP преподают и очень даже много где. Не буду говорить про совок где конкретно, но стопудово, что там давно уже есть, ибо слышал... "типа собака лает, ветер носит ).

Киску, к сожалению, да, учить надо по документации. И на практике, очень желательно. Курс толковый только CCNA, все что выше - есть курсы, но типа "пятидневок". Толк от них определенный есть (если слушатели подготовленные). Но и стоимость у таких курсов - мама не горюй. Английский же - основной технический язык.

А "чашечка кофе"... это надо еще спеца на эту чашечку вытащить, потому что спецу после работы надо к семье и футболу... Некоторые, опять же, на кофе не ловятся, только на пиво или вискарик типа Jamesson (Арчер, например) ... или на водку... как большинство моих коллег е-буржцев

 

Re: Re: Re: Re: Re: Re: Re: Re: Придирки не по существу

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

Зачем? Я уже привел пример в опровержение твоего "топика 1". В ответ я не увидел никаких вразумительных аргументов, кроме всякой фигни про извращенно настроенные маршрутизаторы.

Лично для меня (исходя из теории и моей личной практики) уже одно то, что пинг работает на layer 2, а tcp на layer 3, является доказательством.

IT-специалист? Ну-ну.

Во-вторых, если ты склонен рассматривать канал от себя до провайдера, как единственный пример, то я этого делать не склонен.

Ты нагло лжешь. Давай мои не вырванные из контекста цитаты.

Если тебе нечем заняться в свободное от работы время и есть охота позаниматься интеллектуальным анонизмом ? я тебе скину четыре возможные трейса от меня до фрихоста, дам приблизительное описание каналов и протоколов маршрутизации, сброшу настройки своего роутера (котором не я слава богу рулю) и настройки роутера своего провайдера (им тоже не я рулю, но знаю их по долгу службы), попрошу настройки бордер роутера своего провайдера (того, которым он втыкается в дойч телеком) ? и если после этого ты напророчишь мне хотя бы с 51% вероятностью, что я должен видеть в канале от себя до фрихоста в 19:04 (взято с потолка) каждый день в течение недели, я с удовольствием проведу эксперимент, чтобы блестяще подтвердить или блестяще опровергнуть твое утверждение. (настройки дам после того, как ты подпишешь мне non-disclosure agreement c полной твоей ответственностью в части разглашения).

С чего-бы это вдруг? Не гони пургу, пожалуйста.

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

Весьма похвально.

У меня есть деловое предложение. Вместо того, чтобы перекидывать мне мячик с названием Топик 1, мы берем этот топик, меняем в нем одно слово и ты доказываешь его. Идет?

С чего-бы это вдруг? Я тебе что-то должен?

Во-первых, давай договоримся, что я не юлю. Не имею привычки. Во-вторых, куча параметров действительно существует.

Именно что это и делаешь. Не юли, а называй параметры, составляющие эту "кучу" и не относящиеся к случаям извращенной настройки маршрутизаторов. С объяснениями, каким образом они явятся причиной того, что перегрузка канала не будет существенно влиять на среднее значение и разброс RTT для посылаемых пингов. А пока ты именно юлишь. И думается мне, что это понятно многим, даже не имеющим глубоких познаний в предметной области. Что касается IT-специалистов, если таковы здесь есть, то я думаю что им уже все давно понятно.

Живые сети, живые клиенты. Хватит примеров?

Твой поток сознания как и примеры никуда не годятся. Пока ты не объяснишь какая разница провайдеру что именно находится внутри моих ip пакетов, icmp echo{reply} или tcp. И почему он должен без предварительной договоренности напрягаться и настраивать маршрутизаторы разгребать их содержимое и соответствующим образом обслуживать.
Но если ты будешь настаивать, я попробую пояснить, почему именно каждый твой конкретный пример не подходит среднестатистическому, не отягощенному извращенной настройкой маршрутизаторов, вирпилу. После уточнения тобой некоторых деталей.

А живого примера наоборот тебе не надо?

Уж уволь, ты итак нагнал тут пурги немерянно.

Получилось то, что я написал.

То есть, ты таки согласен, что написал лажу?

Скажу уже не в первый раз - не нравится - напиши лучше.

Уже.

Оччччень понятно. Operok, тебе понятно? Кому еще понятно, поднимите руки.

Здесь чай не детский сад. Те, кому не понятно, всегда могут попытаться уточнить.

Теперь продолжи и объясни, почему же все-таки часть time-sensitive игровых приложений реализована на TCP, а часть на UDP.

А за пивом тебе не сбегать?

Я говорил о том, что механизм UDP для игровых приложений и VoIP ? один и тот же. В ответ на твое замечание, что оригинальный вопрос был по играм, а не по VoIP.

Только каким образом это относится к оригинальному вопросу? Лучше сознайся, что ляпнул не подумав (ты же не сознаешься, что это был банальный "перевод стрелок" ). Избавишь нас от выяснения еще одного обстоятельства

Вообще - деловое предложение. Есть у меня неприкрытое желание сократить количество флуда "около".

Вот и начинай с себя, в твоих постингах очень много пурги (разглагольствований не по существу, левых примеров и прочей откровенной лажи).

Муссировать далее "около-темы", по-моему, есть отход от "идеологически выдержанной цели"

К счастью, в отличие от некоторых, идеологической выдержанностью не страдаю.

/usd

 

Re: Re: Re: Re: Re: Re: Re: Re: Re: Придирки не по существу

to usd only
========
все прочитано... потом посмотрено с удовольствием на написанный в предыдущих топиках acl.

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

Bye

 

sepukked

 

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

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

Большинство людей, которых я знаю, не имеют ввиду стоимость знаний. Ибо от них этих знаний не убудет и потому ну совершенно не жалко. Практика shared knowledge была общепринятой во всех тех фирмах, в которых я работал (хотя может мне просто везло). Другое дело, что не у всех людей есть время. И, кроме того, документация - открытая и бесплатная, это всегда учитывается. И если тебе, например, cisco-знающий тебе говорит ищи на ССО - это не значит, что он тебя "послал", это значит, что он помнит примерно, а попусту переливать водицу времени нет, и лучше если тот, кто спрашивает - сам посмотрит.

 

sepukked

 

Re: 2 usd

Archer
Каким боком это вообще относится к TCP SEQ и к обсуждаемой нами теме? Название поля только одно, функция совершенно разная. Какой смысл был в приводе RFC #? Показать что ты знаешь поле с таким значением в ICMP header?

IMHO, если б ты удосужился внимательно почитать тред, то не задавал бы таких глупых вопросов.
Кратко отвечу: причины, вызывающие перетасовку пакетов в сети в "нормальных" условиях равновероятно окажут свое влияние как на tcp пакеты с wb трафиком, так и на пинги. Таким вот боком относится. Под "нормальными" условиями принимаем те, при которых маршрутизаторы не смотрят в содержимое наших ip пакетов, а обслуживают их сообразно информации, находящейся в заголовке (в заголовке ip пакетов, а не пакетов других протоколов, инкапсулированных в ip. Это что б не возникло случайного желания раскручивать по второму кругу).
А смысл привести ссылку на RFC был в том, что badboy ее попросил.

У меня к тебе настойчивая просьба - воздержись пожалуйста от подобного "мусора" в своих постах - информации он никакой не несет. Скорее наоборот. С тобой ведут нормальную техническую дискуссию - придерживайся пожалуйста правил приличий.

Что неприличного ты узрел в отквоченых тобой моих фразах? Поподробнее пожалуйста. Или тебе просто не нравится, как я отвечаю твоему приятелю, который вместо того чтобы придерживаться обсуждаемых вопросов, гонит пургу пытаясь загрузить?
А что касается мусора, то пусть остальные (желательно, чтобы это к тому же были люди, разбирающиеся в предмете обсуждения) сами решат, в чьих сообщениях содержится больше мусора. "С тобой ведут..." Пожалуйста, менторский тон оставь для других.

/usd

 

Re: Re: Re: 2 usd

Archer
Ты отвечал на абзац badboy'a, но в квотинге его немного сократив. Ни просьбы уточнить вопрос, ни попыток отрицать от тебя тогда не было. Я, конечно, понимаю, что сейчас не смогу ничего доказать, ты скажешь как --am-- - "покажите мне где я конкретно это сказал".

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

Таким образом тема "У пинга не должно быть перетасовок. У него могут быть только потери. " остается подвешенной в воздухе. Я не собираюсь далее с тобой об этом спорить. Функциональность подробно описана в документации.

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

По вежливому не понимаем. Посмотри, пожалуйста, на колонку "Moderators" для раздела "Hardware & Software".

Еще раз повторюсь: какие проблемы с отквоченой тобой частью моего сообщения? Там нету ничего, что бы шло в разрез с действующим законодательством. Как нету бранных выражений и тому подобного. Что написано в колонке "Moderators" я вижу, позволю задать вопрос: ну и что? Какие правила приличия я нарушил? Прежде чем отвечать, рекомендую тебе трезво посмотреть, что в настоящий момент является "в порядке нормы" на этом форуме, и вспомнить про двойные стандарты. Это так, на всякий случай, безотносительно к чему либо.

Мне как модератору, не нравится твой тон и неуважение к оппоненту в технической конференции.

Ты модератор, тебе и карты в руки. Я думаю, что в любом случае, посетители по достоинству оценят твои последующие действия, как действия модератора и человека.

/usd

 

2 usd. По существу

Так, пока Арчер не видит, я сделаю еще одну попытку, последнюю.

To usd. По существу
----------------

1. Скажи, пожалуйста, что будет видеть юзер, когда эти пинги вернутся не в той последовательности, в которой были отправлены?
2. Объясни, пожалуйста, что будет происходить c TCP (в применении к WB), в тот момент, когда пинги возвращаются не в той последовательности, в которой были отправленны.
3. И ответь, пожалуйста, на вопрос: можно ли считать пингование фрихоста (при помощи ICMP PING) с компьютера юзера (вирпила) однозначным доказательством стабильности соединения между компом данного вирпила и фрихостом? Очень желательно с небольшим обоснованием.

Пояснение в связи с моей просьбой:
1. ТЫ МНЕ НЕ ДОЛЖЕН.
2. ЗА ПИВОМ ХОДИТЬ НЕ НАДО
3. ЗДЕСЬ НЕ ДЕТСКИЙ САД

Все что не по существу - ушло приватом.