Intercambio de información en el espacio

Algo de lo que me di cuenta no hace mucho acerca de una sociedad espacial es que, si bien mucha tecnología se sentirá avanzada, mucha más se sentirá antigua solo por todos los obstáculos que tiene que superar para funcionar en primer lugar. . Un ejemplo de esto es la comunicación.

La forma en que lo estoy explicando actualmente en mi mundo es que para viajar más rápido que la luz, tu nave tiene que ir al espacio rápido (hiperespacio, slipspace, ya sabes, esa dimensión alternativa donde la física nos permite hacer lo que queramos). Quickspace funciona de manera muy parecida a un océano, donde hay corrientes y vientos que pueden ayudar o dificultar el viaje de un barco. La cuestión es que, para usar el espacio rápido, necesita un método viable para ingresar y salir (de lo contrario, estará atrapado allí para siempre). Esto significa que una señal enviada a través del espacio rápido irá mucho más rápido que cualquier nave, pero nunca sabrá cuándo o dónde detenerse a menos que esté contenida dentro de algún tipo de nave capaz de llevarla de regreso al espacio real. Esto significa que la información viaja tan rápido como lo hacen los barcos, y nosotros

Entonces, mi pregunta es ¿cómo se adaptarían nuestros modernos sistemas de comunicación para manejar este retraso? Las consideraciones sobre cómo viajaron las noticias/mensajes a través de los océanos en el pasado serían geniales, pero también me preocupa cómo lidiamos con cosas como Internet con un ping promedio de un par de meses.

Entonces, ¿cómo maneja las terribles, horribles y no buenas paradojas de causalidad que provienen de FTL?
@SerbanTanasa Honestamente, todavía no puedo creer que existan. Pero digamos que comparo el viaje en el espacio rápido con la teletransportación, ¿con algo de tiempo de viaje basado en la distancia? ¿Y el tiempo de viaje tiene lugar en un universo más pequeño que puede no tener un límite de velocidad? Básicamente, elimino la relatividad y el límite estricto de c de la ecuación.
Bueno, fácil. Si una nave alienígena de a ingresa a su sistema y dispara un doommaker a la Tierra, todo lo que tiene que hacer es encontrar una nave capital moviéndose de tal manera que esté en un marco de espacio-tiempo donde la nave no haya ingresado al sistema, comuníquese FTL con ella y haga lanza un láser hacia donde estará la nave enemiga (desde su perspectiva). Esto destruye la nave enemiga antes de que dispare, entonces, ¿cómo enviaste el mensaje?
Bien, esta vez lo tengo. Quickspace ofrece viajes en cuatro dimensiones percibidos como viajes en tres dimensiones. Básicamente, dado que ir más rápido que c te hace retroceder en el tiempo, viajar en el espacio rápido te hace avanzar en el tiempo para compensarlo. Para ti, llegas a lugares más rápido, pero para cualquier observador, llegas allí después de que te fuiste. Viajar hacia adelante en el tiempo no viola la causalidad, así que yo gano. ¿Derecha?
Eso me suena a dilatación del tiempo. Simplemente diga que la traducción Quickspace le da la velocidad de "ligeramente menos" que la velocidad de la luz y la traducción lo deja en el mismo momento relativo en comparación con la estrella de destino que tenía en relación con la estrella de origen. Básicamente, Quickspace usaría masas de clase estelar como puntos de anclaje y las traslaciones ocurrirían en lo profundo del pozo de gravedad, ciertamente dentro de la órbita de Mercurio. Presumiblemente, las diferencias de momento serían absorbidas y las energías de transición proporcionadas por las estrellas. El beneficio es que podría usar la fórmula normal de dilatación del tiempo.
Creo que su esquema de desplazamiento de tiempo funcionará, ya que efectivamente (es decir, en realidad) hace que el viaje Quickspace sea más lento que la luz. Por supuesto, seguirá siendo útil si tiene requisitos de energía reducidos en comparación con los viajes 'espaciales normales', o si no puede ser observado desde el espacio normal mientras está en tránsito.
@DaaaahWhoosh, seguro, pero eso significa que pasan 100.000 años en la Tierra mientras haces un viaje rápido al núcleo galáctico y de regreso. Mientras estés bien con eso, no hay paradojas.
@SerbanTanasa Estoy bien con eso siempre que pueda viajar a 100,000 años en el pasado en el viaje de regreso, que ya sabemos que es posible :)
@DaaaahWhoosh En realidad no puedes viajar al pasado. ¿Dónde dice alguien que es posible?
@DaaaahWhoosh No, no lo creo. Simplemente le permite llegar antes de que llegue la información sobre su partida. Viajar al pasado en el sentido clásico (al estilo de HG Wells) es a lo que me refiero, específicamente, y eso no es posible AFAWK.
@TylerH Viajar al pasado ES imposible, pero aparentemente también lo son los viajes FTL.

