Модератор: kustarev
ipavel писал(а):В конспекте как-то совсем непонятно описаны Go-Back-N и Selective Repeat, делюсь годными визуализаторами: http://www.ccs-labs.org/teaching/rn/animations/gbn_sr/
ipavel писал(а):Одновременная отправка, очевидно, бага. Ну и там версия без NACK.
Вообще, по разным источникам в сети этот протокол может быть реализован совсем по-разному:
1. без NACK (как в визуализаторе)
2. с NACK, который отправляется только один раз на первый неверный пакет, а затем приемник просто молчит
3. с NACK, который отправляется только один раз на первый неверный пакет, а затем приемник отвечает ACK на последний успешно принятый пакет
4. c NACK на каждый ошибочный пакет, пока всё не будет хорошо.
По идее самый эффективный вариант - 2-й. Его предполагается реализовать?
ipavel писал(а):Можно ли вообще в Go-Back-N с использованием NACK и канала, теряющего подтверждения, подобрать таймаут правильно? Возможна следующая ситуация:
1. Передатчик послал пакеты 1, 2, 3, 4
2. Приемник принял пакеты 1, 2, 3, 4 и соответственно послал ack 1, 2, 3, 4.
3. До передатчика дошел только ack 1, остальное потерялось.
4. Передатчик по таймауту пересылает заново пакеты 2, 3, 4
5. Приемник получает пакет 2 и ругается, отсылая NACK. Теперь приемник не отвечает, пока ему не придет пакет 5.
6. Передатчик, получив NACK снова пересылает пакеты 2, 3, 4 ни на один из них не дождется ответа и будет циклически отваливаться на таймауте, передача заглохнет.
Пока что склоняюсь к тому, что таймаут должен быть больше, чем (размер_окна * RTT). Тогда 100% приемник рано или поздно получит тот пакет, который ждёт.
UPD: на самом деле точнее должно быть что-то вроде: размер_окна*(Tack+Tпак) + RTT
UPD2: на самом деле всё намного хужеЕсли были приняты все пакеты, но потерялись все ack, то передатчик перепошлёт заново всё окно, однако приемник его выплюнет, ибо будет ждать уже следующего пакета. Реальный случай в работе
ipavel писал(а):1. Какие стратегии рекомендуется применять в л.р. 3? Если использовать стратегию повторной передачи только первого сегмента (согласно условию л.р.), стратегию приёма сегментов по порядку и одиночные подтверждения (как самые простые), то мы сталкиваемся с двумя проблемами:
а) После потери какого-либо пакета передатчик будет вынужден переотправлять всё из очереди "отправленных пакетов, не получивших подтверждения" по-одному, причём каждое - только по таймауту.
Пример: отправили пакеты 1, 2 ,3. Пакет 1 потерялся. Прошёл таймаут, отправляем только пакет 1. В ответ приходит подтсверждение и квитанция на отправку пакета 4. Отправляем пакет 4, но на него нет ответа, ибо приёмник ждёт пакет 2. Опять таймаут и так далее... В общем все-все последующие передачи будут повторными и делаться по таймауту каждая.
б) Теряется смысл в кредитах, по факту каждое подтверждение будет выдавать кредит на ещё один пакет.
2. Т.к. видимо использовать самые простые стратегии скорее всего не будет разрешено (см. первый вопрос), то очень хочется услышать пару советов, как в ptolemy можно организовать альтернативные стратегии малой кровью.
3. Как лучше всего передавать в рамках одного события несколько значений (номер подтверждения, выданные кредиты)? Попробовал сделать через массивы (по докам прошлогодних тем тут), не очень получилось. Any other ways?
ipavel писал(а):Это то неловкое чувство, когда вроде всё понятно уже, но упираешься в инструментарий. Крайне туго с реализацией двух вещей внутри конечного автомата в ptolemy:
1. очередь с возможностью удалять элементы из середины (причем не по индексу в очереди, а самому элементу). В принципе, это можно организовать с помощью Actor'ов ArrayAppend и ArrayRemoveElement, но тогда придется всё это выносить из автомата. Да и интуиция подсказывает, что это очень корявая реализация.
2. для правильной реализации приёма в окне логика работы над массивом сильно сложнее:
а) Если пришел пакет в начале окна, то сдвигаем окно на столько, сколько принятых пакетов с начала окна было (например, если пришло всё окно кроме первого пакета, а потом он переслался как раз. тогда окно сдвигается совсем целиком и выдаётся огромный кредит)
б) Иначе надо как-то в середину массива вставить элемент.
И вот с такой логикой неясно, куда копать.
http://ptolemy.eecs.berkeley.edu/ptolem ... ssions.pdf
Согласно этому доку в ptolemy есть массивы, но там же вообще не описаны операции над ними, как над структурами данныхИ в общем-то непонятно, это именно java-массивы или это всё же java-списки с возможностью удаления из середины.
Очень-очень просим хоть какой-то минимальный пример. В конце концов, это курс по протоколам, а не по изучению конкретной системы моделирования.
это курс по протоколам, а не по изучению конкретной системы моделирования.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0