Вопреки озабоченности ОП в начале, это не глупый вопрос; это на самом деле очень хороший. Большинство ответов, которые получил этот пост, в значительной степени неверны, и в этой группе это означает, что вы, должно быть, задали вопрос, который опирается на кучу действительно технических основ. Так что слава!

Распространенная ошибка

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

В современной наземной (и, в меньшей степени, орбитальной спутниковой) сетевой инфраструктуре данные, которые должны быть переданы с компьютера, подвергаются следующему процессу (на высоком уровне):

1. Поток данных идентифицируется
2. Поток данных разбивается отправителем на сегменты передачи.
3. Сегменты инкапсулируются (обертываются) внутри пакета «Уровня 3», который предоставляет всю необходимую информацию об источнике/назначении/ошибках, необходимую для того, чтобы сделать пакет маршрутизируемым через большое количество сетевых сегментов.
4. Пакеты инкапсулируются (обертываются) внутри кадра «уровня 2», который предоставляет информацию об источнике, получателе, используемом протоколе и других ошибках. Эта инкапсуляция определяет, как кадр маршрутизируется через один сегмент сети.
5. После обработки кадра пакет кодируется по проводу (или по беспроводной сети). Эта кодировка определяет, например, как отличить «1» от «0». Таким образом, «высокое напряжение = 1», «низкое напряжение = 0» и тому подобное.

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

Решение

Если отправитель и получатель известны заранее и потеря не является проблемой, то вообще нет причин заморачиваться с какой-либо инкапсуляцией. Все, что вам нужно на этом этапе, — это метод кодирования, такой как Manchester Encoding . Методы кодирования в основном определяют, что такое 0 и 1 (как по времени, так и по амплитуде), и предоставляют системам механизм, гарантирующий, что они оба находятся на одной странице.

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

Также обратите внимание

Из-за очень низких скоростей, если у вас есть какие-либо данные, которые вы хотите использовать, чтобы направить вашу информацию в конечный пункт назначения, вам лучше оставить это для протоколов более высокого уровня (несетевых). Ваша скорость передачи данных настолько тривиально низка, что будет очень мало значить, чтобы ваше оборудование на обоих концах повторно собирало полный поток данных и анализировало представленные данные, чтобы понять, куда их следует направить.

И нет, это не означает, например, смотреть на ИЗОБРАЖЕНИЕ и понимать, что означают картинки — компьютеры имеют множество языков с более высоким протоколом, которые пользователи никогда не видят. Такая информация могла бы, например, быть включена как часть пакета XML. Я бы не стал беспокоиться о технических деталях в тот момент.

Асинхронный режим передачи (ATM)

Мне нравятся оба других ответа, но я думаю, что лучшим решением, учитывая набор проблем, является банкомат. Интерфейс TCP/IP лучше всего подходит для распределенной сети, но вопрос касается двухточечной связи. «Протоколы» внутренней компьютерной шины передачи не обладают такой же надежной способностью объединять различные каналы входящей информации в один поток и контрольные суммы для обеспечения правильной доставки.

Протокол ATM был более или менее вытеснен протоколом TCP/IP, потому что последний лучше подходит для распределенных сетей, но ATM все еще используется в спутниковых сетях. На самом деле, это то самое приложение, которое наиболее применимо к вашей ситуации.

Проще говоря, если корабли в море хотят связаться с остальной частью Интернета, они будут использовать ATM для отправки пакетов TCP/IP в концентратор на суше через спутник. Спутник объединяет несколько возможных входящих ATM-потоков, поступающих с кораблей, и отправляет их обратно в концентратор, где пакеты извлекаются из ATM-потока и весело отправляются в обычный Интернет.

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

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

Я хотел немного уточнить свой ответ. ATM — это протокол уровня 2, а TCP/IP — это протокол уровня 3/4. Поэтому нет причин, по которым их нельзя использовать вместе. Я хочу сказать, что интересующий протокол лучше всего подходит для связи FLT, например, ATM, и вы можете отправлять либо IP, либо что-то еще, что может быть лучше для низкой пропускной способности.

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

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