Respuestas (7)

En realidad, incluso con los protocolos de comunicación actuales, la latencia no es realmente un problema siempre que el enlace sea razonablemente confiable. Esta es una red tolerante a retrasos . Tenga en cuenta que en el mundo real, con las comunicaciones de largo alcance, tendrá que agregar una buena parte de la corrección de errores hacia adelante para que la mayoría de los errores puedan repararse sin necesidad de volver a solicitar y retransmitir los datos.

Incluso hubo un Borrador de Internet publicado hace algunos años que discutía cómo podría funcionar una "Internet interplanetaria". Tendría que ir y desenterrarlo, lo cual no estoy muy inclinado a hacer en este momento, pero la esencia era que sí, funcionaría bastante bien con solo modificaciones menores a los protocolos de bajo nivel. IP estaría bien. A UDP, ICMP y sus amigos no les iría muy mal. TCP no funcionaría muy bien en un entorno de alta latencia con sus viajes de ida y vuelta, pero eso no sería necesariamente un problema si la latencia se puede mantener en un nivel razonable (piense en minutos; el factor limitante probablemente sería una combinación de cómo tiempo que está dispuesto a esperar y su capacidad para rastrear ambos puntos finales en el espacio).

El verdadero asesino fue cuando comenzaste a aplicar la alta latencia a los protocolos de nivel superior y las implementaciones contemporáneas de los mismos. Algo como HTTP simple, con una sola solicitud seguida de su respuesta asociada, no sería tan malo. Sin embargo, un protocolo diseñado para usarse de forma interactiva, como FTP o SMTP, no funcionaría muy bien como está diseñado actualmente porque la latencia se multiplicaría por el número de viajes de ida y vuelta. El DNS definitivamente tendría problemas porque es relativamente sensible a la latencia. Este no es un problema insuperable, pero es algo que algunos de nuestros protocolos actuales no están bien equipados para manejar porque están diseñados para un entorno donde la latencia de un segundo es extremadamente alta.

Dado que esta ID se escribió en el contexto de nuestro mundo real, con nuestra física del mundo real, también tuvieron que lidiar con el hecho de que no todos los nodos serían visibles (en relación con el enlace de radio) desde todos los demás nodos, o incluso desde cualquier nodo cercano. , en todo momento. Entonces, ¿cómo resuelves todo esto? Bueno, resulta que una solución fácil es diseñar una red usando

almacenamiento y reenvio

Store-and-forward es una técnica muy antigua para construir redes informáticas. Técnicamente, en algún nivel, todas las redes conmutadas o enrutadas son de almacenamiento y reenvío, pero el reenvío se realiza tan rápido que normalmente no las consideramos como tales. En una red real de almacenamiento y reenvío, puede retener paquetes durante horas o días hasta que puedan transmitirse al siguiente nodo, acercándolos al punto final de destino. Para ver dos ejemplos de redes de almacenamiento y reenvío, considere Usenet y FidoNet . El correo electrónico de Internet también solía funcionar de la misma manera.

