юмор

Не кот

Скажи "нет" кошатине в галетах!!!



PS: На самом деле Nekot -- это просто написанное задом-наперёд Token. Ну, как в Token Ring (о Гефест, кроме меня ещё кто-нибудь помнит это безобразие?)
Это безобразие вовсю применяется на производстве, поскольку из всех других безобразий может обеспечить гарантированное время доставки пакета.
Токен ринг - это верхний логический уровень, внизу можно на чем угодно.
>>Токен ринг - это верхний логический уровень
-
ШИТО????
Introduced by IBM in 1984, it was then standardized with protocol IEEE 802.5 and was fairly successful, particularly in corporate environments, but gradually eclipsed by the later versions of Ethernet.
..
In IEEE 802.5, the token passing scheme is used in place of Carrier Sense Multiple Access with Collision Detection (CSMA/CD) on a ring topology local area network (LAN). A token is circulated around a network.
-
Где тут логический уровень? В каком месте TR инкапсулируется в TCP/IP ???
Мне кажется у Вас некая каша в голове. С какого перепугу токен ринг должен инкапсулироваться в TCP/IP? При чем тут Ethernet?
>>Токен ринг - это верхний логический уровень
>> какого перепугу токен ринг должен инкапсулироваться в TCP/IP?
-
Вы не могли бы определиться, где у вас верх с логикой, а где низ с физикой?
Например, изучив картинку:


Точнее говоря даже так:
Какой из уровней:
Layer 1: Physical Layer
Layer 2: Data Link Layer
Layer 3: Network Layer
Layer 4: Transport Layer
Layer 5: Session Layer
Layer 6: Presentation Layer
Layer 7: Application Layer

вы называете логическим и почему?

Edited at 2016-09-11 09:16 pm (UTC)
Например, потому что он описывает формат кадра (токена), который передается в логическом кольце (ринг) и он не описывает уровень медиа.
>> потому что он описывает формат кадра (токена)
-
это прекрасно, но не отвечает ни на один из вышезаданных вопросов.
1. Точно ли это TR, а не IE, поскольку ни карт, ни коммутаторов в продаже нет ?
2. Какой из вышеперечисленных уровней модели вы называете логическим и чем вам не нравится стандартная модель, если вы решили придумать свою?
3. Что у вас находится ниже уровня TR (ближе к физике - кабелю), а что выше ?
Какой-нибудь RS-485 (или любой другой интерфейс), протянутый напрямую из пункта А в пункт Б, тоже обеспечит гарантированное время. Если же устройств, требующих гарантированное время, много ("портов не напасёшься"), то у token ring будет ниже надёжность - отказ любого узла будет означать выход из строя всей сети.

Так что если и применяется - то скорее в тех случаях, где оно было поставлено двадцать лет назад, и работает до сих пор. В новых инсталляциях я сильно сомневаюсь.
Начну с того, что Токен ринг - это верхний уровень, внизу может быть все что угодно. возможно есть и RS-485. Во-вторых, у токен ринг структура - звезда, поэтому выход одного узла на общей надежности не должен сказаться.
Википедия грит, "Станции на локальной вычислительной сети (LAN) Token Ring логически организованы в кольцевую топологию". Правда, физически это кольцо может находиться внутри одного MAU, тогда снаружи это выглядит как "звезда".

RS-485 (или, тем более, RS-232) при подключении "точка-точка" время доставки обеспечивает, и довольно часто используется "сам по себе" - то есть, прикладной уровень кладут прямо поверх RS-485. Если RS-485 подложить под что-то другое, под тот же токен ринг - да, свойства будут определяться ещё и токен рингом.

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

Но возьмём такую ситуацию: пусть в цепочке есть станция, в силу неисправности оборудования искажающая проходящие через неё данные (токен, допустим, как правило передаётся верно - он маленький, вероятность искажения невелика). Поскольку данные передаются по цепочке, они будут искажаться для любой передачи от станции "до" неисправной к станции "после". И непонятно как с этим бороться - если скажем станция не отвечает, её можно выкинуть из цепочки, тут же простых проверяемых технически признаков я не вижу.

