Licklider Transmission Protocol — протокол связи «точка-точка», предназначенный для использования в каналах связи для дальнего космоса, который был разработан для обеспечения надежной передачи данных по каналам с экстремально большими значениями времени кругового обхода и/или частыми разрывами связи, в связи с чем данный протокол прежде всего предназначен для поддержки надежной дальней связи через межпланетные радиоканалы.
Licklider Transmission Protocol обычно рассматривается как стандартный базовый протокол уровня конвергенции для Bundle Protocol, поддерживающий широкий выбор сетей.
Протокол получил свое наименование в честь американского ученого Джозефа Ликлайдера.
Описание протокола Работа рассматриваемого протокола начинается с момента, когда экземпляр клиента запрашивает у машины LTP передачу блока данных удаленному клиенту.
LTP рассматривает каждый блок данных, как состоящий из двух частей — «красной» и «зеленой». При доставке «красной» используются подтверждения и при необходимости повторы передачи, а при доставке «зеленой» предпринимаются попытки доставить без обеспечения гарантий. LTP может работать, подобно протоколу TCP и UDP одновременно в рамках одной сессии.
Экземпляр клиента использует программный интерфейс LTP для идентификации LTP экземпляра удаленного клиента, которому нужно передать данные, местоположение передаваемых данных, общий размер передаваемой информации и размер данных в начальной части блока, которые передаются в качестве «красных». Передающая машина начинает сеанс передачи этого блока и уведомляет экземпляр клиента о начале сеанса, при этом важно заметить, что передающая машина не согласует начало сеанса с машиной удаленного клиента.
После этого передающая машина инициирует первоначальную передачу, помещая в очередь столько сегментов данных, сколько требуется для передачи блока целиком, с учётом ограничений на размер сегмента, вносимых нижележащим коммуникационным уровнем. Последний сегмент «красной» части блока отмечается маркером, который говорит о завершении данной части и идентифицируется уникальным порядковым номером, показывающим, что приемная машина должна отправить подтверждение доставки при получении этого сегмента.
Протокол LTP рассчитан на работу непосредственно «поверх» протокола канального уровня, но может также в некоторых случаях (например, при разработке программ или при использовании в частных ЛВС) работать «поверх» протокола UDP.
После этого выделяется полоса для очереди, в которую помещены сегменты данных блока, помещенные в очередь сегменты, их размеры передаются локальному протоколу канального уровня через поддерживаемый этим протоколом интерфейс API для передачи машине LTP обслуживающей удаленный экземпляр клиента.
Таймер запускается в момент маркировки конца «красной» части, поэтому при отсутствии отклика он может быть автоматически запущен снова.
Каждый модуль данных локального протокола канального уровня должен содержать целое число сегментов LTP и локальный протокол канального уровня никогда не должен доставлять неполные сегменты LTP приемной машине LTP. Когда в качестве локального протокола канального уровня используется UDP, следует использовать расширение LTP для аутентификации [LTPEXT], чтобы гарантировать целостность данных в тех случаях. От использования этого расширения можно отказаться, если на всем пути обеспечивается пренебрежимо малая вероятность повреждения пакетов (как в некоторых приватных ЛВС) или последствиями повреждения данных в процессе передачи и/или обработки можно пренебречь (как в некоторых случаях при разработке приложений). Когда расширение LTP для аутентификации не используется, протокол LTP требует от локального протокола канального уровня контроля целостности всех принятых сегментов. В частности, локальный протокол канального уровня должен детектировать и отбрасывать принятые поврежденные сегменты.
Принятые сегменты, которые не были отброшены, передаются приемной машине LTP через интерфейс API, поддерживаемый локальным протоколом канального уровня.
При получении первого сегмента данных для блока принимающая машина запускает сеанс приема для этого блока и уведомляет локальный экземпляр соответствующего клиентского сервиса о начале сеанса. В обычных условиях все сегменты исходной передачи принимаются без ошибок. Все факты доставки данных и протокольные события передаются локальному экземпляру клиентского сервиса с использованием программного интерфейса реализации LTP. Отметим, что по причине однонаправленности потока данных LTP подтверждения LTP (отчеты о получении) не могут прицепляться к сегментам данных TCP и передаются в отдельном типе сегментов.
На следующем этапе помещенный в очередь сегмент отчета незамедлительно отправляется передающей машине и запускается таймер, по завершении отсчета которого отчетный сегмент передается повторно, если не будет получен отклик. Передающая машина получает сегмент отчета, выключает таймер, помещает в очередь для передачи приемной машине сегмент подтверждения приема отчета и уведомляет локальный экземпляр клиентского сервера об успешной передаче красной части блока. На этом сеанс передачи красной части завершается.
На следующем этапе помещенный в очередь сегмент подтверждения отчета незамедлительно передается приемной машине.
Приемная машина получает сегмент подтверждения отчета и выключает для этого сегмента таймер повтора. Сеанс приема красной части и передача блока на этом завершается.
Отложенная передача Информация о состоянии канала также уведомляет LTP о невозможности передачи сегментов. В межпланетной связи ни в какой момент нельзя быть уверенным в наличии двухсторонней связи. В LTP всегда возможна генерация исходящего, который невозможно передать незамедлительно, — в ответ на прием сегмента, по тайм-ауту или запросу клиентского сервиса. Эти сегменты должны помещаться в очередь для последующей передачи, когда канал будет организован, о чём укажет информация о состоянии канала.
Концептуально каждый исходящий сегмент LTP добавляется в конец одной или двух очередей (формируя набор очередей) трафика, привязанного к машине LTP, которая является получателем сегмента. Одна из таких очередей является «внутренней операционной очередью» данного набора, другая — очередью данных приложения. Извлечение сегмента из очереди всегда означает его доставку нижележащей коммуникационной системе для незамедлительной передачи. Когда внутренняя операционная очередь не пуста, наиболее старый сегмент в этой очереди является следующим сегментом, который будет извлечен из очереди для передачи адресату. В остальных случаях следующим сегментом для извлечения из очереди и передачи является наиболее старый сегмент очереди данных приложений.
Создание и размещение сегмента в очереди и последующая реальная передача этого сегмента, в принципе, совершенно не синхронизированы.
В случае, когда коммуникационный канал к адресату активен, очередь, в которую помещается данный исходящий сегмент, пуста и эта очередь является внутренней операционной или последняя пуста, сегмент будет передаваться незамедлительно после его создания. Передача вновь созданных сегментов во всех других случаях откладывается.
Концептуально отмена постановки в очередь (de-queuing) сегментов из очередей трафика, привязанных к данному получателю, инициируется при получении сигнала о состоянии канала, указывающего, что базовая коммуникационная система передает данные этому адресату (то есть канал к получателю активен). Это прекращается после получения сигнала о том, что базовая коммуникационная система больше не передает данных этому получателю.
Таймеры LTP опирается на точный расчет ожидаемого времени прибытия сегментов с отчетами и подтверждениями для того, чтобы знать, когда нужен упреждающий повтор передачи. Если расчетное время оказалось немного раньше, в результате могут возникнуть издержки от ненужного повтора передачи. С другой стороны, расчетное время прибытия может на несколько секунд позже безопасно и единственным «наказанием» за более поздний тайм-аут и повтор передачи будет незначительная задержка доставки данных и освобождения ресурсов сессии.
Поскольку статистику, основанную на истории интервалов кругового обхода, невозможно безопасно использовать для предсказания времени кругового обхода LTP, мы должны предположить, что время кругового обхода по крайней мере приблизительно детерминировано (то есть достаточно точная оценка значения RTT может быть выполнена индивидуально в реальном масштабе времени на основе доступной информации).
Расчет выполняется в два этапа:
Первое приближение RTT рассчитывается простым удвоением времени прохождения светового луча к получателю с добавлением произвольного значения предполагаемой дополнительной задержки (например, в очередях или при обработке в оконечных точках). Для операций в глубоком космосе такая добавка обычно составит несколько (немного) секунд. Хотя такая добавка представляется аномальной с точки зрения стандартов Internet, она невелика по сравнению со временем прохождения света туда и обратно. Мы предпочли риск запоздалого повтора передачи, который просто задержит доставку одного блока на сравнительно небольшое время, слишком раннему повтору, ведущему к неоправданному расходу пропускной способности и общему снижению производительности. Затем для учёта дополнительных задержек, вносимых перебоями в связи, таймеры динамически приостанавливаются на те периоды, когда относящиеся к делу удаленные машины LTP заведомо не способны передавать отклики. Предполагается, что состояние удаленных систем определяется на основе сигналов о состоянии канала от работающего оборудования.
Приведенное ниже обсуждение служит базой для расчетов ожидаемого времени прибытия LTP.
Общее время, требуемое для одного «кругового обхода» (передача и прием исходного сегмента, а затем передача и прием сегмента подтверждения) состоит из перечисленных ниже компонент.
Протокольное время обработки. Время, затрачиваемое на выдачу исходного сегмента, его прием, генерацию и выдачу сегмента подтверждения, а также прием сегмента подтверждения. Задержка в выходных очередях. Задержка у отправителя исходного сегмента на ожидание в очереди на передачу и задержка у отправителя подтверждения на ожидание в очереди на передачу. Время на передачу. Время на выдачу (отправку) всех битов исходного сегмента и время на выдачу всех битов сегмента подтверждения (это важно лишь при очень низкой скорости передачи). Время кругового обхода со скоростью света. Время распространения сигнала со скоростью света в обоих направлениях. Задержка во входных очередях. Задержка во входной очереди у получателя исходного сегмента и задержка во входной очереди у получателя сегмента подтверждения. Задержка на передачу исходного сегмента или сегмента подтверждения по причине потери связи, то есть в результате прекращения активности у отправителя любого из сегментов по причине затенения, запланированного выхода из зоны видимости и т. п.
В этом контексте, где могут возникать ошибки продолжительностью в секунды и даже минуты, протокольное время обработки на каждой из сторон сессии считается пренебрежимо малым.
Задержка во входной очереди также считается пренебрежимо малой, поскольку даже на мелких космических станциях скорость обработки LTP значительно выше скорости передачи данных.
Применяется два механизма снижения задержки в выходных очередях до пренебрежимо малых значений.
Ожидаемое время прибытия сегмента подтверждения не рассчитывается, пока базовая система связи не уведомит LTP о начале передачи исходного сегмента. Все задержки выходногой очереде для исходного сегмента к этому моменту уже состоялись.