Кроме того, @Navin; Вам нужен протокол L2, потому что у вас будет более одного перевозчика, курсирующего туда и обратно между двумя разными звездными системами. Зачем придерживаться одной несущей со скоростью 10 байт/с, если можно установить 10 несущих на такой скорости? В этом случае вам нужно, чтобы ваши пакеты были разделены между несколькими перевозчиками, а затем повторно объединены в пункте назначения. Банкомат так делает. Вы по-прежнему хотите, чтобы носитель L3 рассредоточил ваше сообщение по потенциально миллионам сетевых узлов в пункте назначения.

Кроме того, если вы передаете таким образом, 50-байтовый кадр ATM передается на одном носителе за 5 секунд; Ethernet-кадр размером 9000 байт за 15 минут. Это означает, что 1000-байтовое сообщение, разделенное на 20 кадров, может быть передано за 10 секунд на 10 различных носителях с ATM, а 1000-байтовое сообщение в одном 1000-байтовом кадре будет передано за 100 секунд. Конечно, вы видите преимущество меньшего размера кадра в приложении с низкой пропускной способностью.

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

Наиболее важным ограничением здесь является мучительно низкая скорость передачи. Вы бы свели к минимуму количество накладных расходов, не связанных с сообщениями (или полностью устранили бы их) и использовали максимально возможное сжатие. Если вам нужно отправить информацию о маршрутизации или доставке, вы, вероятно, воспользуетесь хэш-таблицей и отправите хэш пункта назначения вместо полной информации о доставке. В комментарии ниже упоминается TDMA, что является интересной мыслью. Учитывая максимальную пропускную способность запутанных фотонов (или что-то еще), может иметь смысл объединить несколько каналов вместе.

Если это от А до Б без посредников и практически гарантировано отсутствие потери/повреждения данных или отключения, вы в основном имеете дело с тем же мышлением связи между внутренними компьютерными компонентами , только намного, намного, намного медленнее. Протокола сетевой передачи между ЦП и дисковым накопителем нет, потому что он вам просто не нужен.

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

Вы захотите сосредоточиться на сжатии данных (а не на протоколах передачи) и на разметке, которая помогает уменьшить количество метаданных. Концепция MessagePack кажется вам вполне подходящей:

MessagePack — это эффективный формат двоичной сериализации. Он позволяет обмениваться данными между несколькими языками, такими как JSON. Но он быстрее и меньше. Небольшие целые числа кодируются в один байт, а для типичных коротких строк требуется только один дополнительный байт в дополнение к самим строкам.

Вы не захотите останавливаться на достигнутом, но подумайте об этом. Вы также можете повысить эффективность, если знаете, какой трафик вы передаете через это соединение, а ЦП на принимающей стороне могут экстраполировать базовый уровень, подобно векторной графике (несколько определений используются для расчета более широкой концепции)

Лучшим решением будет проприетарный формат, так как вам не нужна совместимость, вам нужна только эффективность.

«Пакеты данных» - это концепция, применяемая к сети, когда данные должны маршрутизироваться вокруг и через несколько устройств, чтобы достичь места назначения; например, сеть или Интернет. Если это просто двухточечная связь, то это похоже на последовательную связь (например, старые школьные принтеры / клавиатуры), и ее не нужно пакетировать.

Любой современный протокол может иметь дело с низкой скоростью передачи, если он настроен для него , поэтому несколько байтов в секунду могут работать для TCP / IP или UDP, если «время жизни» достаточно велико; ваши потребности будут определять конкретный протокол.

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

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

Приложение для «TCP-IP/UDP с потерями»:

В протокол TCP встроено нечто, называемое «гарантированной доставкой», что означает, что каждый отправленный пакет будет доставлен к месту назначения… в конце концов. UDP не дает такой гарантии. Потеря пакетов происходит не только при передаче, хотя это обычное явление; маршрутизаторы могут выйти из строя или переполниться, а пакет, который они удерживали для передачи, может быть потерян, или случайный фотон может попасть в микрочип, в котором он хранится, и немного перевернуться, повредив данные. Коррупция и потери происходят не только при передаче.

Часть «гарантированная доставка» означает, что если пакет, который имеет индивидуальный номер (часть служебных данных, которые эти пакеты берут с точки зрения данных), отсутствует, получатель вернется к источнику и запросит повторную отправку пакета. . Это хорошо, если вы ДОЛЖНЫ иметь все данные полностью. Это плохо влияет на пропускную способность сети.

UDP, протоколы без установления соединения или «без гарантии» — это то, что вы используете при потоковой передаче данных (например, YouTube). Это убило бы сеть, если бы вам пришлось взять каждый бит этого последнего кадра анимации, который вы пропустили, и в этот момент это все равно не имеет значения. На самом деле вы не теряете так много пакетов, и это намного проще с точки зрения пропускной способности для передачи данных.

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

Для таких низких скоростей передачи данных я бы рассмотрел методы старого последовательного стиля (COM-порт) и пошел дальше и ограничил их связью между одним компьютером и одним компьютером (даже если было доступно несколько разговоров), и если вам нужна сеть, просто используйте стандартную сеть между этими компьютерами FTL.

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

Нет, это невозможно на фундаментальном уровне.

Протокол — это набор правил, определяющих, как одна вещь взаимодействует с другой в стандартизированном виде. Это могут быть две части приложения на одном компьютере (например, одна часть моего приложения отправляет данные другой части, сохраняя JSON в файл), или это могут быть две совершенно разные машины в разных уголках земного шара (для например, я здесь, в Великобритании, могу отправить электронное письмо своим друзьям в Новой Зеландии, потому что кто-то определил POP и SMTP — некоторые протоколы электронной почты).

По сути, вы не можете вступать в какую-либо форму общения с чем-либо, если у вас нет определенного протокола. Это не обязательно должен быть записанный, пронумерованный RFC, одобренный IETF, задокументированный протокол MDN, но это все же протокол.

Итак: нет , вы должны определить сетевой протокол, прежде чем ваши компьютеры смогут общаться друг с другом.

Предустановленный протокол сжатых данных — это то, что вам нужно. Предустановленное сжатие позволяет отправителю выбирать протокол с фиксированным словарем на основе намерения. Например, если вы хотите перевести текст, лучше всего использовать низкое количество битов для часто повторяющегося текста. Некоторые слова также могут быть удалены автоматически. В большинстве случаев пропуск «the» не вызовет никаких проблем, но сэкономит немного. Примените Хаффмана или подобное кодирование к большому количеству текстовых документов, чтобы получить словарь. Поскольку словари большие, лучше их не пересылать. Нечто подобное можно использовать и для других протоколов.

Ответ на этот вопрос на 100% зависит от трафика, проходящего по сети. Есть веская причина, по которой у нас сегодня так много протоколов. Каждый хорошо работает в своей нише. Если вам нужна синхронная связь, такие протоколы, как ATM, имеют значение. Если ваша система FTL имеет поведение, аналогичное оптоволоконному кабелю, SONET может быть полезен. Если ваша система является широковещательной, ни один из них не будет работать вообще, и вы захотите использовать что-то вроде 802.11b или, возможно, один из других беспроводных протоколов с более низкой пропускной способностью, таких как Zigbee.

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

Большим вопросом может быть военное или гражданское использование. Если ваша система используется только военными, такие протоколы, как LINK-16, разрабатывались десятилетиями, чтобы хорошо работать в средах с ограниченной пропускной способностью. Между тем, для марсохода Mars Reconnaissance Rover были выбраны протоколы, построенные на основе турбокодов, потому что они наилучшим образом использовали ограниченную доступную полосу пропускания, и мы могли сэкономить ресурсы, необходимые для декодирования турбокодов.

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

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

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

