Contrariamente a la preocupación del OP al principio, esta no es una pregunta tonta; en realidad es muy bueno. La mayoría de las respuestas que ha recibido esta publicación son bastante incorrectas, y en este grupo eso significa que debe haber hecho una pregunta que se basa en un montón de fundamentos realmente técnicos. ¡Así que felicitaciones!

El error común

El error común entre las respuestas hasta ahora es que hablan de lo que comúnmente se conoce como protocolos de "capa 3" , o incluso protocolos de "capa 2" adecuados . Para entender la respuesta, necesitamos entender por qué esta es la forma incorrecta de ver el problema.

En la infraestructura de red terrestre (y, en menor medida, satélite orbital) de hoy en día, los datos que se van a transmitir desde una computadora pasan por el siguiente proceso (en un nivel alto):

1. El flujo de datos se identifica
2. El flujo de datos se divide en segmentos de transmisión por el remitente
3. Los segmentos están encapsulados (envueltos) dentro de un paquete de "Capa 3", que proporciona toda la información de fuente/destino/errata necesaria para hacer que el paquete sea enrutable a través de una gran cantidad de segmentos de red.
4. Los paquetes se encapsulan (envuelven) dentro de un marco de "Capa 2", que proporciona información sobre el origen, el destino, el protocolo en uso y otras erratas. Esta encapsulación define cómo se enruta la trama a través de un único segmento de red.
5. Una vez que se resuelve el encuadre, el paquete se codifica en el cable (o de forma inalámbrica). Esta codificación define, por ejemplo, cómo distinguir un “1” de un “0”. Entonces, indicando "alto voltaje = 1", "bajo voltaje = 0" y similares.

El problema contextual aquí que anula este método de operación es que está hablando de flujos de datos muy BAJOS con presumiblemente relativamente pocos objetivos comunicándose. De acuerdo con su premisa, también está hablando de un sistema que se sabe que no tiene pérdidas donde la fuente y el destino ya se conocen con anticipación. Esas no son las expectativas y situaciones a las que se adaptaron los protocolos a los que la mayoría de las personas están expuestas a diario.

La solución

Si el remitente y el destinatario se conocen con anticipación y la pérdida no es un problema, no hay ninguna razón para preocuparse por la encapsulación. Todo lo que necesita en ese momento es un método de codificación, como Codificación Manchester . Los métodos de codificación definen básicamente qué es un 0 y un 1 (tanto en tiempo como en amplitud) y proporcionan a los sistemas un mecanismo para garantizar que ambos estén en la misma página.

Para simplificar las cosas, probablemente solo usaría la codificación Manchester, como se usa en muchas de las conexiones por cable de hoy. Sí, hay otros tipos de codificación que pueden funcionar mejor para características de transmisión específicas, pero dado su sistema de entrega de portal "instantánea/perfecta", creo que podemos dibujar un análogo bastante bueno para que ese portal sea equivalente a solo un segmento infinitamente pequeño de una conexión de red por cable.

También tenga en cuenta

Debido a las velocidades muy lentas involucradas, si tiene datos que desea usar para ayudar a enrutar su información a su destino final, sería mejor dejar eso a protocolos de nivel superior (fuera de la red). Su velocidad de transferencia de datos es tan trivialmente lenta que significaría muy poco tener su equipo en ambos extremos para volver a ensamblar el flujo de datos completo y analizar los datos presentados para comprender hacia dónde debe dirigirse.

Y no, eso no significa mirar una IMAGEN, por ejemplo, y comprender lo que significan las imágenes: las computadoras tienen muchos lenguajes de alto protocolo que los usuarios nunca ven. Dicha información podría, por ejemplo, incluirse como parte de un paquete XML. Sin embargo, no me preocuparía por los detalles técnicos en ese momento.

Modo de transferencia asincrónica (ATM)

Me gustan las otras dos respuestas, pero creo que una mejor solución, dado el conjunto de problemas, es ATM. Una interfaz TCP/IP es mejor para una red distribuida, pero la pregunta especificaba la comunicación punto a punto. Los 'protocolos' de bus de transferencia de computadora internos no tienen la misma capacidad robusta para fusionar diferentes canales de información entrante en un solo flujo, y las sumas de verificación para garantizar la entrega correcta.

ATM fue más o menos eliminado en el uso común por TCP/IP porque este último es mejor para redes distribuidas, pero ATM todavía se usa en redes satelitales. De hecho, esta es la aplicación que más se aplica a su situación.

