Изменения

Удобнее всего будет привести протоколы в виде псевдокода (хотя это валидный сишный кодНа канальном уровне нужно передавать данные с сетевого уровня. При этом требуется, чтобы кадры не дублировались, кажется)и сохранялся порядок. От Ниже представлены протоколы с различными допущениями о канале от самого простого случая (с идеальным каналом) к более сложным. Сначала даётся краткое словесное описание, затем сишный псевдокод, из которого всё понятно.

TODO: хорошо бы эти картиночки заменить на кодтекст, но мне пока как-то не хочется этим заниматься.

Данные передаются в одном направлении. Время обработки равно нулю, буфер бесконечен, канал идеальный.Отправитель просто постоянно шлёт данные, получатель постоянно читает. 

Всё то же самое, только теперь считаем, что получатель обрабатывает данные не моментально, поэтому посылающий не может постоянно слать данные. Для этого получатель будет ждать слать подтверждение, а принимающий отправитель будет его посылатьдожидаться, когда будет готовпрежде чем послать следующий пакет. Канал считаем идеальным. 

Теперь перестаём верить в идеальный канал, кадры могут теряться и искажаться (в том числе служебные). Введём порядковые номера для сообщений Проверку искажения кадра будем проводить уровнем ниже (сверять checksum). Чтобы обнаружить потерю кадра, запустим таймер и будем посылать их в подтвержденияхждать подтверждение. Если нам пришло подтверждения нет, а наступил таймаут, то кадр считаем потраченным и посылаем заново. Есть проблема: может потеряться подтверждение с тем же номером, что в таком случае произойдёт дублирование кадра. Для этого добавим порядковый номер кадра и у отправленного кадра, то всё окподтверждения. В псевдокоде для простоты этом случае принимающий будет знать, какой порядковый номер — 0 или 1он ждёт, и игнорировать кадры с неправильным номером. Также будем запускать таймер, чтобы пониматьНетрудно понять, что сообщение потерялосьдля порядкового номера хватит одного бита. 

Дуплексный протоколСимплексные протоколы — это плохо, потому что данные хотим посылать в обе стороны, а если сделать два отдельных канала, то получится дороже. Каждая сторона хранит «окно»В случае с дуплексными протоколами в обе стороны могут ходить и обычные кадры, и служебные (ACK). В заголовке кадра будем хранить kind, чтобы различать типы кадров. Есть техника piggybacking: если мы хотим послать подтверждение и обычный кадр, то пошлём их вместе (подтверждение положим в поле ACK в заголовке кадра). В таком варианте нужно заводить отдельный таймер на тот случай, когда от нас ждут подтверждение, а мы не хотим посылать обычный кадр (в этом случае мы просто пошлём кадр с подтверждением). То есть диапазон , если нам пришло сообщение, то мы либо довольно скоро захотим сами что-то послать и приложим подтверждение, либо просто пошлём подтверждение по тику таймера. Следующие три протокола относятся к протоколам скользящего окна. Суть в том, чтобы хранить два окна (диапазона порядковых номеров, соответствующих кадрамкадров) — посылающее и принимающее. Окно хранит номера кадров, которые мы можем посылать послать/принять. Когда сетевой уровень просит что-то послать, мы даём очередному кадру номер, равный верхней границе посылающего окна, и на которые можем получить подтвержденияувеличиваем эту границу. При получении кадра на отправку подтверждения увеличиваем верхнюю нижнюю границу . При получении пакета из принимающего окна, при оно сдвигается на единицу. При получении подтверждения увеличиваем нижнююпакета не из принимающего окна такой пакет игнорируется. Таким образом Это всё общая идея, в окне находятся те кадры, которые были посланыперейдём к конкретным реализациям. ===== Однобитовое окно =====Простейший вариант, но ещё не подтверждены. Размер когда размер окна (максимальный) как-то заранее фиксируется. В псевдокоде он равен единице. Также по-прежнему В этом случае после отправки одного пакета мы не будем гонять таймеротправлять следующий, пока не получим подтверждения о доставке первого. 

===== Протоколы с возвратом на N =====Предыдущие протоколоы плохи тем, что если Если у нас есть большая пропускная способность, небольшие кадры и большое время прохождения сигнала, то пропускная способность будет использоваться очень слабо, так как большую часть времени мы будем ждать подтверждение, прежде чем посылать очередной кадр. Поэтому будем посылать сразу много кадров не дожидаясь доставки/потери предыдущего.Размер посылающего окна больше единицы (но ограничен какой-нибудь константой). Есть два подхода к обработке ошибок. Первый называется возвратом на N. Если с каким-то из посланных кадров случилась беда, то все остальные посланные кадры игнорируются, что соответствует единичному размеру входящего окна. Через какое-то время проигнорированные кадры будут перепосланы отправителем. Это плохо в ситуации, когда возможно большое количество ошибок. [[Файл: Networks 1.5 Protocol5.1.png]] [[Файл: 2015-04-02-14-00-07_selection.png]] [[Файл: Networks 1.5 Protocol5.3.png]]

Возврат на n подразумевает, что если бы повреждён какой-то кадр (не пришло подтверждение/не сошлась checksum), то все кадры с большими номерами игнорируются, подтверждения на них не посылаются[[Файл: Networks 1. Отправитель должен будет перепослать испорчённый кадр и все за ним5 Protocol5.4.png]]

Альтернативный ===== Протоколы с выборочным повтором =====Второй вариант (выборочный повтор) — буферизовать обработки ошибок называется выборочным повтором. Если потерялся/повредился кадр, то все кадры следующие за ним получатель не игнорирует, а буферизует и шлёт на них подтверждения. Сломанный кадр будет перепослан, после ошибочногочего получатель сможет восстановить нужную последовательность. В таком случае отправитель перепошлёт только испорченные Доставленные кадры. Можно послать отрицательное подтверждение (NAK) для испорченного кадра, в этом случае отправитель сразу же перепошлёт повреждённый кадрперепосылать не потребуется.