Это я всё к тому, сказывается ли выход из строя одного узла на всей сети.
Это уже экстремальный случай, когда оборудование неисправно. Если все хорошо, то гарантируется время доставки пакетов. Может MAU заботится о достоверности данных, я не знаю? Хотя насколько я понимаю, MAU достаточно простое коммутационное устройство.
Ну, "отказ узла" (изначальная вводная) довольно часто означает неисправность оборудования, так что с чего начали, к тому и вернулись :-)
И хотя ситуация "почти работает, но бьёт пакеты" явно более редкая, чем полный отказ (при котором, как я понимаю, узел просто выкинут из кольца), в случае эзернета такой отказ повлияет только на сам узел (и его адресата), в токен ринге же - на все коммуникации "через" этот узел, то есть надёжность - ниже.
Почитал немного, оказывается надежность - не самая сильная сторона Токен ринг, "хуже чем у Etherenet". Что, впрочем, не отменяет изначального посыла о гарантированном времени доставки пакетов и предетерменированости протокола.
The AM carries out the following tasks:
Lost frames - If a token has not been seen for 10 milliseconds, then a ring purge is carried out and a new token is sent. This can happen if a source station suddenly leaves the ring before removing its own frame.
Orphaned frames - If a transmitting station goes inactive before receiving back its frame, the frame could circulate endlessly so preventing the release of a token and thereby stopping anyone else from transmitting. The Monitor bit is therefore set as each frame passes through the AM and each frame is checked to see if the Monitor bit is set, if so, then the frame is removed.
http://www.rhyshaden.com/tokenr.htm
> Lost frames - If a token has not been seen for 10 milliseconds, then a ring purge is carried out and a new token is sent

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

Да даже возьмём более простую ситуацию: пусть в цепочке есть станция, в силу неисправности оборудования искажающая проходящие через неё данные (токен, допустим, как правило передаётся верно - он маленький, вероятность искажения невелика). Поскольку данные передаются по цепочке, они будут искажаться для любой передачи от станции "до" неисправной к станции "после". И непонятно как с этим бороться - если скажем станция не отвечает, её можно выкинуть из цепочки, тут же простых проверяемых технически признаков я не вижу.
Токен, ЕМНИП, генерится Media Access Unit (MAU), а гуглить траблшутинг древней технологии мне откровенно лень.
>>Какой-нибудь RS-485 (или любой другой интерфейс), протянутый напрямую из пункта А в пункт Б, тоже обеспечит гарантированное время.
-
RS-485 only specifies electrical characteristics of the generator and the receiver. It does not specify or recommend any communications protocol, only the physical layer. Other standards define the protocols for communication over an RS-485 link.
1) не очень понятно, как это должно опровергать гарантированность времени доставки.

2) RS-485 довольно часто используется "сам по себе" - в том смысле, что протоколы прикладного уровня гоняют сразу над RS-485, без промежуточных уровней. На тех же "производствах" (в системах АСУТП), в частности.
1. Вот пдф-ка
http://www.ti.com/lit/wp/spry265/spry265.pdf
Не могу найти там про "гарантию времени доставки", кроме сноски
Ideal RS-485 turn-around delay is roughly 1 bit time, which is a factor of the baud rate (e.g., turn-around of 1 ms is ideal for a baud rate of 9600)

2. прикладной уровень - это русский перевод "Application layer" чтоли ? В вики он так значится.
"без промежуточных" - для датчика /привода нормально, почему нет. Вопрос в том, что стоит с другой стороны провода, и применим ли к этому чему-то термин "Application layer", или все же конвертер в середине какой-то имеется.
1. Ладно, 485 не очень удачный пример - там полудуплекс, поэтому одна сторона в принципе может заблокировать канал на неопределенное время. Правда, в рамках задачи "управление производством в реальном времени" это означает неисправность одной из сторон, а в этом случае ни о каких гарантиях речи быть не может. Ну, то есть, в рассматриваемой ситуации ("на производстве") размеры пакетов туда-сюда известны заранее, частота с которой они посылаются - тоже, и исходя из этого (и из того, что в режиме "точка-точка" нам никто помешать не может) можно рассчитать максимальное время, потребное для обмена пакетами. Если же размер пакета существенно превышен - это уже нештатная ситуация (скорее всего сбой программы).

Но возьмём RS-232. Там дуплекс, скорость задана, канал всегда доступен. Берем размер пакета, делим на скорость, получаем время передачи. Оно гарантировано простой математикой :-) Flow control я не рассматриваю, потому что если ввести понятие "устройство не готово к приёму", то гарантии времени доставки не будет ни на каком протоколе.