Para explicarlo de manera simple, si un barco en el mar quiere comunicarse con el resto de Internet, utilizará ATM para enviar paquetes TCP/IP a un centro en tierra a través de un satélite. El satélite fusiona múltiples posibles flujos de cajeros automáticos entrantes que provienen de los barcos y los envía de regreso al centro, donde los paquetes se extraen del flujo de cajeros automáticos y se envían alegremente a través de Internet normal.

Hay mucho más que eso, si desea leer en Wikipedia, o la especificación . Pero me imagino que esta es la capacidad que imagina para la comunicación FTL.

Editar:

Quería aclarar un poco mi respuesta. ATM es un protocolo de capa 2 y TCP/IP es un protocolo de capa 3/4. Así que no hay razón para que no se puedan usar juntos. Mi punto es el protocolo de interés que mejor se adapta a la comunicación FLT, como ATM, y puede enviar IP o cualquier otra cosa que podría ser mejor para un ancho de banda bajo.

Edit2:

Más respuestas a las críticas. Edité la primera sección sobre protocolos de bus para reflejar lo que no pueden hacer y creo que deben hacer.

Además, @Navin; Desea un protocolo L2 porque tendrá más de un operador yendo y viniendo entre dos sistemas estelares diferentes. ¿Por qué quedarse con un operador a 10 bytes/seg cuando podría instalar 10 operadores a esa velocidad? En este caso, necesita que sus paquetes se dividan entre varios operadores y luego se vuelvan a fusionar en el destino. Cajero automático hace eso. Aún querrá que un operador L3 disperse su mensaje a través de millones de nodos de red en el destino.

Además, si transfiere de esta manera, una trama ATM de 50 bytes se transfiere en un operador en 5 segundos; una trama ethernet de 9000 bytes en 15 minutos. Eso significa que un mensaje de 1000 bytes dividido en 20 marcos se puede transmitir en 10 segundos en 10 operadores diferentes con ATM, mientras que un mensaje de 1000 bytes en un marco de 1000 bytes se transmitirá en 100 segundos. Seguramente puede ver la ventaja de un tamaño de marco más pequeño para una aplicación de bajo ancho de banda.

Esta es una comunicación punto a punto, por lo que nunca se molestará con el
enrutamiento, el tiempo y la sobrecarga de la suma de verificación de los paquetes de red. Si la transmisión de ftl está sujeta a pérdida o corrupción, es posible que desee una corrección de errores y una noción de la orientación de la conexión. En lugar de reutilizar una tecnología existente, debe ajustar su protocolo para el perfil real de corrupción y pérdida de su nuevo medio.

La limitación más importante aquí es la velocidad de transmisión insoportablemente lenta. Minimizaría la cantidad de sobrecarga que no es de mensajes (o la eliminaría por completo) y usaría la mejor compresión que pueda. Si necesita enviar información de enrutamiento o entrega, probablemente use una tabla hash y envíe el hash del destino en lugar de la información de entrega completa. Un comentario a continuación menciona TDMA, que es un pensamiento interesante. Dado el ancho de banda máximo de los fotones entrelazados (o lo que sea), podría tener sentido agrupar varios canales.

Si es de A a B sin intermediarios y virtualmente garantizado sin pérdida/corrupción de datos o desconexión, básicamente está tratando con la misma mentalidad de comunicación entre los componentes internos de la computadora , solo que mucho, mucho, mucho más lento. No existe un protocolo de transferencia de red entre la CPU y la unidad de disco, porque simplemente no lo necesita.

Siendo que esta sociedad tiene esta tecnología, asumo que están en nuestro nivel de poder de cómputo general o (más realista) más allá. Esto significa que con esta velocidad lenta, el cuello de botella dolorosamente obviamente es la transferencia, no las computadoras de ambos lados.

Querrá centrarse en la compresión de datos (no en los protocolos de transferencia) y en un marcado que ayude a reducir los metadatos. El concepto detrás de MessagePack parece muy adecuado para ti:

MessagePack es un formato de serialización binaria eficiente. Le permite intercambiar datos entre múltiples idiomas como JSON. Pero es más rápido y más pequeño. Los números enteros pequeños se codifican en un solo byte, y las cadenas cortas típicas requieren solo un byte adicional además de las propias cadenas.

No querrá detenerse allí, pero piense de esta manera. También podría expandir la eficiencia si sabe qué tipo de tráfico está enviando a través de esta conexión, y las CPU en el lado receptor pueden extrapolar desde la línea de base, similar a los gráficos vectoriales (se usan algunas definiciones para calcular el concepto más grande)

Su mejor solución será un formato propietario, ya que no necesita compatibilidad, solo necesita eficiencia.