Опять же, это всего лишь один подход для определенного типа сценария.

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

Это абсолютно отличается от первых дней Интернета, и вот почему.

К тому времени, когда был изобретен Интернет, скорость передачи данных уже была намного выше вашей спецификации, а процессоры были намного медленнее, чем сегодня. Вы описываете ситуацию, в которой отношение (вычислительная мощность)/(пропускная способность) значительно больше, чем когда-либо прежде.

Таким образом, хотя, безусловно , можно было бы использовать (m) любые уже изобретенные протоколы, регулируя тайм-ауты, в этой ситуации это было бы не так. Вместо этого будут изобретены новые протоколы, оптимизированные для этой конкретной ситуации.

Протокол FTL v1 будет иметь краткую структуру кадра, не отличающуюся от HDLC или Ethernet II. В некоторых ответах упоминается ATM, что хорошо, за исключением того, что задержка оценивается больше, чем битовая эффективность, что, я подозреваю, может быть настроено. Непосредственно поверх этого , без дополнительных слоев, будут поступать сильно сжатые данные протокола приложения. Во-первых, короткие и дорогие военные/финансовые сообщения с использованием, мало чем отличающимся от старого телеграфа. Затем новости и личные сообщения.

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

Если нет, то что делает его невозможным?

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

Я хотел бы ответить на вопрос комментария @JohnFeltz:

Есть ли какие-либо ограничения на количество таких устройств, которые вы можете построить и разместить рядом друг с другом? Если я могу запускать 100 000 из них параллельно, мне просто нужен обратный мультиплексор, чтобы получить пропускную способность 5 Мбит.

К сожалению, если поставить два или более таких устройства рядом друг с другом, они будут мешать.

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

Минимальное безопасное расстояние между трансиверами зависит от вас, просто будьте последовательны в этом вопросе. Это также может быть проблемой только на стороне отправки или получения.

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

поскольку передача является «мгновенной», вы можете кодировать информацию не в байтах, которые вы отправляете (как в обычных сетевых протоколах), а в количестве времени между битами. поэтому, если вы хотите отправить число 255, вы не будете использовать целый байт (8 бит), как в обычном интернет-пакете. скорее, вы должны отправить 1 бит ровно через 255 наносекунд после предыдущего бита. ваша общая реализованная пропускная способность будет ограничена только точностью ваших часов и желаемой задержкой. например, вы можете сказать: «Я буду отправлять 1 бит каждые 10 миллионов наносекунд. Значение, которое представляет этот бит, равно количеству наносекунд с момента отправки предыдущего бита». этот протокол даст вам максимальную одностороннюю задержку 10 миллисекунд и минимальную скорость передачи данных чуть менее 300 байт в секунду. удвоение максимальной задержки также удваивает эффективную скорость передачи. более сложные протоколы могут быть построены поверх этого, чтобы согласовать скорость передачи на лету, или использовать кодирование с коротким кодом, чтобы максимизировать пропускную способность, гарантируя, что наиболее распространенные блоки данных имеют много начальных нулей (поэтому биты отправляются Быстрее). вы также можете ограничить максимальный размер блока, чтобы обеспечить синхронизацию часов в зависимости от относительного дрейфа часов.

Я бы использовал ссылку напрямую как 7-битную тупую последовательную линию и воскресил бы древние протоколы UUCP. Эти вещи на самом деле имеют меньше накладных расходов, чем современные, и лучше спроектированы для работы с глупо медленным временем передачи. Единственное существенное изменение — замена uuencode одним из вариантов base85.

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

Я предложу другую точку зрения. Ссылка не будет в сети в обычном смысле. В этом не было бы смысла.

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

