Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Че делает свич 100/10 с "лишьними" фреймами? 18.11.03 03:46 [Den, amirul]
Автор: Zef <Alloo Zef> Статус: Elderman
|
всмысле с теми, которые из "широкого" канала не успевают пролезть в "узкий," и уже не помещаются в кэш.
1. Дропает?
2. Уведомляет отправителя о том, что нужно снизить скорость передачи? Как? Наск. я знаю, стандартом IPX это не предусмотренно. Может я не все знаю?
3. Имитирует коллизию (в сторону отправителя)?
Это лично моя идея, как можно подтормаживать скорость передачи на порту, не теряя пакеты, может ее где-нить уже реализовали?
|
|
Осторожно, двери закрываются... (всвязи с отсутствием конструктивных предложений) 8-) 29.11.03 08:35
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
|
А мож закроем и обойдемся без флейма??? 28.11.03 10:51
Автор: Den <Denis> Статус: The Elderman
|
|
|
|
При переполнении буфера инициируется ошибка передачи кадра. 20.11.03 12:21
Автор: Den <Denis> Статус: The Elderman
|
|
|
| |
Как? Стандарт IPX не предусматривает уведомления отправителя о получении/ошибке. Или? 20.11.03 13:14
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| | |
На физическом уровне 20.11.03 13:47
Автор: RazDolBai Статус: Member
|
|
|
|
Че делает свич 100/10 с "лишьними" фреймами? 18.11.03 07:59
Автор: cybervlad <cybervlad> Статус: Elderman
|
> 1. Дропает?
да
> 2. Уведомляет отправителя о том, что нужно снизить скорость
> передачи? Как? Наск. я знаю, стандартом IPX это не
> предусмотренно. Может я не все знаю?
IPX/IP уровнем выше, чем ethernet, посему "проблемы негров шерифа - сам знаешь" ;)
> 3. Имитирует коллизию (в сторону отправителя)?
> Это лично моя идея, как можно подтормаживать скорость
> передачи на порту, не теряя пакеты, может ее где-нить уже
> реализовали?
Да зачем эти сложности? Уровень ethernet не является уровнем гарантированной доставки. Послал, а там хоть трава не расти (кроме аппаратных коллизий, конечно). Каждый должен делать свое дело; в частности, проверять, доставлены ли пакеты - верхний уровень.
|
| |
Угу. Значит рост трафика может стать причиной отказа UDP-сервисов 18.11.03 10:01
Автор: Zef <Alloo Zef> Статус: Elderman
|
> > 3. Имитирует коллизию (в сторону отправителя)?
> > Это лично моя идея, как можно подтормаживать скорость
> > передачи на порту, не теряя пакеты, может ее где-нить
> уже
> > реализовали?
> Да зачем эти сложности? Уровень ethernet не является
> уровнем гарантированной доставки. Послал, а там хоть трава
> не расти (кроме аппаратных коллизий, конечно). Каждый
> должен делать свое дело; в частности, проверять,
> доставлены ли пакеты - верхний уровень.
А вот, данный вариант от этого избавляет. Кстати, такой подход очень хорош для жесткого ограничения трафика.
|
| | |
может 19.11.03 10:59
Автор: cybervlad <cybervlad> Статус: Elderman
|
> > доставлены ли пакеты - верхний уровень.
>
> А вот, данный вариант от этого избавляет. Кстати, такой
> подход очень хорош для жесткого ограничения трафика.
Кто бы спорил. Но есть стевая модель взаимодействия, и не дело нижнего уровня заниматсья гарантированием доставки.
|
| | | |
Почему же "не дело"? Модель ОСИ показала себя неоправданно жесткой, 20.11.03 05:10
Автор: Zef <Alloo Zef> Статус: Elderman
|
> > > доставлены ли пакеты - верхний уровень.
> >
> > А вот, данный вариант от этого избавляет. Кстати,
> такой
> > подход очень хорош для жесткого ограничения трафика.
> Кто бы спорил. Но есть стевая модель взаимодействия, и не
> дело нижнего уровня заниматсья гарантированием доставки.
Сегодня ее в точности никто не придерживается. Глупо придерживаться схемы, небольшое отступление от которой резко повышает надежность связи.
Другое дело, что предлагаемый фокус возможен только в полудуплексе (я прав?)
Предлагаемый механизм выглядит так: на порту стоит блок ассоциативной памяти, в к-рый заносятся МАК-и адресатов, в направлении к-рых произошло "переполнение". МАК адресата в поступающем фрейме аппаратно сравнивается с МАК-ами в ассоциативке и, если совпадает с одним из них, имитируется коллизия (выдается несущая).
Почему аппаратно и ассоциативка?
Потому, что встречную несущую надо успеть выдать до завершения передачи фрейма.
|
| | | | |
потому что каждый должен заниматься своим делом ;) 20.11.03 13:16
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Сегодня ее в точности никто не придерживается. Глупо
> придерживаться схемы, небольшое отступление от которой
> резко повышает надежность связи.
Вот-вот. А потом начинают рождаться протоколы типа STP...
> Предлагаемый механизм выглядит так: на порту стоит блок
> ассоциативной памяти, в к-рый заносятся МАК-и адресатов, в
> направлении к-рых произошло "переполнение". МАК адресата в
> поступающем фрейме аппаратно сравнивается с МАК-ами в
> ассоциативке и, если совпадает с одним из них, имитируется
> коллизия (выдается несущая).
А теперь поясни: нафига?
Передает комп информацию, которая спускается по стеку вниз, до ethernet. Имитация коллизии приведет к тому, что самый нижний уровень сразу же начнет попытки повторной пересылки, продолжая забивать очередь. Если же просто дропнуть фрейм, то верхний уровень, поняв, что происходят потери (отсутствие подстверждения по таймауту), притормозит передачу.
В х.25 скрестили эту фигню в одну сущность, и кому легче стало от этих "гарантий"? Тормозит все со страшной силой...
> Почему аппаратно и ассоциативка?
>
> Потому, что встречную несущую надо успеть выдать до
> завершения передачи фрейма.
Вот-вот. начинаем усложнять и удорожать простой девайс (свитч). В процессе наделаем ошибок, коотрые вызовут новые проблемы...
|
| | | | | |
Каждый занимается своим делом . "А за дикцию никто не отвечает"(с) А.Райкин 21.11.03 10:31
Автор: Zef <Alloo Zef> Статус: Elderman
|
> Вот-вот. начинаем усложнять и удорожать простой девайс
> (свитч). В процессе наделаем ошибок, коотрые вызовут новые
> проблемы...
Не ошибается только тот, кто ничего не делает. Главное, не выбрасывать на рынок в спешке полусырых продуктов, перегруженных "оживляжем", как у мелкомягких.
|
| | | | | | |
в том-то и дело 21.11.03 15:46
Автор: cybervlad <cybervlad> Статус: Elderman
|
> Не ошибается только тот, кто ничего не делает. Главное, не
Это был эпиграф к моей дипломной работе ;)
> выбрасывать на рынок в спешке полусырых продуктов,
> перегруженных "оживляжем", как у мелкомягких.
К сожалению, так оно и происходит. Есть модульная архитектура, которая усовершествуется ugly mode :(
|
| | | | | | | |
Ну, это уже флейм. Конструктивные идеи/возражения есть? Или свернем дискуссию? 22.11.03 09:00
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| | | | | | | | |
Вот именно, что флейм. Ты спросил "как?", я ответил. А убеждать IETF изменить OSI - без меня, please :) 24.11.03 07:52
Автор: cybervlad <cybervlad> Статус: Elderman
|
|
|
| | | |
а разве 2 уровень не должен гарантировать доставку в пределах LAN ? 19.11.03 22:17
Автор: tdes <jin> Статус: Member
|
|
|
| | | | |
Этим транспортный уровень занимается (4-й) [upd] 19.11.03 23:01
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 19.11.03 23:04 Количество правок: 1
|
И то не всегда (UDP - протокол транспортного уровня без гарантированной доставки). Причем обеспечение доставки - единственная цель транспортного уровня.
-----------
Кроме того, LAN может иметь довольно сложную конфигурацию, в которой невозможно обеспечить ГАРАНТИРОВАННУЮ физическую доставку. Взять хотя бы радиоканал или сетку с 4-5 уровнями свитчей.
|
| | | | | |
Этим транспортный уровень занимается (4-й) [upd] 20.11.03 00:40
Автор: tdes <jin> Статус: Member
|
транспортный, он же 4 уровень, я думал, обеспечивает гарантированную доставку между сетками (LAN'ми ), а если сеть одна, то в ней в принципе можно обойтись как без транспортного, так и без сетевого уровня,
то есть функциональность транспортного протокола может взять на себя LLC
|
| | | | | | |
Этим транспортный уровень занимается (4-й) [upd] 24.11.03 03:52
Автор: Covax_ Статус: Незарегистрированный пользователь
|
> то есть функциональность транспортного протокола может
> взять на себя LLC
Data Link Function 3: Error Detection
Error detection discovers whether bit errors occurred during the transmission of the frame. To
do this, most data links include a frame check sequence (FCS) or cyclical redundancy check
(CRC) field in the data link trailer. This field contains a value that is the result of a mathematical
formula applied to the data in the frame. The FCS value calculated and sent by the sender should
match the value calculated by the receiver. All four data links discussed in this section contain
an FCS field in the frame trailer.
Error detection does not imply recovery; most data links, including 802.5 Token Ring and 802.3
Ethernet, do not provide error recovery. In these two cases, however, an option in the 802.2
protocol, called LLC Type 2, does perform error recovery. (SNA and NetBIOS are the typical
higher-layer protocols in use that request the services of LLC2.)
(Wendell Odom, CCNA Exam 640-607 Certification Guide)
|
| | | | | | | |
Написал немного неточно 24.11.03 16:45
Автор: amirul <Serge> Статус: The Elderman
|
> Error detection does not imply recovery
Например реакция PPP-шного LCP (link control protocol) который и является этим даталинком на срыв фрейма (неверный FCS) - silent discard. Перепосылка потом осуществляется на транспортном уровне. Для топологии шина ввели хитрую схему работы с коллизиями, но это скорее от ущербности самой идеи такой топологии, чем реальная необходимость. Как пример: в винде начиная с 2000 графическую подсистему вынесли в ядро, но никто не говорит, что это правильно - так быстрее, но не факт, что правильно.
Имелось в виду, что если надо ГАРАНТИРОВАТЬ доставку, то это проблемы транспортного уровня, уровни ниже него могут проверять валидность фрейма, но если что не так - он просто дропится.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