Los "paquetes de datos" son un concepto aplicado a las redes, cuando los datos deben enrutarse alrededor ya través de múltiples dispositivos para llegar a su destino; por ejemplo, una red o Internet. Si es solo una comunicación punto a punto, entonces es como un enlace serial (como las impresoras/teclados de la vieja escuela) y no necesita ser empaquetado.

Cualquier protocolo moderno puede lidiar con velocidades de transmisión lentas cuando está configurado para ello , por lo que unos pocos bytes por segundo son viables para TCP/IP o UDP siempre que el "tiempo de vida" sea lo suficientemente alto; sus necesidades determinarán el protocolo específico.

TCP/IP y UDP son apropiados para redes de malla grande porque contienen toda la información de direccionamiento necesaria para llegar de cualquier lugar a cualquier lugar cuando hay una gran cantidad de destinos y enrutadores. Si se trata de una red pequeña de solo unas pocas computadoras, existen protocolos más eficientes.

Para una conexión directa, una computadora hablando solo con otra computadora, un paquete no es óptimo, porque parte de la transmisión será absorbida por la información de la dirección. Para punto a punto se puede asumir la dirección.

Anexo para "TCP-IP/UDP con pérdidas":

El protocolo TCP tiene algo incorporado llamado "entrega garantizada", lo que significa que cada paquete enviado llegará a su destino... eventualmente. UDP no ofrece esta garantía. La pérdida de paquetes no ocurre solo en la transmisión, aunque es común (más o menos); los enrutadores pueden fallar o desbordarse y el paquete que estaban reteniendo para transmitir puede perderse, o un fotón perdido puede golpear el microchip en el que está almacenado y cambiar un poco, corrompiendo los datos. La corrupción y la pérdida no ocurren sólo en la transmisión.

La parte de "entrega garantizada" significa que, si falta un paquete, que están numerados individualmente (parte de la sobrecarga que estos paquetes tienen en términos de datos), el destinatario volverá a la fuente y solicitará que el paquete se envíe nuevamente. . Esto es bueno si DEBE tener todos los datos, completamente. Esto es malo para el ancho de banda de la red.

Los protocolos de estilo UDP, sin conexión o "sin garantía" son los que usa cuando transmite datos (por ejemplo, YouTube). Mataría a la red si tuviera que ir a capturar cada parte del último cuadro de animación que se perdió, y en ese momento no importa de todos modos. En realidad, tampoco pierde tantos paquetes de esta manera, y es mucho más fácil en el lado del ancho de banda para transmitir datos.

Sin embargo, para estos dos protocolos listos para usar, se trata de más de 60 bytes solo para la información del encabezado en cada paquete. Esa podría ser una parte significativa del tiempo que se toma para una simple conversación de punto a punto, especialmente cuando los datos se dividen en miles de paquetes.

Para tasas de datos tan bajas, buscaría técnicas de estilo serial antiguo (puerto COM), y seguiría adelante y restringiría la comunicación de una computadora a una computadora (incluso si estuviera disponible la comunicación múltiple), y si necesita una red solo use una red estándar entre estas computadoras FTL.

¿Difiere de los primeros días de Internet? En otro sentido, ¿sería posible manejarlo con cualquier protocolo que se haya desarrollado en el campo de las redes informáticas?

No, eso no es posible, en un nivel fundamental.

Un protocolo es un conjunto de reglas que definen cómo una cosa se comunica con otra cosa de forma estandarizada. Pueden ser dos partes de una aplicación en la misma computadora (por ejemplo, una parte de mi aplicación envía datos a otra parte al guardar JSON en un archivo), o pueden ser dos máquinas muy diferentes en diferentes rincones del mundo (por ejemplo, ejemplo, aquí en el Reino Unido puedo enviar un correo electrónico a mis amigos en Nueva Zelanda porque alguien definió POP y SMTP, algunos protocolos de correo electrónico).

Fundamentalmente, no puede participar en ninguna forma de comunicación con nada a menos que tenga un protocolo definido. Eso no tiene que ser un protocolo de protocolo escrito, numerado por RFC, aprobado por IETF y documentado por MDN, pero sigue siendo un protocolo.

Entonces: no , debe definir un protocolo de red antes de que sus computadoras puedan comunicarse entre sí.

Lo que necesita es un protocolo de datos comprimidos basado en preajustes. Una compresión basada en preajustes permite al remitente seleccionar un protocolo que tiene un diccionario fijo basado en la intención. Por ejemplo, si desea traducir texto, es mejor utilizar un recuento de bits bajo para texto muy repetido. Algunas palabras también podrían eliminarse automáticamente. La mayoría de las veces, omitir un "el" no causará ningún problema, pero ahorraría bastante. Aplique la codificación Huffman o similar a muchos documentos de texto sin formato para obtener el diccionario. Dado que los diccionarios son grandes, es mejor no reenviarlos. Algo similar podría usarse para otros protocolos.