Las redes de almacenamiento y reenvío no brindan servicios de comunicación en tiempo real, pero se prestan muy bien a las comunicaciones orientadas a mensajes y lotes. El correo electrónico (tanto personal como en forma de discusiones) funciona bien en una red de este tipo. La navegación web tal y como la conocemos no funcionaría tan bien, simplemente por los retrasos que conlleva, pero en principio no hay nada que impida que funcione. La entrega de solicitudes por lotes para ser procesadas y los resultados devueltos más tarde funciona bien. Y así.

Por lo tanto, tendría que diseñar sus sistemas de comunicaciones para tener en cuenta esta latencia.Eso significa que no hay pantalla de video que muestre a un comandante de alto rango lejano para un chat bidireccional. Según la cantidad de ancho de banda que tenga y las necesidades de la historia, podría tener audio audiovisual, solo audio o solo texto, con o sin canales separados para que los datos los procesen las computadoras. Solo el texto es donde probablemente comenzaría, ya que requiere, con mucho, el menor ancho de banda (y como una ventaja adicional, es posible hojear y obtener la esencia general, a diferencia de un mensaje de video que debe reproducirse a velocidad normal) . También significa comunicaciones más como correo electrónico o tal vez incluso carta postal, o algo como lo que estamos haciendo aquí en Stack Exchange con el formato de preguntas y respuestas, y mucho menos como una conversación telefónica.

Los datos reales podrían ser transportados por naves especializadas, o transportados en naves que ya están en ruta hacia el área de destino, o transportados a través de una red de espacio rápido como alguien mencionó y transportados al espacio normal cerca del punto final. Pero lo anterior le permite lidiar con la latencia introducida por el hecho de que el mensaje debe transportarse de alguna manera.

Si bien UDP podría funcionar, no tendría sentido usarlo: su objetivo es reducir el ping para permitir aplicaciones en tiempo real, por lo que si el ping es demasiado alto de todos modos, no tiene ningún uso real. (a menos que simplemente construya un protocolo alternativo similar a TCP encima, por supuesto)
@Lohoris Tu comentario no tiene mucho sentido. UDP y TCP son buenos en diferentes cosas. En un entorno de baja latencia, UDP se utiliza, por ejemplo, cuando se puede tolerar la pérdida de paquetes y no la posible imprevisibilidad en el tiempo de entrega de TCP. La transmisión de audio y video son dos ejemplos comunes (DNS es otro, pero DNS puede recurrir a TCP para paquetes grandes); perder el valor de un paquete IP de datos AV transmitidos no afecta significativamente la comprensión, pero la tartamudez mientras la pila TCP está reconstruyendo la transmisión con los paquetes en el orden correcto puede afectar significativamente la usabilidad.
El uso de TCP para algo como DNS que se puede hacer sobre UDP y que funciona principalmente con pequeñas cantidades de datos aumentaría varias veces la cantidad de paquetes. (También en un entorno de alta latencia), UDP tiene la ventaja de que evita el viaje de ida y vuelta SYN/SYN-ACK/ACK para el establecimiento de la conexión de TCP, que no es particularmente significativo para grandes transferencias en un entorno donde los viajes de ida y vuelta se miden en cientos de milisegundos o menos, pero puede ser una diferencia bastante significativa en un entorno donde los viajes de ida y vuelta se miden potencialmente en cientos de horas o más.

¿Qué hay de tener estaciones de comunicación dentro de Quickspace? Así que envías un montón de ellos a QuickSpace, creas una red de comunicación y cuando necesitas enviar un mensaje, lo envías a esa red, los datos del mensaje contendrán las coordenadas de su destino y una vez que llegue a la comunicación más cercana. estación dentro de QS que puede enviarlo al espacio normal, lo hace.

Sí, existe el problema obvio de querer enviar un mensaje más allá de lo que puede alcanzar la red de comunicaciones QS. En ese caso el mensaje viajaría más rápido que la luz hasta un punto y luego continuaría atravesando el espacio normal a la velocidad de la luz hasta llegar a su destino.

