Какие существуют варианты кодирования данных для передачи по сети с потерями?

Давным-давно я читал о технологии сотового кодирования для передачи данных с потерями. Насколько я помню, он дополнял данные или что-то в этом роде или предоставлял им какую-то избыточность, так что только 60% передачи должны были быть получены, чтобы получить полную информацию. Не могу вспомнить название кодировки.

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

У кого-нибудь есть идеи о подходящей схеме кодирования для целостности данных в сети с потерями? Особенно, возможно, что-то, что я могу реализовать с помощью Python, однако Python не требуется.


person 0xhughes    schedule 31.12.2013    source источник
comment
Разве сетевая библиотека, которую вы используете, не справится с этим за вас?   -  person Waleed Khan    schedule 01.01.2014
comment
Рассматривая возможность просмотра Исправление ошибок Рида-Соломона.   -  person Lasse V. Karlsen    schedule 01.01.2014
comment
@WaleedKhan Я думаю, предполагается, что передача осуществляется с потерями на ненадежном уровне (где подтверждение/повторная передача невозможна или эффективна) ... или ответом будет TCP, и вопрос никуда не денется.   -  person user2864740    schedule 01.01.2014
comment
Я сразу же вспомнил старый формат PAR2. Не уверен, что это сработает для вас или нет.   -  person Matt Johnson-Pint    schedule 01.01.2014
comment
Кажется, что большинство EC (например, Reed-Solomon) сосредоточены на повреждении внутри пакетов: с этим обращаются на аппаратном уровне.   -  person user2864740    schedule 01.01.2014
comment
Почти уверен, что аппаратный уровень не позволит 60% полных сообщений UDP. Это все или ничего. Вам придется написать свой собственный обмен сообщениями/EC и использовать UDP, чтобы убедиться, что он проходит, но я думаю, что простого awk/resend должно быть достаточно.   -  person Alan    schedule 01.01.2014
comment
@Alan Вот где я думаю, что идея избыточности (распределенной по пакетам) звучит интересно ... так что повторные передачи, хотя они все еще необходимы для 100% доставки, могут быть уменьшены.   -  person user2864740    schedule 01.01.2014
comment
@ user2864740 Интересно, да. Хотя компромисс (сложность реализации и потеря пропускной способности сети) будет действительно иметь смысл только в самых сложных сценариях, например, на поле боя или в космосе.   -  person Alan    schedule 01.01.2014
comment
Я не гуру в этой области. Я очень ценю вклад каждого в реализацию этого типа кодирования. Это то, что я хотел реализовать! en.wikipedia.org/wiki/Forward_error_correction. В частности, я вспомнил, что читал Хэмминга( 7,4)! Я не мог на всю жизнь вспомнить, что я читал.   -  person 0xhughes    schedule 01.01.2014


Ответы (1)


Еще во времена моего военного моделирования мы использовали вариант Надежный UDP. Хотя это и не формальный стандарт, существуют готовые реализации.

Идея состоит в том, чтобы добавить к пакетам подтверждение, а также возможность повторной отправки пропущенных/отброшенных пакетов.

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

person Alan    schedule 31.12.2013
comment
Изобретать заново TCP не очень весело. Также кажется, что для сетей с очень большими потерями (например, 60% потерь) было бы более эффективно использовать большую избыточность данных, чтобы свести к минимуму повторные передачи. - person user2864740; 01.01.2014
comment
RUDP не TCP. Вся идея RUDP заключается в том, что с несколькими дополнительными функциями вы можете получить надежную передачу без дополнительных накладных расходов с помощью TCP. - person Alan; 01.01.2014
comment
вздох Это не должно было восприниматься буквально. В любом случае, ни добавляет избыточность или корректирующие (кроме ack/retrans) возможности в поток. (Скорее, RTO может использовать лучшие методы при передаче, чтобы свести к минимуму обратную болтовню.) - person user2864740; 01.01.2014