La respuesta a esta pregunta depende al 100% del tráfico que pasa por la red. Hay una buena razón por la que tenemos tantos protocolos hoy. Cada uno funciona bien en su propio nicho. Si necesita comunicación síncrona, los protocolos como ATM tienen valor. Si su sistema FTL tiene comportamientos similares a la fibra óptica, SONET puede ser útil. Si su sistema es un sistema de transmisión, ninguno de los dos funcionaría en absoluto, y le gustaría usar algo como 802.11b o quizás uno de los otros protocolos inalámbricos de menor ancho de banda como Zigbee.

Cada uno de esos protocolos que acabo de mencionar están en uso hoy en día, de una forma u otra. Cada uno se usa porque se ajusta a los roles que debe cumplir.

Una gran pregunta podría ser el uso militar versus civil. Si su sistema es utilizado únicamente por militares, los protocolos como LINK-16 se han diseñado durante décadas para funcionar bien en entornos de ancho de banda limitado. Mientras tanto, se eligieron protocolos creados sobre Turbo Codes para el Mars Reconnaissance Rover porque hizo el mejor uso del limitado ancho de banda disponible y pudimos ahorrar los recursos necesarios para decodificar turbo códigos.

Primero, gran pregunta. En segundo lugar, no para contradecir ni discutir con ninguna de las excelentes respuestas que ya están aquí, sino para ofrecer una alternativa muy situacional: según la tecnología, si está imaginando algo como el entrelazamiento cuántico, es posible que ni siquiera necesite preocuparse por un protocolo. Si se imagina algo más tradicional en lo que respecta a las comunicaciones, deje de leer. : )

Con un sistema similar a QE, siempre hay una conexión directa que siempre está activa pase lo que pase, por lo que "comunicarse" podría ser más como copiar un archivo de una parte de su disco duro a otra. No existen paquetes caídos o no sincronizados, y no hay riesgos de seguridad en la medida en que se transfieren los datos de un punto a otro. Entonces, incluso si hay un software diferente ejecutándose en cada extremo, solo tiene que enviar los datos sin procesar.

Lo importante sería simplemente comprimir los datos al tamaño más pequeño posible dadas las estrictas restricciones de ancho de banda. Siempre que se conozca el algoritmo de compresión en ambos extremos, no tendrá ningún problema.

Nuevamente, este es solo un enfoque para cierto tipo de escenario.

¿Difiere de los primeros días de Internet? En otro sentido, ¿sería posible manejarlo con cualquier protocolo que se haya desarrollado en el campo de las redes informáticas?

Es absolutamente diferente de los primeros días de Internet, y he aquí por qué.

Cuando se inventó Internet, las velocidades de comunicación ya eran mucho más rápidas que sus especificaciones, mientras que los procesadores eran mucho más lentos de lo que son hoy. Usted describe una situación en la que la proporción de (potencia informática) / (ancho de banda) es mucho mayor que nunca.

Entonces, aunque ciertamente sería posible usar (m) cualquier protocolo ya inventado ajustando los tiempos de espera, eso no es lo que se haría en esta situación. En su lugar, se inventarían nuevos protocolos, optimizados para esta situación específica.

El protocolo FTL v1 tendría una trama concisa no muy diferente a HDLC o Ethernet II. Algunas respuestas nombraron ATM, lo cual es bueno, excepto por valorar la latencia más que la eficiencia de bit, que, sospecho, podría ajustarse. Directamente encima de eso , sin capas adicionales, vendrían datos de protocolo de aplicación altamente comprimidos. Primero, mensajes militares/financieros cortos y costosos con un uso no muy diferente al del antiguo telégrafo. Luego, noticias y mensajes personales.

Las capas de los protocolos contemporáneos están diseñadas para mejorar la separación entre las preocupaciones de transportar, enrutar y usar los datos, lo que facilita reemplazar uno sin afectar al otro. Para que existan, este incentivo debe prevalecer sobre el incentivo a hacer el máximo uso del mínimo número de bits. No creo que este sea su caso hasta bien entrado en el universo de la red FTL, si es que llega a hacerlo.

Si no, ¿qué hace que sea imposible de manejar?

Nada. Pero el uso no se parecerá a Internet contemporáneo hasta que se mejore el ancho de banda.

