Легкие двухточечные протоколы связи

Почему вы не собираетесь использовать существующий протокол?

AFAICT, существует множество уже используемых протоколов, разработанных в течение многих лет, которые решили многие проблемы на основе исследований и опыта. Поэтому я бы использовал что-то, что работает и было отлажено, если вы не проводите исследования. Если это исследование, вам нужно описать вариант использования в целом, а не только некоторые его особенности.

Старые протоколы могут выжить просто потому, что технология на спутниках не только должна работать, но и должна быть протестирована, охарактеризована и «сертифицирована» для работы в космосе. Это дорогой, специализированный и медленный процесс. Таким образом, экономия средств и времени за счет использования того, что уже известно как надежно работающее, имеет даже больше смысла, чем обычные инженерные проекты, связанные с Землей.

Это коммерческий, исследовательский или любительский проект?

Я знаю, что любители построили эквивалент глобальной сети наземных станций, которые переключаются на следующую станцию ​​по мере движения спутника по орбите (немного похоже на сеть наземных станций, которая есть у НАСА или других космических агентств, но с использованием оборудования, доступного для части суток [владельцы оборудования тоже используют его сами, в своих целях] увлеченными любителями). Вы пытаетесь решить эту проблему?

В этом случае это может быть не одно соединение «точка-точка». Это могут быть несколько наземных станций, каждая из которых пытается связаться с одним и тем же спутником. Или это могут быть несколько наземных станций, пытающихся связаться с несколькими спутниками.

Если это любительский проект, свяжитесь с группами напрямую. Британская группа любительских спутников дружна, и ее члены сотрудничали с коллегами из AMSAT-NL в создании программного обеспечения и сети для международной сети наземных станций на основе любительского радио. Они также построили недорогое радиооборудование, используемое для отслеживания их FUNCube CubeSat.

Одна из первых пакетных беспроводных сетей ALOHnet повлияла на Ethernet и Inmarsat. Так, например, некоторые удачные идеи могут быть сохранены из этой работы. Пока он работает, не имеет существенных недостатков, доказал свою работоспособность в космосе и имеет доступное аппаратное обеспечение, которое протестировано и «сертифицировано» для использования в космосе, какая мотивация для изменений?

Редактировать:

Есть несколько статей о высокой задержке и даже вопрос о переполнении стека. Сеть с чрезвычайно высокой задержкой , которая может вдохновить.

Есть старые протоколы с отлаженными реализациями. У них есть то преимущество, что они настолько старые, что машины, на которых они работали, имеют мало ресурсов, и поэтому могут хорошо подходить для вашего приложения.

Например, протокол Кермита . В этой статье в Википедии говорится: «Программное обеспечение Kermit использовалось для решения самых разных задач, от простых студенческих заданий до решения проблем совместимости на борту Международной космической станции». Так что у него есть полезная родословная :-)

Он поддерживает « протокол скользящего окна », который поддерживает выборочную повторную передачу. Это должно помочь восстановиться после ошибок и выполнить повторную сборку поврежденных потоков данных.

Это с открытым исходным кодом и имеет реализации C. Таким образом, вы можете получить исходный код и портировать его. Kermit работал на машинах с адресным пространством менее 64 КБ. Так что это может подойти для вашего оборудования.

Даже если Kermit не подходит, я бы порекомендовал взглянуть на старые (около 1980-х годов) протоколы и реализации, потому что машинные ограничения могут быть сопоставимы с ограничениями вашего оборудования в полете; даже если ваше оборудование менее ограничено, чем в 1980-х годах, ваш бюджет мощности может помочь реализации протокола с низким уровнем ресурсов.

У вас ДЕЙСТВИТЕЛЬНО есть сеть, признаете вы это или нет. Ваш кубсат будет не единственным на орбите и вряд ли будет единственным на выделенном вам канале. Каким-то образом сообщения вашего кубсата должны быть отличимы от других, а полагаться на эфемеридные данные (ваши должны быть над головой о... сейчас...) небезопасно.

То же самое с наземной станцией. Особенно, если вы хотите обрабатывать большие объемы данных, вам понадобится более одной наземной станции. Кубсаты часто используют сеть любительских наземных станций, и если какой-нибудь парень в Вумере или Якутске подобрал пакеты, которые вы потеряли из-за замирания, отлично! Но вы, вероятно, хотите, чтобы ваша собственная наземная станция управляла спутником, поэтому вам нужно идентифицировать наземные станции, а также спутники.

Вы можете решить все эти проблемы, создав свой собственный протокол... с собственной системой адресации... но повторное использование одного из них, скорее всего, потребует меньше работы и улучшит сотрудничество с другими.

Я думаю, вам понадобится больше, чем PPP - возможно, TCP (без IP) был бы хорошим кандидатом.

тфтп? - маленький, легкий и известный.

(Простые) методы сжатия могут сэкономить достаточную длину пакета, чтобы сделать IP возможным, и позволить вам перераспределить рабочую силу на более интересные части проекта.

Вернитесь к удалению IP-адресов после того, как протокол, устройство и приложение будут работать и полностью протестированы с использованием существующих стеков.