Во-вторых, из-за низкой пропускной способности Link можно рассматривать скорее как телеграф, чем что-то в современной компьютерной сети. Телеграф (за исключением необходимости в повторителях) обеспечивает скорость, сравнимую со скоростью света, благодаря волшебству медной проволоки. Вы закрываете телеграфный ключ, другой конец идет «щелчок». Конечно, электромагнит медленный, но человек, управляющий сигналами, еще медленнее. Это эффективно мгновенно. Рассмотрим подводный кабель между США и Великобританией. В каждой стране может быть развитая телеграфная сеть, и за небольшую плату Салли из Флориды может рассказать бабушке в штате Мэн о своем новом коте, но какие сообщения будут рассматриваться для связи по подводному кабелю? Вероятно, это не кошачья телеграмма. Вместо этого он, вероятно, будет использоваться для информации, относящейся к политике и высоким финансам.

Конечно, в 2016 году у нас не будет пары человек, прослушивающих сообщения по нашей межзвездной связи. Но это все еще как телеграф. У вас будет компьютер на каждом конце Линка. Отправитель читал из буфера сообщений (закодированных, а затем максимально сжатых) и вытаскивал их. Машина на другом конце будет получать, распаковывать и декодировать.

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

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

Но какие именно сообщения будут отправлены через The Link?

Скажем, досветовой колониальный корабль через 300 лет достиг пункта назначения и начинает строить свой новый дом. Линк настроен.

Первые отправленные сообщения выглядят примерно так:

Здравствуй, Земля, мы благополучно прибыли, и все идет по плану.

(Это будет несколько символов, возможно, из-за кодировки), и ответил,

Чертовски приятно тебя слышать, cheerio!

(еще 2 или 3 символа)

Какое отношение имеет что-либо на Земле к колонии после любезностей и диагностики? Помощь будет через 300 лет, если не считать каких-то шокирующих новых открытий. Политика прибывает и ослабевает на протяжении столетий. Страны меняются. Будет ли существовать страна, отправившая корабль? Будет ли узнаваем Мировой Порядок, отправивший корабль? Какое отношение колония будет иметь к людям Земли, отстоящим на 15 поколений от тех отважных смельчаков, которые поднялись на борт колониального корабля?

Может случиться так, что изображение кошки в формате jpeg действительно может быть столь же полезным, как и любое другое сообщение.

РЕДАКТИРОВАТЬ. Учитывая отсутствие какой-либо важности между повседневной жизнью людей на Земле и колонистов, может показаться, что Связь в этом случае обычно используется для низкоуровневой научной коммуникации. Наблюдения за звездой, вращающейся по орбите, и тому подобное. Я не знаю, почему это было бы особенно актуально, но это лучше, чем мертвый воздух, если предположить, что Link не изнашивается от использования.

Более вероятное использование The Link вообще не задействует людей. Вместо этого корабль, на котором находится Линк, полностью роботизирован. Эти корабли по счету отправляются в разные звездные системы. Они молча и украдкой наблюдают за сигналами других рас. Данные, отправляемые обратно очень медленно, предназначены для того, чтобы люди на Земле могли заглянуть в технологии инопланетян и, надеюсь, их намерения. Зловещий, правда.

Рассмотрим это: Луки 17:11 или это: Коран 2:4-5, издание Oxford World's Classics, или даже это: «правило 5». Все они являются ссылками на более расширенные фразы или тексты. Ограничивающим фактором в этом типе кодирования является доступность ссылок как для отправителя, так и для получателя. Английский — очень избыточный язык, известны гораздо более эффективные языки. Типичный выпускник колледжа имеет словарный запас менее 20 000 слов или семейств слов. Один байт позволяет закодировать 65 тысяч слов. Таким образом, от 5 до 10 байт в секунду быстрее, чем речь, и не будут ограничивать словесную (в отличие от визуальной) передачу данных.

Я немного сторонник MeeSeeks.

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

"человечеству каким-то образом удается мгновенно передавать данные"

