Можно ли использовать файлы в качестве двунаправленного канала связи между двумя удаленными процессами (своего рода «сокеты поверх файлов»)?

Question

Вот сценарий:

• Пользователь имеет доступ к двум машинам

• Эти машины не могут связываться с сетевыми сокетами из-за ограничений брандмауэра

• Но оба имеют доступ к общему сетевому ресурсу с правами чтения / записи на третьем компьютере

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

Я представляю, что:

1) для связи потребуется два файла, по одному для каждого направления

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

Но я не уверен, возможно ли это, главным образом потому, что я сомневаюсь в пункте 2). Возможно, это возможно в Unix-подобных средах с NFS.

Возможно ли это? Это уже существует?

Answer 1

Я думаю, что это хорошая идея сначала разбить поток на пакеты. Тогда эти пакеты должны появиться как файлы в общем каталоге. Для двух способов должно быть два «пространства имен» (a-> b и b-> a). Для простоты отладки имена файлов должны содержать метку времени, а не просто инкрементную часть.

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

• создать файл на временное имя,
• напишите содержание, закройте его,
• затем переименуйте его в окончательное имя (с отметкой времени и т. Д.).

Таким образом, получатель будет выбирать файл только после переименования, когда он на 100% уверен, что он полностью записан.

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

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

Answer 2

Как насчет этого:
Когда машина A хочет отправить сообщение на машину B, она создает файл с именем _toBfromA_12782 (где 12782 - текущая метка времени).Он записывает содержимое в файл, а затем меняет имя, удаляя первое подчеркивание.
Каждые несколько секунд каждая машина проверяет, есть ли файлы с именем файла, начинающимся с toX, где X - их собственное имя,Если найдено несколько сообщений, их можно заказать в соответствии с отметками времени.После прочтения файла сообщения получатель удаляет файл.
Это предполагает, что у всех участников есть синхронизированное время, но если они этого не делают, это тоже может быть решено (или действительно проигнорировано).

Answer 3

mmap () может использоваться для совместного использования файла между двумя процессами. Это классическая стратегия IPC , и исторически некоторые реализации ядра API разделяемой памяти использовали временные inode в качестве резервного хранилища.

С точки зрения ядра, единственное отличие в вашей ситуации состоит в том, что файл, используемый для IPC, будет использовать inode, которые используют подсистему VFS для подключения к общему ресурсу NFS.

Answer 4

Возможно, попробуйте, если одно из этих решений работает для вас, зависит от того, позволяет ли ваша сетевая система один из упомянутых методов мониторинга:

Отслеживание папки для новых файлов в Windows

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

Answer 5

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

По сути, вы должны создать файл FIFO, используя mkfifo . Затем вы можете открыть файл и использовать блокировку чтения / записи для его обработки (каждое «открытие» может либо читать, либо записывать, но не оба одновременно, так что вам нужно будет, по одному для каждого направления). Некоторые другие описания процесса, которые включают некоторые примеры кода, можно найти здесь и здесь .

Я тестировал mkfifo, используя стандартные команды unix:

Создать трубу:

mkfifo mypipe

Запишите все из одного окна в трубу:

cat > mypipe

Чтение всего с канала в другое окно:

cat mypipe

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