Me gustaría responder a la pregunta de comentario de @JohnFeltz:

¿Alguna restricción sobre cuántos de estos dispositivos puede construir y colocar uno al lado del otro? Si puedo ejecutar 100,000 de estos en paralelo, solo necesito un multiplexor inverso para obtener un ancho de banda de 5 Mb

Desafortunadamente, si coloca dos o más de estos dispositivos uno al lado del otro, interferirán.

Esto no solo es un problema para ampliar el ancho de banda, sino que también permite la interferencia de mensajes que no desea que un enemigo envíe o reciba.

La distancia mínima de seguridad entre los transceptores depende de usted, solo sea consistente al respecto. También podría ser un problema solo en el lado de envío o recepción.

"El valiente héroe se cuela en los terrenos del palacio disfrazado de jardinero. Mientras replanta un arbusto, también entierra una pequeña caja debajo de sus raíces. Más tarde, un temporizador lo activa y la comunicación se vuelve imposible. El oficial de comunicaciones puede decirle al emperador que la caja está en algún lugar. en el lado este del palacio, pero en realidad encontrarlo requiere una larga búsqueda. Mientras tanto, el equipo de comunicación se reubica en la parte superior de la torre oeste, tratando de escuchar mensajes en el ruido".

dado que la transferencia es "instantánea", podría codificar la información no en los bytes que envía (como con los protocolos de red normales), sino en la cantidad de tiempo entre bits. entonces, si desea enviar el número 255, no usaría un byte completo (8 bits) como con un paquete de Internet normal. más bien, enviaría 1 bit exactamente 255 nanosegundos después del bit anterior. su ancho de banda total realizado estaría limitado solo por la precisión de sus relojes y su latencia deseada. por ejemplo, podría decir "enviaré 1 bit cada 10 millones de nanosegundos. El valor que representa ese bit es igual a la cantidad de nanosegundos desde que se envió el bit anterior". ese protocolo le daría una latencia unidireccional máxima de 10 milisegundos y una tasa de transferencia de datos mínima de poco menos de 300 bytes/segundo. duplicar la latencia máxima también duplica la tasa de transferencia efectiva. Se podrían construir protocolos más sofisticados sobre este para negociar la tasa de transferencia sobre la marcha, o usar codificación de código corto para maximizar el rendimiento asegurando que los bloques de datos más comunes tengan muchos ceros a la izquierda (para que los bits se envíen más rápido). También es posible que desee limitar el tamaño máximo del bloque para garantizar que los relojes permanezcan sincronizados según la desviación relativa del reloj.

Usaría el enlace directamente como una línea serial tonta de 7 bits y resucitaría los antiguos protocolos UUCP. Estas cosas en realidad tienen menos gastos generales que las modernas y están mejor diseñadas para lidiar con los estúpidos tiempos de transmisión lentos. El único cambio significativo es reemplazar uuencode con una de las variantes base85.

Supongo que esta máquina, a la que llamo The Link, es rara. Es decir, no habrá suficientes ejecutándose en paralelo para mejorar el ancho de banda.

Ofreceré una visión diferente. El enlace no estaría en una red en el sentido normal. No tendría sentido.

En primer lugar, debido a su importancia y al bajo ancho de banda, el uso de The Link estaría estrictamente controlado para que la gente no transmitiera imágenes de gatos. Habría cortafuegos para evitar el acceso no autorizado.

En segundo lugar, debido al bajo ancho de banda, The Link puede considerarse más como un telégrafo que como algo en una red informática moderna. Un telégrafo (salvo la necesidad de repetidores) ofrece velocidades comparables a la velocidad de la luz gracias a la magia del alambre de cobre. Cierras la tecla del telégrafo, el otro extremo hace "clic". Seguro que el electroimán es lento, pero el humano que manipula las señales es aún más lento. Es efectivamente instantáneo. Considere un cable submarino entre los EE. UU. y el Reino Unido. Cada país puede tener una red de telégrafos sofisticada y, por una pequeña tarifa, Sally en Florida puede contarle a su abuela en Maine sobre su nuevo gato, pero ¿qué mensajes se considerarían para las comunicaciones a través del cable submarino? Probablemente no el telegrama del gato. En cambio, probablemente se usaría para información relevante para la política y las altas finanzas.

Por supuesto, en 2016, no vamos a tener un par de personas escribiendo mensajes en nuestro enlace interestelar. Pero sigue siendo como un telégrafo. Tendrías una computadora en cada extremo de The Link. El remitente leería de un búfer de mensajes (codificados, luego comprimidos al máximo) y los sacaría. La máquina en el otro extremo recibiría, descomprimiría y decodificaría.