Этот элемент сверхсветовых сетей вашего мира, в частности, делает многое из того, что определяет современные соглашения о передаче данных (и, соответственно, то, как мы их измеряем), фактически бесполезными для вас.

С вашей технологией существует нулевая задержка. Другими словами, когда я что-то отправляю, другая сторона получает это ТОЧНО в то же время, когда я это отправляю. Не раньше, не наносекунды позже, а в то же самое время в каком-то отдаленном месте. Если разрешить эту ситуацию в современных сетях, ваша пропускная способность данных будет зашкаливающей. По сути, через эту сеть можно передавать бесконечное количество информации, поскольку теоретически ограничений нет. По крайней мере пока нет...

«но сама скорость низкая — скажем, возможность отправлять от 5 до 10 байтов (от 10 до 20 шестнадцатеричных кодов) в секунду».

Здесь ваша ситуация становится немного уникальной . Мысленный эксперимент, если хотите:

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

Основная загадка здесь заключается в том, что если данные отправляются мгновенно, то измерение пропускной способности данных за определенный период времени бессмысленно. И если измерения пропускной способности неприменимы, то как и/или почему ваша технология настолько ограничена?

Мой ответ:

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

Например:

• Передача данных является мгновенной из-за {вставить здесь предпочтительную теоретическую концепцию мгновенной передачи информации, т.е. квантовая запутанность}
• Технология ограничена состоянием включения и выключения (аналогично двоичным системам), предоставляя вам ограничение на данные, которые могут быть переданы, а также предоставляя обоснование для разрешения ограничения объема данных, которые могут быть " отправлено» в течение заданного периода времени, несмотря на то, что «отправка» этих данных происходит мгновенно. Объяснение: сами данные находятся в обоих местах одновременно, но состояние системы не может быть и ВКЛ и ВЫКЛ одновременно. Это означает, что отставание в передаче информации связано не с задержкой или пропускной способностью, которые, как мы обсуждали, не обязательно применимы, а вместо этого ограничены функциональными ограничениями существующей системы.
• Необязательно: системы являются мужскими и женскими, связь возможна только между парными системами. Нет реальной причины, мне просто нравится это как дополнительное ограничение, поскольку контекст вашего вопроса на самом деле сводится к следующему: «Если данные могут быть переданы мгновенно, как мне рационально ограничить технологию для жителей моего мира?»

Вывод: как и со всем, что связано с воображением, делайте со всем этим, что хотите. Потому что это твой мир. И спасибо, мне, наверное, было веселее писать, чем вам читать.

Какого рода информацию вы хотите передать? Если это просто текст, то реализуйте что-то вроде Вавилонской библиотеки на обоих концах. Затем вам просто нужно передать позиционную информацию о желаемом сообщении.

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

Уточнение: то, что я имел в виду, ссылаясь на библиотеку babel, - это своего рода таблица поиска. Это сообщение было бы создано по определенной причине. Я предполагаю, что это для межзвездной связи, а не для отправки чего-то на несколько миль. Следовательно, должна быть какая-то форма кодирования, чтобы гарантировать, что цель сообщения будет отправлена ​​без необходимости отправки буквальной информации. Зачем отправлять 30 000 байт, когда я могу отправить 10-20 таких точек в таблицу поиска, которая передает все сообщение.

Я собирался опубликовать то же наблюдение, что и Джеймс Тернер, поэтому вместо этого я проголосовал за его ответ и подумал о возражении (которое также может объяснить как эффект помех, так и медлительность передачи).

Если бы передача была безупречной и мгновенной, то, если бы можно было определить время с точностью до наносекунды, я мог бы согласиться на отправку сигнала каждые 1,048576 мс (максимум) с задержкой 0 нс, что означает 1111111111, и задержкой 1048575 нс. что означает 0000000000. Десять бит каждую миллисекунду, и мы уже находимся в диапазоне 10 кбит/с (и, в среднем, лучше).