Este. Muy poco emocionante y técnico, tan realista como parece. Para un observador, solo tendría estaciones normales en RS de alguna manera enviando mensajes entre sí en QS. El hecho de que tengan una contraparte en QS y un proxy que va entre espacios a 1000 veces por segundo transfiriendo información entre las 2 partes de la estación son detalles de implementación. E incluso si la frecuencia de tales transferencias es limitada, es solo una sobrecarga de latencia constante.

Pony express La información se carga en medios de alta capacidad con lectura y escritura de alta velocidad (el disco SSD podría ser un gran ejemplo de esto) y luego se envía por barco a su destino final. Habría barcos pequeños (¿de una sola persona?) Diseñados para la velocidad.

Nota al margen divertida. Incluso hoy en día es más rápido enviar información por correo que por internet.

Poste de tubo Vayamos aún más pequeños: tenga una cápsula totalmente automatizada programada para ir directamente del punto A al punto B. Esa nave probablemente consistiría solo en:

  • Una computadora capaz de ir solo del punto A al punto B a través de espacio rápido (cuanto más pequeño, mejor)
  • Unidad de espacio rápido lo suficientemente grande como para llevarte de A a B (¿entiendes la pista?)
  • Carga útil, también conocido como disco SSD (o cualquier cosa con acceso de lectura y escritura de muy alta velocidad)
  • Combustible (no tengo que especificar cuánto necesitas, ¿verdad?)

Básicamente, la configuración sería de esta manera:

  1. Surgirían las empresas Pony Express. Pequeñas naves se encargarían de enviar información de allá para aquí y de regreso
  2. Alguien trabajaría duro para automatizar todo el proceso tanto como sea posible. Cuanto más pequeño, mejor (poste de tubo)
  3. Agregue precisión a la publicación del tubo. Quien pueda manejar el tubo para volver a entrar en el espacio normal en el punto exactamente dado, gana.
  4. Surgen puestos de avanzada. Enviaría correo postal a centros de información bien conectados
Consideré algo como esto difícil, estaba en algo como escribir en papel nuevamente, pero sí, si los barcos viajan tan rápido como las señales de radio, lo más probable es que haya barcos de transporte. Al igual que el correo antiguo. Lo más probable es que use discos duros o tarjetas SD.
Me entusiasmó la idea de los envíos de mensajes de una sola persona, luego me recordaste que los robots son mejores que los humanos (ya que lo son para casi todo). Bueno, supongo que si no podemos tener ponis espaciales, también podríamos usar robots.
La triste noticia es: ¿Por qué usar robots cuando todo lo que necesitas es un chip de computadora?
@DaaaahWhoosh Algunas historias usan alguna variante de que los cerebros biológicos son especiales y la IA no puede manejar la navegación de su versión de FTL. (como Andrómeda) Esto permite historias más interesantes.
@PavelJanicek Quise decir que la nave era el robot, con el chip como su 'cerebro'. ¿Supongo que debería haberlo llamado drone? Sigo olvidando que es importante ser políticamente correcto cuando se habla de formas de vida sintéticas :)
¡Nunca subestime el ancho de banda de una furgoneta cargada de cintas de copia de seguridad!

Voy a hacer algunas suposiciones, la primera es que puedes enviar una señal en el Quickspace aunque no puedas salir.

En segundo lugar, tienes cierta capacidad para dirigir la señal, ya que puedes dirigir un barco.

Entonces, lo que esperaría para acelerar la comunicación sería tener estaciones de retransmisión, algunas permanentemente en Quickspace impulsando y retransmitiendo mensajes como un enrutador y en puntos finales máquinas que pueden entrar y salir de Quickspace para enviar/recibir mensajes desde el espacio real. Puede ser prohibitivo usarlo para llamar a la familia todas las noches, pero permitiría comunicaciones mucho mejores y más rápidas.

Es probable que todavía haya retraso, pero será mucho más manejable. Sin embargo, el retraso será la principal restricción sobre hasta qué punto la 'Tierra' podría extender su influencia a otras colonias. Cuanto más lejos menos, y menos necesita la colonia algo de la tierra u otros sistemas, también reducirá su necesidad de apaciguar.