Entonces, si bien no habría un protocolo de red, probablemente habría algún tipo de protocolo de mensaje para que el receptor supiera cuándo era apropiado descomprimir el mensaje. Un mensaje corto sería un 'quemador de granero' sin duda porque la compresión por carácter sería más pequeña y, por lo tanto, menos eficiente.

Dado lo controlado que sería el uso de The Link, es poco probable que los mensajes sean particularmente interesantes para la persona normal de la misma manera que en nuestro ejemplo internacional anterior, la persona normal no estaría demasiado preocupada por los asuntos de las altas finanzas.

Pero, ¿exactamente qué mensajes se enviarían a través de The Link?

Digamos que una nave colonial sublumínica ha llegado a su destino después de 300 años y está comenzando a construir su nuevo hogar. El enlace está configurado.

Los primeros mensajes enviados son algo como esto:

Hola Tierra, hemos llegado sanos y salvos y todo marcha según lo previsto.

(Serán unos pocos caracteres, tal vez, debido a la codificación), y respondido por,

¡Es muy bueno saber de ti, cheerio!

(otros 2 o 3 caracteres)

Después de bromas y diagnósticos, ¿qué relevancia tiene algo en la Tierra para la colonia? La ayuda está a 300 años de distancia, salvo algún nuevo descubrimiento impactante. La política crece y decae a lo largo de los siglos. Los países cambian. ¿Seguiría existiendo el país que envió el barco? ¿Sería reconocible el Orden Mundial que envió la nave? ¿Qué relevancia tendría la colonia para la gente de la Tierra, 15 generaciones después de aquellas almas valientes y atrevidas que abordaron la nave de la colonia?

Podría ser que un jpeg de gato fuera tan útil como cualquier otro mensaje.

EDITAR: dada la falta de importancia entre la vida cotidiana de las personas en la Tierra y los colonos, parecería que The Link en este caso generalmente se usaría para comunicaciones científicas de bajo grado. Observaciones sobre la estrella en órbita, y ese tipo de cosas. No sé por qué eso sería particularmente relevante, pero es mejor que el aire muerto, suponiendo que The Link no se desgaste por el uso.

Un uso más probable de The Link no involucra a las personas en absoluto. En cambio, la nave que alberga a The Link es puramente robótica. Estas naves son enviadas por decenas a diferentes sistemas estelares. Observan, en silencio y con sigilo, las señales de otras razas. Los datos enviados, muy lentamente, están diseñados para permitir que los humanos en la Tierra vislumbren la tecnología de los extraterrestres y, con suerte, sus intenciones. Siniestro, de hecho.

Considere esto: Lucas 17:11 o esto: Corán 2:4-5, edición Oxford World's Classics, o incluso esto: "regla 5". Son todas referencias a frases o textos más extensos. El factor limitante en este tipo de codificación es la disponibilidad de las referencias tanto para el remitente como para el receptor. El inglés es un idioma altamente redundante, se conocen idiomas mucho más eficientes. El graduado universitario típico tiene un vocabulario de <20,000 palabras o familias de palabras. Un byte permite codificar 65k palabras. Por lo tanto, de 5 a 10 bytes/segundo es más rápido que hablar y no limitaría la transferencia de datos verbal (en contraste con la visual).

Soy un poco riguroso MeeSeeks.

Siento que deberíamos estar discutiendo la paradoja que presenta su tecnología al tratar de resolverla dentro de las convenciones de transmisión de datos modernas conocidas.

"la humanidad de alguna manera se las arregla para transmitir datos de forma instantánea"

Este elemento de las redes FTL de su mundo, en particular, hace que mucho de lo que define las convenciones modernas de transmisión de datos (y, por extensión, cómo las medimos) sea efectivamente inútil para usted.

Con su tecnología, hay latencia cero. En otras palabras, cuando envío algo, se recibe en el otro lado EXACTAMENTE al mismo tiempo que lo envío. No antes, no nanosegundos después, sino exactamente al mismo tiempo en algún lugar distante. Si resuelve esta situación dentro de las redes modernas, su rendimiento de datos estaría fuera de serie. En esencia, podría meter una cantidad infinita de información a través de esta red, ya que teóricamente no hay limitación. Al menos no todavía...

"pero la velocidad en sí es lenta, digamos, poder enviar de 5 a 10 bytes (10 a 20 códigos hexadecimales) por segundo".

Aquí es donde su situación se vuelve un poco única . Experimente mentalmente si quiere:

Cuando publique esta respuesta, recibirás una notificación. Pretenda por el bien de nuestra discusión que estamos operando con la tecnología de su mundo. Cuando presiono este botón "Publicar su respuesta", su dispositivo le hará ping con esta notificación; ambos eventos ocurrirán simultáneamente. PERO, ¿cuántos datos se enviaron?

El principal enigma aquí es que si los datos IF se envían instantáneamente, entonces no tiene sentido medir el rendimiento de los datos durante un período de tiempo. Y si las medidas de ancho de banda no se aplican, ¿cómo y/o por qué su tecnología es tan limitada?

Mi respuesta:

Teniendo en cuenta los hechos de su tecnología y ajustándose al contexto de su pregunta, si yo fuera usted, no me preocuparía por definir la transmisión de información con los principios modernos de redes. Me centraría en definir por qué las cosas son como son de la forma más sencilla.

Por ejemplo:

• La transmisión de datos es instantánea debido a {insertar aquí el concepto teórico preferido de transmisión de información instantánea, es decir. entrelazamiento cuántico}
• La tecnología está limitada a un estado de encendido y apagado (similar a los sistemas binarios), lo que le brinda una limitación a los datos que se pueden transmitir, así como también proporciona una justificación para resolver la limitación de la cantidad de datos que se pueden transmitir. enviados" durante un período de tiempo determinado a pesar de que el "envío" de esos datos sea instantáneo. Explicación: los datos en sí están en ambos lugares al mismo tiempo, pero el estado del sistema no puede estar ENCENDIDO y APAGADO al mismo tiempo. Lo que significa que el retraso en la transmisión de información no se debe a la latencia o al ancho de banda, que, como comentamos, no se aplican necesariamente, sino que está limitado por una limitación funcional del sistema en su lugar.
• Opcional: Los sistemas son macho-hembra, y la comunicación solo es posible entre sistemas emparejados. No hay razón real, simplemente me gusta esto como una limitación adicional, ya que el contexto de su pregunta realmente se reduce a: "Si los datos se pueden transmitir instantáneamente, ¿cómo limito racionalmente la tecnología para los habitantes de mi mundo?"

Conclusión: como con cualquier cosa de la imaginación, haz con todo esto lo que quieras. Porque oye, es tu mundo. Y gracias, probablemente fue más divertido para mí escribirlo que para ti leerlo.

¿Qué tipo de información desea transmitir? Si es solo texto sin formato, implemente algo como la Biblioteca de Babel en ambos extremos. Luego solo tiene que transmitir la información posicional del mensaje deseado.

Esto supone que en este mundo de FTL, la potencia de procesamiento de comunicaciones y el almacenamiento de datos no son problemas.

Aclaración: lo que quería decir al hacer referencia a la biblioteca de babel es una especie de tabla de búsqueda. Esta comunicación habría sido creada por una razón específica. Mi suposición es que esto es para la comunicación interestelar en lugar de enviar algo a unas pocas millas de distancia. Por lo tanto, habría alguna forma de codificación para garantizar que la intención del mensaje se envíe sin posiblemente la necesidad de enviar la información literal. ¿Por qué enviar 30.000 bytes cuando puedo enviar 10-20 que apuntan a una tabla de búsqueda que transmite el mensaje completo?

Iba a publicar la misma observación que James Turner, así que voté a favor de su respuesta y pensé en una objeción (que también podría explicar tanto el efecto de interferencia como la lentitud de la transmisión).

Si la transmisión fue impecable e instantánea, entonces si fuera posible resolver el tiempo con precisión de nanosegundos, podría estar de acuerdo en que se envíe una señal cada 1.048576 ms (como máximo), con un retraso de 0 ns que significa 1111111111 y un retraso de 1048575 ns lo que significa 0000000000. Diez bits cada milisegundo y ya estamos en el rango de 10 kbit/s (y, en promedio, mejor).

Así que planteo que mientras la transmisión de la señal es instantánea, resolver la señal es un proceso probabilístico. Analice una ventana de 1 ns, y las posibilidades de distinguir una "señal" o "falta de ella" son nulas. Para alcanzar una certeza del 99%, debe analizar la transmisión de un segundo completo.

Así que, por supuesto, los ingenieros llegaron a un compromiso y, combinando tiempos más cortos con esquemas de compresión y corrección de errores, elevaron el ancho de banda a 40-80 bits/s.

Si colocamos dos transmisores cerca, alrededor del 50% de las veces uno transmitirá un 0 mientras que el otro transmitirá un 1, lo que aumentará la tasa de error en el extremo receptor, obligando a una velocidad más baja; así que escalar el dispositivo no te sirve de nada.