Итак, я утверждаю, что хотя передача сигнала происходит мгновенно, разрешение сигнала является вероятностным процессом. Проанализируйте окно в 1 нс, и шансы отличить «сигнал» или «отсутствие такового» равны нулю. Чтобы достичь уверенности в 99%, вам нужно проанализировать передачу за целую секунду.

Поэтому, конечно же, инженеры пришли к компромиссу и, объединив более короткие времена со схемами сжатия и исправления ошибок, увеличили пропускную способность до 40-80 бит/с.

Если мы разместим два передатчика рядом, примерно в 50% случаев один будет передавать 0, а другой - 1, что увеличит частоту ошибок на приемном конце, заставляя снизить скорость; поэтому масштабирование устройства ничего не дает.

С другой стороны, на каком расстоянии должны находиться передатчики друг от друга, чтобы они перестали заметно мешать? Скажем, это 500 метров; в космосе можно построить огромную коммуникационную сеть, каркасный куб размером в десять километров, состоящий из 500-метровых «проводов», удерживающих около восьми тысяч передатчиков, координируемых посредством обычной досветовой сигнализации. Планеты могут общаться между собой с помощью наземных сетей; корабли были бы гораздо более ограниченными. Последствия кажутся интересными.

Это обсуждение кажется очень узким – я бы посмотрел на вопрос несколько шагов назад.

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

Если у вас есть сверхсветовая связь, но путешествие происходит медленнее скорости света, то становится интереснее. На протяжении всей истории люди могли путешествовать со скоростью информации; в последнее время у нас мгновенная связь, но и поездка куда-то занимает не более суток, если вы спешите.

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

Предположим, люди Земли были одержимы версией Шекспира Омикрона Персея VIII. Наперстки доставляли все пьесы, фильмы и интервью, которые Земля могла потреблять, но они прибывали намного позже смерти Космического Шекспира. Состоятельный землянин мог арендовать 15 минут сверхсветового радио для живого чата, но лучшее, что они могли сделать, это поболтать с внуками Спейсспир. Или вы можете пообщаться с живой омикронской знаменитостью, но только ваши внуки увидят, чем они знамениты.

С экономической точки зрения трудно представить, что связь в режиме реального времени играет большую роль в культурной торговле. Люди могут платить за просмотр фильмов из Космического Голливуда, но они будут просто потреблять фильмы 200-летней давности, которые приходят наперстком, и относиться к 200-летней версии Космического Голливуда как к «настоящему дню».

Сверхсветовое радио годится только для спойлеров. Что не очень важно для торговли, но, очевидно, было бы полезно для предупреждения о массированных флотах вторжения / сверхновых / и т. д. На самом деле, эта услуга может быть важной гарантией для торговли; если вы не оплатите счет Space HBO за шоу, которые они отправили 200 лет назад, они не предупредят вас об этом астероиде в следующем марте.

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

NB

Некоторые из приведенных выше ответов касаются идеи кодирования огромных объемов данных с использованием гигантских словарей; эта идея имеет долгую историю, по крайней мере, с 17-го века вплоть до 1950-х годов, когда она была демонтирована в ходе создания теории информации.

Идея состоит в том, что вы выписываете все возможные книги, расставляете их по порядку, а затем просто ссылаетесь на них по номерам. Проблема в том, что книга — это уже просто последовательность байтов, т. е. длинное число, и присвоение числа каждой книге означает, что число будет таким же длинным, как и сама книга; на самом деле это будет одна и та же последовательность байтов.

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

Практические алгоритмы сжатия используют этот вид «словарного кодирования», но он гораздо более простой. Хитрость на самом деле состоит в том, чтобы исключить из словаря как можно больше, чтобы только очень распространенные строки заменялись очень короткими кодами, поэтому, например, the cat sat on the matсокращается до 1 c2 s2 on 1 m2. Если вы использовали заранее составленный словарь, в который вошли все известные слова, вы можете сделать сообщение длиннее ( 23 4954 3430 109 23 908078).