¿Es posible usar archivos como un canal de comunicación bidireccional entre dos procesos remotos (tipo de "sockets over files")?

Question

Aquí está el panorama:

• Un usuario tiene acceso a dos máquinas

• Estas máquinas no pueden comunicarse con conectores de red debido a las restricciones de firewall

• embargo, ambos tienen acceso a una red común compartida con permisos de lectura/escritura en una tercera máquina

Mi pregunta es decir: ¿es posible escribir una pequeña aplicación ejecutada en ambas máquinas que permite establecer un canal de comunicación entre las dos utilizando solo archivos en la red compartida? Lo ideal sería emular el comportamiento de las secuencias y los zócalos.

Imagino que:

1) que implicaría tener dos archivos que se utilizan para la comunicación, uno para cada sentido

2) y que tiene la posibilidad de leer un archivo, mientras que otro proceso está escribiendo. .. a través de la red.

Pero no estoy seguro si es factible, principalmente porque dudo sobre el punto 2). Sin embargo, es posible en entornos de Unix con NFS.

¿Es posible? ¿Ya existe?

Answer 1

Creo que es una buena idea dividir la secuencia en paquetes primero. Entonces estos paquetes deberían aparecer como archivos en el directorio común. Debe haber dos "espacios de nombres" para las dos formas (a-> b y b-> a). Para la depuración fácil, los nombres de archivo deben contener una marca de tiempo, no solo una parte incremental.

Solo hay un problema con los archivos: incluso si el archivo es muy pequeño, el receptor puede atraparlo cuando no está totalmente enrojecido, es decir, el archivo está solo a medio camino (caso común: 0 bytes) o una red error ocurrido durante la transferencia. Evitar esta situación, el remitente debe:

• crear el archivo en un nombre temporal,
• escribir el contenido, cerrarla,
• continuación, cambie su nombre por el nombre final (con fecha y hora, etc.) .

Por lo tanto, el receptor solo elegirá el archivo después del cambio de nombre, cuando sea 100% seguro, que está completamente escrito.

Antes de enviar un nuevo archivo, el remitente puede verificar el archivo temporal, si existe, significa que se canceló la última transmisión.

Al crear un nuevo archivo de transmisión, el remitente debe crear un archivo de información, que contiene información sobre el paquete de transmisión que se envía, por lo que al abortar, contendrá información sobre el paquete fallido. Tal vez, la única información es el momento de la transmisión (recuerde: el nombre del archivo temporal no contiene la marca de tiempo), pero es mejor que nada.

Answer 2

¿Qué tal esto:
Cuando la máquina A quiere enviar un mensaje a la máquina B, se crea un archivo llamado _toBfromA_12782 (donde 12782 es la fecha y hora actual). Escribe el contenido en el archivo y luego cambia el nombre para eliminar el primer guión bajo.
Cada pocos segundos, cada máquina comprueba si hay archivos con un nombre de archivo que comienza con toX donde X es su propio nombre. Si se encuentran varios mensajes, se pueden ordenar de acuerdo con las marcas de tiempo. Después de leer el archivo de mensaje, el destinatario borra el archivo.
Esto supone que todos los participantes tienen un tiempo sincronizado, pero si no lo hacen, esto también puede resolverse (o realmente ignorarse en realidad).

Answer 3

Recordaba vagamente algo acerca de los archivos fifo en UNIX. Una búsqueda web ha confirmado que eran lo que yo recordaba (una forma de realizar comunicación a través de archivos). No he probado para ver si funcionarán entre dos máquinas distintas, que tienen acceso al mismo sistema de archivos, pero creo que probablemente lo hará. Tal vez tenga algo de burla cuando tenga acceso a un sistema Unix para satisfacer mi curiosidad.

Básicamente, debe crear un archivo FIFO, utilizando mkfifo. Luego puede abrir el archivo y usar las lecturas/escrituras de bloqueo para procesarlo (cada 'abierto' puede leer o escribir, no ambos al mismo tiempo, por lo que lo necesitaría, uno para cada dirección). Algunas otras descripciones del proceso, que sí incluyen algunas muestras de código, pueden encontrarse en here y here.

He probado mkfifo, mediante los comandos estándar de UNIX:

Crear la tubería:

mkfifo mypipe 

escribir todo de una ventana a la tubería:

cat > mypipe 

Leer todo, desde la tubería de otra ventana:

cat mypipe 

La tubería funcionó como se esperaba, escriba una ventana, apareció en la otra, lamentablemente, sin embargo, esto parece funcionar (al menos para mí), cuando los procesos se ejecutan en la misma máquina, por lo que no ayuda con tu problema Pero voy a dejar la respuesta en caso de que sea útil a alguien en el futuro ...

Answer 4

Tal vez probar si una de estas soluciones funciona para usted, depende de si el sistema de red permite que uno de los métodos de control mencionados:

Monitoring a folder for new files in Windows

Haga 2 carpetas, cada proceso escribe en una de las carpetas, use una marca de tiempo para el nombre de archivo, escriba en modo exclusivo. Cada proceso supervisa la otra carpeta y cuando aparece un archivo, espera hasta que se escriba por completo, luego lo lee y luego lo elimina.

Answer 5

mmap() can be used to share a file between two processes, and is a classic IPC strategy, e históricamente algunas implementaciones kernel de API de memoria compartida utilizarían inodos temporales como almacén de respaldo.

Desde la perspectiva del núcleo, la única diferencia en su situación es que el archivo que se utiliza para IPC sería el uso de i-nodos que utilizan el subsistema VFS a conectarse al recurso compartido NFS.