Por otro lado, ¿a qué distancia deben estar los transmisores entre sí para que dejen de interferir apreciablemente? Digamos que son 500 metros; en el espacio, podrías construir una enorme matriz de comunicación, un cubo de estructura alámbrica de diez kilómetros de tamaño, formado por "cables" de 500 m que sostienen unos ocho mil transmisores, coordinados a través de señales sublumínicas normales. Los planetas pueden comunicarse entre ellos utilizando redes de superficie; los barcos serían mucho más limitados. Las consecuencias parecen interesantes.

Esta discusión parece muy estrecha: miraría la pregunta desde unos pocos pasos atrás.

Supongo que el contexto es una civilización interestelar, ya que de lo contrario es difícil ver la ventaja sobre la tecnología de comunicaciones existente. Si esta civilización tiene viajes FTL, entonces sería más efectivo enviar datos físicamente: una sola tarjeta Micro SD podría contener más de 500 años de transmisiones.

Si tiene comunicaciones FTL, pero viajar es más lento que la luz, entonces se vuelve más interesante. Durante toda la historia, las personas han podido viajar tan rápido como la información; recientemente tenemos comunicación instantánea, pero tampoco toma más de un día viajar a cualquier lugar si tiene prisa.

Si los mundos distantes pudieran hablar en tiempo real, pero viajar entre ellos llevara décadas, sería un tipo de realidad completamente nuevo. El lanzamiento de un dedal semanal de chips de memoria aún ofrecería un mayor ancho de banda que la radio FTL (en muchos órdenes de magnitud), pero la latencia sería de décadas frente a minutos. Hay implicaciones interesantes.

Supongamos que la gente de la Tierra estuviera obsesionada con la versión de Shakespeare de Omicron Persei VIII. Thimbles proporcionaría todas las obras de teatro, películas y entrevistas que la Tierra pudiera consumir, pero llegarían mucho después de la muerte de Space Shakespeare. Un Terran rico podría alquilar 15 minutos de tiempo de radio FTL para una charla en vivo, pero lo mejor que podría hacer sería charlar con los nietos de Spacespeare. O bien, podría chatear con una celebridad omicroniana viva, pero solo sus nietos podrían ver por qué son famosos.

Económicamente hablando, es difícil ver que las comunicaciones en tiempo real jueguen un papel importante en el comercio cultural. La gente puede pagar para ver películas de Space Hollywood, pero solo consumirían las películas de 200 años que llegan por dedal y tratarían la versión de 200 años de Space Hollywood como "el presente".

La radio FTL solo sería realmente buena para los spoilers. Lo cual no es muy importante para el comercio, pero obviamente sería útil para avisos de flotas de invasión masiva/supernovas/etc. De hecho, ese servicio podría ser una garantía importante para el comercio; si no pagas tu factura de Space HBO por los programas que enviaron hace 200 años, no te avisarán sobre ese asteroide el próximo marzo.

(Vagamente relacionado, el premio Nobel Paul Krugman escribió una vez un artículo sobre la economía del comercio sublight ).

nótese bien

Algunas de las respuestas anteriores tocan la idea de codificar grandes cantidades de datos utilizando diccionarios gigantes; esta idea tiene una larga historia, desde al menos el siglo XVII hasta la década de 1950, cuando fue desmantelada en el curso de la creación de la Teoría de la Información.

La idea es que escribas todos los libros posibles, los pongas todos en orden y luego los menciones por número. El problema es que un libro ya es solo una secuencia de bytes, es decir, un número largo, y dar un número a cada libro significa que el número será tan largo como el libro mismo; de hecho, serán exactamente la misma secuencia de bytes.

Por supuesto, la mayoría de las cadenas de bytes no son libros "reales", y si solo incluye textos válidos en inglés, puede omitir la mayoría de los números. De hecho, eso conduce a una compresión de datos significativa. Pero también requiere un algoritmo para generar todos los textos "significativos" posibles, es decir, un algoritmo que pueda enumerar cada pensamiento que un ser humano pueda tener. Eso es... desafiante... y requiere mucho espacio en disco.

Los algoritmos de compresión prácticos utilizan este tipo de "codificación de diccionario", pero es mucho más básico. El truco consiste en dejar la mayor cantidad posible fuera del diccionario, de modo que solo las cadenas muy comunes se reemplacen por códigos muy cortos, por lo que, por ejemplo, the cat sat on the matse reduce a 1 c2 s2 on 1 m2. Si usó un diccionario preestablecido que incluía todas las palabras conocidas, podría terminar alargando el mensaje ( 23 4954 3430 109 23 908078).