Pero para saber cómo la persona promedio manejaría el retraso, mire hacia atrás a los EE. UU., Europa y el resto del mundo durante el siglo XIX hasta que el telégrafo comenzó a conectar el mundo.

Me imagino que las estaciones repetidoras serían difíciles de colocar/sincronizar/administrar, pero su beneficio es obvio. Probablemente se usarían para colonias cercanas/importantes. Gran respuesta.

Es un poco frívolo, pero se ha probado 'internet' de alta latencia: los protocolos admiten latencias muy altas, aunque tiene un problema bastante fundamental con la retransmisión y la corrección de errores.

http://en.wikipedia.org/wiki/IP_over_Avian_Carriers

Pero fundamentalmente: los protocolos de Internet, tal como existen, tienen confiabilidad y retransmisión incorporadas. Eso es simplemente horrible cuando tienes comunicaciones de ráfaga de alta latencia.

Lo que me imagino que obtendría en su lugar es básicamente lo que tenemos con el correo electrónico: el correo electrónico se diseñó para una era en la que el usuario promedio se conectaba a un punto de presencia local a través de un módem. Las comunicaciones por Internet tampoco estaban 'siempre activas' para las empresas. Envía su correo a una puerta de enlace local e intentará entregarlo más tarde.

Esto funcionaría en su escenario. Paquetes de correo electrónico que contienen correos electrónicos que se envían de ida y vuelta. También es posible que desee ver protocolos más antiguos como Archie, Gopher y NNTP. Estos también son de una era de 'no siempre en marcha'.

Creo que terminarías con varias redes de Internet similares, replicadas y sincronizadas. Tal vez enviaría una gran "copia de seguridad de Internet" de un lado a otro en cada servicio de mensajería y volvería a sincronizar las diferencias entre cada uno, algo así como lo haría rsync.

Respuesta interesante, y como actualmente estoy tomando una clase de redes, buscar protocolos más antiguos puede resultar una experiencia útil.
Con toda honestidad, probablemente no. Los protocolos más antiguos se basan en un montón de suposiciones que en realidad ya no se aplican. Internet son enlaces intermitentes, por lo que los datos deben almacenarse y reenviarse. Los que tienen valor hoy en día todavía están (casi) en servicio.

Otra solución (que también rompe las leyes de la física, pero de una manera diferente) es algo así como la comunicación instantánea o superluminal de Ansible .

Para hacerlo más limitado, haga que cada par de ansibles solo se pueda comunicar entre sí (átomos cuánticos acoplados o handwavium similar), por lo que para hablar con 1000 mundos diferentes necesita 1000 ansibles. Sí, una molestia, pero ciertamente vale la pena.

Esa es una opción, pero mi pregunta se refería más a lidiar con el retraso que a eliminarlo por completo. La Comunidad podría haber usado las Águilas para llegar a Mordor, pero se divirtieron mucho más caminando.

El RPG Traveler (primera edición en 1977) tiene un modelo de comunicaciones para la comunicación interestelar: The Express Boat Network. http://wiki.travellerrpg.com/Express_Boat_Network

El barco expreso (también llamado xboat) es un barco pequeño y rápido lleno de un compartimento para el piloto, bancos de datos de mensajes y unidades de salto. El ajuste es tan ajustado que no hay espacio ni siquiera para maniobrar los accionamientos. Cada uno es capaz de saltar 4 (cuatro parsecs por semana); salta, transmite sus mensajes a la estación a su llegada, y luego espera a que lo recoja un bote auxiliar, para repostar y enviarlo con una nueva carga de mensajes. Mientras tanto, la estación local acepta mensajes, los codifica y los transmite a una licitación en los bordes del sistema estelar. Los mensajes traídos por el xboat que llega y destinados a más adelante en la línea se consolidan con los nuevos datos y todos se envían a otro xboat que ya tiene combustible y está listo para partir. Toda la red funciona como el pony express: los mensajes siempre se mueven a la máxima velocidad.

Nota: un salto en la configuración de viajero tarda una semana, independientemente de la duración del salto.

Intercambio de información en el espacio
RespuestasAquíPolítica de privacidad1y, 0v