По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Перечисления, или перечисляемые типы данных, - это список постоянных значений с именами, которые удобны для разработчиков. В программировании они нужны для того, чтобы определить набор предопределенных значений, которые может принимать переменная.
Определение списка значений
Перечисления – это список значений, где каждое значение уникально. В перечислении не может быть двух значений с идентичными именами. Это весьма полезно, если нужно определить все возможные варианты значений, которые может обрабатывать функция.
Например, у вас есть перечисление под названием «Fruits». В нем хранится список фруктов, которые понятны для приложения. Именно в этом и есть ключевое отличие перечисления от использования строки для того, чтобы представить эту переменную, – строка может иметь бесконечное число возможных значений, а это перечисление – только три.
Это перечисление вы можете использовать в своем коде, например, для того, чтобы проверить, соответствует ли тип пользовательского ввода элементу Apple, или для передать его оператору switch/case в качестве аргумента для того, чтобы выполнить определенные действия для каждого типа возможного значения.
С точки зрения внутренней структуры перечисления сами по себе являются значениями. Это, конечно, зависит от реализации языка, но, например, в C# перечисления по умолчанию являются целыми значениями. Значения по умолчанию начинаются с 0, 1, 2, 3 и т.д., но их можно изменить вручную. Можно установить определенное значение для каждого элемента перечисления. Например, это могут быть коды состояния HTTP:
Они могут преобразовываться из значения в перечисление и наоборот с помощью простого приведения типов:
Перечисления не просто полезны для определения набора элементов, но они также неплохо помогают разработчикам. Даже если вы конвертируете данные в строковый или целочисленный тип перед тем, как отправить их в API, использования перечислений в вашей кодовой базе в любом случае обеспечит большую гибкость и приведет ваш код в порядок.
К тому же, наличие выпадающих списков с автозаполнением со списком возможных значений может помочь не только вам, но и любому, кто будет работать с вашей кодовой базой в дальнейшем. Никто не хочет сопровождать программный код, который в качестве аргументов принимает строки и выполняет случайные действия, основываясь на входных данных. Использование перечислений, напротив, строго определяет то, как себя будет вести приложение.
Недостатки использования перечислений
Основной недостаток перечислений заключается в том, что, как только они перестают находиться в вашей кодовой базе, они теряют свое особое значение. Например, у вас есть API, в котором вы сохраняете и отправляете данные. Для начала вам необходимо сериализовать перечисление, которое, скорее всего, по умолчанию принимает базовые значения 0, 1, 2 и т.д. Некоторые языки программирования поддерживают перечисления с базовыми строковыми значениями или настраивают правила сериализации перечислений так, чтобы сгладить эту проблему.
Проблемой может стать и изменение перечислений. Как только вы начинаете использовать перечисление, вы не можете больше менять порядок элементов. У вас есть право только добавить элементы в конец списка. В противном случае хранящиеся данные, которые используют старую версию перечисления, перестанут быть актуальными и будут искажены.
Перечисления как флаги
Еще одно популярное направление использования перечислений – это определение битовых флагов. Это достаточно продвинутая концепция, но по сути речь идет о том, что каждое значение перечисления – это логическое значение. Все эти перечисления можно хранить вместе в одном целом числе и использовать для выполнения быстрого поиска логических данных.
Это действительно работает, потому что каждое значение перечисления соответствует разным битам базового числа. Для двоичного представления значения перечисления будут следующие: 0, 1, 2, 4, 8, 16 и т.д. И вы можете соединить их вместе, чтобы получить список логических значений.
Почему именно такой вариант, а не несколько логических значений? Что ж, во-первых, это экономит место, а это в некоторых ситуациях (когда у вас их много) может быть очень на руку. Но, что еще важнее, при таком подходе можно очень быстро получить доступ к каждому значению, особенно если вам нужно получить доступ к нескольким значениям. Например, вы хотите проверить, выходной сегодня или нет. Вы можете проверить суббота сегодня или воскресенье (
Saturday | Sunday
), и все это из того же байта, что был загружен в память. Центральному процессору необходимо извлечь лишь один элемент, чтобы получить список всех флагов.
У каждого из нас, наверное, есть родственник (бабушка, брат, племянник или еще кто-то), который говорил так быстро, что вы не могли понять слова, которое он говорил? Некоторые компьютерные программы тоже "говорят" слишком быстро. Рисунок 1 иллюстрирует это.
На рисунке:
В момент времени 1 (T1) отправитель передает около четырех пакетов на каждые три, которые может обработать приемник. Приемник имеет пяти-пакетный буфер для хранения необработанной информации; в этом буфере находятся два пакета.
В момент времени Т2 отправитель передал четыре пакета, а получатель обработал три; буфер в приемнике теперь содержит три пакета.
На этапе T3 отправитель передал четыре пакета, а получатель обработал три; буфер в приемнике теперь содержит четыре пакета.
На этапе T4 отправитель передал четыре пакета, а получатель обработал три; буфер в приемнике теперь содержит пять пакетов.
Следующий переданный пакет будет отброшен получателем, потому что в буфере нет места для его хранения, пока получатель обрабатывает пакеты, чтобы их можно было удалить. Что необходимо, так это своего рода петля обратной связи, чтобы сказать передатчику замедлить скорость, с которой он посылает пакеты, как показано на рисунке 3.
Этот тип обратной связи требует либо неявной сигнализации, либо явной сигнализации между приемником и передатчиком. Неявная передача сигналов используется более широко. При неявной сигнализации передатчик предполагает, что пакет не был принят на основании некоторых наблюдений о потоке трафика. Например, получатель может подтвердить получение некоторого более позднего пакета, или получатель может просто не подтвердить получение определенного пакета, или получатель может не отправлять что-либо в течение длительного периода времени (в терминах сети). При явной сигнализации получатель каким-то образом напрямую сообщает отправителю, что определенный пакет не был получен.
Windowing
Windowing в сочетании с неявной передачей сигналов, безусловно, является наиболее широко используемым механизмом управления потоками в реальных сетях. Windowing по существу состоит из следующего:
Передатчик отправляет некоторое количество информации получателю.
Передатчик ждет, прежде чем решить, правильно ли была получена информация или нет.
Если получатель подтверждает получение в течение определенного периода времени, передатчик отправляет новую информацию.
Если получатель не подтверждает получение в течение определенного периода времени, передатчик повторно отправляет информацию.
Неявная сигнализация обычно используется с Windowing протоколами, просто не подтверждая получение конкретного пакета. Явная сигнализация иногда используется, когда получатель знает, что он сбросил пакет, когда полученные данные содержат ошибки, данные получены не по порядку или данные иным образом повреждены каким-либо образом. Рисунок 3 иллюстрирует простейшую Windowing схему-окно с одним пакетом.
В одиночном окне пакета (также иногда называемом ping pong) передатчик отправляет пакет только тогда, когда получатель подтвердил (показанный на рисунке как ack) получение последнего переданного пакета. Если пакет не получен, получатель не подтвердит его. При отправке пакета отправитель устанавливает таймер, обычно называемый таймером повторной передачи; как только этот таймер активируется (или истекает), отправитель предполагает, что получатель не получил пакет, и отправляет его повторно.
Как долго должен ждать отправитель? Существует несколько возможных ответов на этот вопрос, но по существу отправитель может либо ждать фиксированное количество времени, либо установить таймер на основе информации, полученной из предыдущих передач и условий сети. Простой (и наивной) схемой было бы
Измерьте промежуток времени между отправкой пакета и получением подтверждения, называемый временем обратного пути (RTT- Round Trip Time, хотя обычно пишется в нижнем регистре, поэтому rtt).
Установите таймер повторной передачи на это число плюс небольшое количество времени буфера, чтобы учесть любую изменчивость в RTT на протяжении нескольких передач.
Кроме того, получатель может получить две копии одной и той же информации:
A передает пакет и устанавливает таймер его повторной передачи
B получает пакет, но
Не может подтвердить получение, потому что он находится вне памяти или испытывает высокую загрузку процессора или какое-то другое состояние.
Отправляет подтверждение, но оно отбрасывается сетевым устройством.
Таймер повторной передачи в точке A истекает, поэтому отправитель передает другую копию пакета.
B получает эту вторую копию той же информации
Как получатель может обнаружить дублированные данные? Для получателя представляется возможным сравнить полученные пакеты, чтобы увидеть, есть ли дублирующаяся информация, но это не всегда будет работать - возможно, отправитель намеревался отправить одну и ту же информацию дважды. Обычный метод обнаружения дублирующейся информации заключается в включении некоторого вида порядкового номера в передаваемые пакеты. Каждому пакету присваивается уникальный порядковый номер при его создании отправителем; если получатель получает два пакета с одинаковым порядковым номером, он предполагает, что данные дублированы, и отбрасывает копии.
Окно размером 1, или ping pong, требует одного кругового перехода между отправителем и получателем для каждого набора передаваемых данных. Это, как правило, приводит к очень низкой скорости передачи. Если рассматривать сеть, как о сквозном железнодорожном пути, а каждый пакет-как об одном вагоне поезда, то наиболее эффективное использование пути и самая быстрая скорость передачи данных будут тогда, когда путь всегда полон. Это физически невозможно, однако, в случае сети, потому что сеть используется многими наборами отправителей и получателей, и всегда есть сетевые условия, которые помешают использованию сети достичь 100%. Существует некоторый баланс между повышением эффективности и скорости отправки более одного пакета за один раз, а также мультиплексированием и "безопасностью" отправки меньшего количества пакетов за один раз (например, одного). Если правильная точка баланса может быть вычислена каким-то образом, схема управления потоком с фиксированным окном может хорошо работать. Рисунок 4 иллюстрирует это.
На рисунке 4, предполагаемое фиксированное окно с тремя пакетами:
При T1, T2 и T3 A передает пакеты; A не нужно ждать, пока B что-либо подтвердит, чтобы отправить эти три пакета, так как размер окна установлен на 3.
В момент T4 B подтверждает эти три пакета, что позволяет A передать другой пакет.
При T5 B подтверждает этот новый пакет, даже если это только один пакет. B не нужно ждать, пока A передаст еще три пакета, чтобы подтвердить один пакет. Это подтверждение позволяет A иметь достаточный бюджет для отправки еще трех пакетов.
При T5, T6 и T7 A отправляет еще три пакета, заполняя свое окно. Теперь он должен ждать, пока B не подтвердит эти три пакета, чтобы отправить больше информации.
На этапе T8 B подтверждает получение этих трех пакетов.
В схемах управления окнами, где размер окна больше одного, существует четыре вида подтверждений, которые приемник может отправить передатчику:
Положительное подтверждение: приемник подтверждает получение каждого пакета в отдельности. Например, если порядковые номера 1, 3, 4 и 5 были получены, приемник подтвердит получение этих конкретных пакетов. Отправитель может сделать вывод, какие пакеты не получил приемник, отметив, какие порядковые номера не были подтверждены.
Отрицательное подтверждение: приемник отправляет отрицательное ack для пакетов, которые, по его мнению, отсутствуют или были повреждены при получении. Например, если порядковые номера 1, 3, 4 и 5 были получены, приемник может сделать вывод, что порядковый номер 2 отсутствует, и отправить отрицательное ack для этого пакета.
Выборочное подтверждение: по сути, это сочетание положительного и отрицательного подтверждения, как указано выше; приемник отправляет как положительные, так и отрицательные подтверждения для каждой последовательности полученной информации.
Кумулятивное подтверждение: подтверждение получения порядкового номера подразумевает получение всей информации с более низкими порядковыми номерами. Например, если порядковый номер 10 подтвержден, подразумевается информация, содержащаяся в порядковых номерах 19, а также информация, содержащаяся в порядковом номере 10
Третий оконный механизм называется управлением потоком скользящего окна. Этот механизм очень похож на фиксированный механизм управления потоком окон, за исключением того, что размер окна не является фиксированным. При управлении потоком со скользящим окном передатчик может динамически изменять размер окна при изменении сетевых условий. Приемник не знает, какого размера окно, только то, что отправитель передает пакеты, и время от времени приемник подтверждает некоторые или все из них, используя один из механизмов подтверждения, описанных в предыдущем списке. Механизмы скользящих окон добавляют еще один интересный вопрос к вопросам, уже рассмотренным в других механизмах управления окнами: какого размера должно быть окно? Простое решение позволяет просто вычислить rtt и установить размер окна, кратный rtt. Были предложены более сложные решения;
Negotiated Bit Rates (Согласование Bit Rates)
Другое решение, которое чаще используется в сетях с коммутацией каналов, а не в сетях с коммутацией пакетов, заключается в том, чтобы отправитель, получатель и сеть согласовывали скорость передачи битов для любого конкретного потока. Широкий спектр возможных скоростей передачи данных был разработан для ряда различных сетевых технологий. Возможно, "наиболее полный набор" предназначен для асинхронного режима передачи данных (ATM)-но данные сети ATM вы скорее всего найдете в ближайшем Музее истории сетей, потому что ATM редко развертывается в производственных сетях. Битовые скорости ATM являются:
Постоянная скорость передачи (Constant Bit Rate -CBR): отправитель будет передавать пакеты (или информацию) с постоянной скоростью; следовательно, сеть может планировать с учетом этой постоянной нагрузки на полосу пропускания, а приемник может планировать с учетом этой постоянной скорости передачи данных. Этот битрейт обычно используется для приложений, требующих синхронизации времени между отправителем и получателем.
Переменная скорость передачи (Variable Bit Rate -VBR): отправитель будет передавать трафик с переменной скоростью. Эта скорость обычно согласовывается с несколькими другими частями информации о потоке, которые помогают сети и получателю планировать ресурсы, включая:
Пиковая скорость или максимальная скорость передачи пакетов в секунду, которую планирует передать отправитель
Устойчивая скорость или скорость, с которой отправитель планирует передавать данные в обычном режиме
Максимальный размер пакета или наибольшее количество пакетов, которые отправитель намеревается передать за очень короткий промежуток времени
Доступная скорость передачи (Available Bit Rate -ABR): отправитель намеревается полагаться на способность сети доставлять трафик с максимальной отдачей, используя некоторую другую форму управления потоком, такую как метод скользящего окна, для предотвращения переполнения буфера и настроить передаваемый трафик на доступную полосу пропускания.
Перед тем как начать: это цикл статей. Мы рекомендуем до этого материала ознакомиться со статьей про Interlayer Discovery.
Хотя IPv6 является основной темой этих лекций, в некоторых случаях IPv4 представляет собой полезный пример решения; Address Resolution Protocol IPv4 (ARP) является одним из таких случаев. ARP - это очень простой протокол, используемый для решения проблемы межуровневого обнаружения, не полагаясь на сервер любого типа. Рисунок ниже будет использован для объяснения работы ARP.
Предположим, A хочет отправить пакет C. Зная IPv4-адрес C,
203.0.113.12 недостаточно, чтобы A правильно сформировал пакет и поместил его на канал связи по направлению к C. Чтобы правильно построить пакет, A также должен знать:
Находится ли C на том же канале связи, что и A
MAC или физический адрес C
Без этих двух частей информации A не знает, как инкапсулировать пакет в канал связи, поэтому C фактически получит пакет, а B проигнорирует его. Как можно найти эту информацию? На первый вопрос, находится ли C на том же канале вязи, что и A, можно ответить, рассмотрев IP-адрес локального интерфейса, IP-адрес назначения и маску подсети.
ARP решает вторую проблему, сопоставляя IP-адрес назначения с MAC-адресом назначения, с помощью следующего процесса:
Хост A отправляет широковещательный пакет каждому устройству в сети, содержащему адрес IPv4, но не MAC-адрес. Это запрос ARP; это запрос A на MAC-адрес, соответствующий 203.0.113.12.
B и D получают этот пакет, но не отвечают, поскольку ни один из их локальных интерфейсов не имеет адреса 203.0.113.12.
Хост C получает этот пакет и отвечает на запрос, снова используя unicast пакет. Этот ответ ARP содержит как IPv4-адрес, так и соответствующий MAC-адрес, предоставляя A информацию, необходимую для создания пакетов в направлении C.
Когда A получает этот ответ, он вставляет сопоставление между 203.0.113.12 и MAC-адресом, содержащимся в ответе, в локальном кэше ARP. Эта информация будет храниться до истечения времени ожидания; правила тайм-аута записи кэша ARP различаются в зависимости от реализации и часто могут быть настроены вручную. Продолжительность кэширования записи ARP - это баланс между слишком частым повторением одной и той же информации в сети в случае, когда сопоставление IPv4-адресов с MAC-адресами не меняется очень часто, и отслеживанием любых изменений в расположении устройство в случае, когда конкретный адрес IPv4 может перемещаться между хостами.
Когда A получает этот ответ, он вставляет сопоставление между 203.0.113.12 и MAC-адресом, содержащимся в ответе, в локальный кэш ARP. Эта информация будет храниться до тех пор, пока не истечет время ожидания; правила для тайм-аута записи кэша ARP варьируются в зависимости от реализации и часто могут быть настроены вручную. Продолжительность кэширования записи ARP - это баланс между тем, чтобы не повторять одну и ту же информацию слишком часто в сети, в случае, когда сопоставление IPv4-MAC-адресов меняется не очень часто, и идти в ногу с любыми изменениями в местоположении устройства, в случае, когда конкретный IPv4-адрес может перемещаться между хостами.
Любое устройство, получающее ответ ARP, может принять пакет и кэшировать содержащуюся в нем информацию. Например, B, получив ответ ARP от C, может вставить сопоставление между 203.0.113.12 и MAC-адресом C в свой кэш ARP. Фактически, это свойство ARP часто используется для ускорения обнаружения устройств, когда они подключены к сети. В спецификации ARP нет ничего, что требовало бы от хоста ожидания запроса ARP для отправки ответа ARP. Когда устройство подключается к сети, оно может просто отправить ответ ARP с правильной информацией о сопоставлении, чтобы ускорить процесс начального подключения к другим узлам на том же проводе; это называется gratuitous ARP. Gratuitous ARP также полезны для Duplicate.
Gratuitous ARP также полезны для обнаружения дублирующихся адресов (Duplicate Address Detection - DAD); если хост получает ответ ARP с адресом IPv4, который он использует, он сообщит о дублированном адресе IPv4. Некоторые реализации также будут посылать серию gratuitous ARPs в этом случае, чтобы предотвратить использование адреса или заставить другой хост также сообщить о дублирующемся адресе.
Что произойдет, если хост A запросит адрес, используя ARP, который не находится в том же сегменте, например, 198.51.100.101 на рисунке 5? В этой ситуации есть две разные возможности:
Если D настроен для ответа как прокси-ARP, он может ответить на запрос ARP с MAC-адресом, подключенным к сегменту. Затем A кэширует этот ответ, отправляя любой трафик, предназначенный для E, на MAC-адрес D, который затем может перенаправить этот трафик на E. Наиболее широко распространенные реализации по умолчанию не включают прокси-ARP.
A может отправлять трафик на свой шлюз по умолчанию, который представляет собой локально подключенный маршрутизатор, который должен знать путь к любому пункту назначения в сети.
IPv4 ARP - это пример протокола, который отображает interlayer идентификаторы путем включения обоих идентификаторов в один протокол.
Обнаружение соседей IPv6
IPv6 заменяет более простой протокол ARP серией сообщений Internet Control Message Protocol (ICMP) v6. Определены пять типов сообщений ICMPv6:
Тип 133, запрос маршрутизатора
Тип 134, объявление маршрутизатора
Тип 135, запрос соседа
Тип 136, объявление соседа
Тип 137, перенаправление
Рисунок ниже используется для объяснения работы IPv6 ND. Чтобы понять работу IPv6 ND, лучше всего проследить за одним хостом, поскольку он подключен к новой сети. Хост A на рисунке ниже используется в качестве примера.
A начнет с формирования link local address, как описано ранее. Предположим, A выбирает fe80 :: AAAA в качестве link local address.
Теперь A использует этот link local address в качестве адреса источника и отправляет запрос маршрутизатору на link local multicast address (адрес многоадресной рассылки для всех узлов). Это сообщение ICMPv6 типа 133.
B и D получают этот запрос маршрутизатора и отвечают объявлением маршрутизатора, которое является сообщением ICMPv6 типа 134. Этот одноадресный пакет передается на локальный адрес канала A, используемый в качестве адреса источника, fe80 :: AAAA.
Объявление маршрутизатора содержит информацию о том, как вновь подключенный хост должен определять информацию о своей локальной конфигурации в виде нескольких флагов.
Флаг M указывает, что хост должен запросить адрес через DHCPv6, потому что это управляемый канал.
Флаг O указывает, что хост может получать информацию, отличную от адреса, который он должен использовать через DHCPv6. Например, DNS-сервер, который хост должен использовать для разрешения имен DNS, должен быть получен с помощью DHCPv6.
Если установлен флаг O, а не флаг M, A должен определить свой собственный IPv6-адрес интерфейса. Для этого он определяет набор префиксов IPv6, используемых в этом сегменте, исследуя поле информации о префиксе в объявлении маршрутизатора. Он выбирает один из этих префиксов и формирует IPv6-адрес, используя тот же процесс, который он использовал для формирования link local address: он добавляет локальный MAC-адрес (EUI-48 или EUI-64) к указанному префиксу. Этот процесс называется SLAAC.
Теперь хост должен убедиться, что он не выбрал адрес, который использует другой хост в той же сети; он должен выполнять DAD. Чтобы выполнить обнаружение повторяющегося адреса:
Хост отправляет серию сообщений запроса соседей, используя только что сформированный IPv6-адрес и запрашивая соответствующий MAC-адрес (физический). Это сообщения ICMPv6 типа 135, передаваемые с link local address, уже назначенного интерфейсу.
Если хост получает объявление соседа или запрос соседа с использованием того же адреса IPv6, он предполагает, что локально сформированный адрес является дубликатом; в этом случае он сформирует новый адрес, используя другой локальный MAC-адрес, и попытается снова.
Если хост не получает ни ответа, ни запроса соседа другого хоста, использующего тот же адрес, он предполагает, что адрес уникален, и назначает вновь сформированный адрес интерфейсу.
Устранение ложных срабатываний при обнаружении повторяющегося адреса
Процесс DAD, описанный здесь, может привести к ложным срабатываниям. В частности, если какое-то другое устройство на канале связи передает исходные пакеты запроса соседа обратно к A, оно будет считать, что это от другого хоста, требующего тот же адрес, и, следовательно, объявит дубликат и попытается сформировать новый адрес. Если устройство постоянно повторяет все запросы соседей, отправленные A, A никогда не сможет сформировать адрес с помощью SLAAC.
Чтобы решить эту проблему, RFC7527 описывает усовершенствованный процесс DAD. В этом процессе A будет вычислять одноразовый номер, или, скорее, случайно выбранную серию чисел, и включать ее в запрос соседей, используемый для проверки дублирования адреса. Этот одноразовый номер включен через расширения Secure Neighbor Discovery (SEND) для IPv6, описанные в RFC3971.
Если A получает запрос соседа с тем же значением nonce, который он использовал для отправки запроса соседа вовремя DAD, он сформирует новый одноразовый номер и попытается снова. Если это произойдет во второй раз, хост будет считать, что пакеты зацикливаются, и проигнорирует любые дальнейшие запросы соседей с собственным одноразовым номером в них. Если полученные запросы соседей имеют одноразовый номер, отличный от того, который выбрал локальный хост, хост будет предполагать, что на самом деле существует другой хост, который выбрал тот же адрес IPv6, и затем сформирует новый адрес IPv6.
Как только у него есть адрес для передачи данных, A теперь требуется еще одна часть информации перед отправкой информации другому хосту в том же сегменте - MAC-адрес принимающего хоста. Если A, например, хочет отправить пакет в C, он начнет с отправки multicast сообщения запроса соседа на C с запросом его MAC-адреса; это сообщение ICMPv6 типа 135. Когда C получает это сообщение, он ответит с правильным MAC-адресом для отправки трафика для запрошенного IPv6-адреса; это сообщение ICMPv6 типа 136.
В то время как предыдущий процесс описывает объявления маршрутизатора, отправляемые в ответ на запрос маршрутизатора, каждый маршрутизатор будет периодически отправлять объявления маршрутизатора на каждом подключенном интерфейсе. Объявление маршрутизатора содержит поле lifetime, указывающее, как долго действует объявление маршрутизатора.
А теперь почитайте о проблемах шлюза по умолчанию. У нас получился отличным материал на эту тему.