2. Я что-то запутался, в чем суть проблемы. Ну да, RS-485 "does not specify any communications protocol". Ну так и черт с ним - байтики он передаёт, а для того чтобы определиться, делает он это за гарантированное время, или нет - знать конкретный "communication protocol" вроде необязательно.
>>Но возьмём RS-232. Там дуплекс, скорость задана, канал всегда доступен. Берем размер пакета, делим на скорость, получаем время передачи. Оно гарантировано простой математикой :-)
-
Если так подходить, то и Ethernet все гарантирует - и дуплекс, и канал.
При подключении точка-точка - да, именно так (через хаб/свитч - уже нет). Но во-первых, это нетипичное применение, а во-вторых, напихать в комп кучу RS-xxx портов проще, чем кучу эзернет-портов, и через это тоже проистекают особенности практического применения.
>>При подключении точка-точка - да, именно так (через хаб/свитч - уже нет)
-
да ну? и что же такого вносит хаб в архитектуру?
---
>>напихать в комп кучу RS-xxx портов проще, чем кучу эзернет-портов
-
да ну? Какие ваши доказательства? Для примера -
На Intel E1G44HTBLK - 4* 10/100/1000Base-T .
На Silicom PXG6I RoHS Server 6-port Gigabit adapter - шесть.
> да ну? и что же такого вносит хаб в архитектуру?

Ну вообще-то при подключении через хаб постоянно возникают коллизии, и по достижении определённого количества нод количество коллизий начинает превышать полезный траффик.
мм... архитектура CSMA/CD в принципе подразумевает коллизии, о чем говорят буковки CD - collision detection. Вопрос немного в другом - в чем разница подключения точка-точка и точка - хаб (не свитч) - точка ? архитектурно ? Вопрос, замечу, разбирается в 100-101 и 100-105

Edited at 2016-09-12 02:51 pm (UTC)
Архитектурно никак, просто при наличии только двух нод на одном сетевом сегменте количество коллизий радикально меньше, чем при наличии, например, двух сотен.
>>м при наличии, например, двух сотен.
-
эт понятно. ЕМНИП при примерно 50 узлах уже все раком встает на 10-ке.
> да ну? и что же такого вносит хаб в архитектуру?

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

> да ну? Какие ваши доказательства?

Убедили :-) Даже цены разумные (ну, соразмеримые с ценами на многопортовки RS-xxx). Не знал.
>>> да ну? и что же такого вносит хаб в архитектуру?

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

Для двух узлов и свитча разницы нет вообще, для двух узлов и хаба - не уверен, вроде бы излишне активный узел способен эффективно мешать передаче второго узла.
>> Для двух узлов хаб/свитч не нужен, достаточно специального кабеля.
-
Для трех тоже. И для четырех общем-то тоже. Я больше скажу - достаточно коаксиального кабеля.
Я хотел про него вспомнить, ещё когда речь шла о двух узлах - потому что при двух узлах на коаксиале один узел таки точно способен на неопределенное время заблокировать передачу второму, но решил не вспоминать, чтобы не усложнять.

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

При хабе все ноды на сегменте входят в один и тот же домен коллизий.

Свитч просто тупо делит этот домен на много доменов, но в каждом домене всё равно не одна нода, а минимум две.

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

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

Ну, и правильный свитч - штука сложная. Раз уж он умеет одновременно принимать данные с нескольких портов, и одновременно отправлять их адресатам в разные порты, я не вижу технических причин свитчу не поддерживать полный дуплекс для двух узлов - это принципиально не отличается от обслуживания нескольких одновременно передающих узлов.
А, если полнодуплекс, то да, ты прав, коллизий не будет. Не подумал про это.
ладно, это не интересно уже. И специалист по логике в TR куда-то запропал.
общем, можно строить и на TR - только он дохлый, ничего в продаже не видно, и на Industrial ethernet - только тут нужно еще много всякого. Как, впрочем, и на TR
>>Ну, как в Token Ring (о Гефест, кроме меня ещё кто-нибудь помнит это безобразие?)
-
я помню название, ну и вообще Token - слово распространенное.
Помню только название, лично не наблюдал. Но топология в паре мест любопытная :-)