UDP-TCP File System, Trivial Remote File System

Сегодня выходной, так что напишу коротко про мелочи, до которых, как правило, руки не доходят.

TCP FS

Есть ещё одна вещь, которой нет в современном Юниксе и которую я хочу иметь в unix box фантома. Она проста как мычание, и почему её никто не сделал — непостижимо:

#cat /tcp/host/port > local_file

Правда, я хочу использовать иной синтаксис имени файла, URL style — tcp://host:port, но это уже детали. Естественно, наравне с TCP просится UDP, и там вообще проблем нет.

Для TCP есть очевидная проблема — нужен ли нам listen или connect, но её можно решить через указание в имени «файла» определённого суффикса.

Сказать на эту тему настолько больше нечего, что перейдём без остановки к следующей.

TRFS — тривиальная дистанционная файловая система.

В одной из тестовых сред Фантом работал на машине без диска и хотелось организовать дистанционный пейджинг по сети. Для этого я сделал минимальную сетевую ФС.

Ссылки:

• Минималистическое описание протокола ^[1]
• Клиент — хедер ^[2]
• Клиент — код (Си) ^[3]
• Сервер — код (Java) ^[4]

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

Обмен идёт секторами. Фактически, сам Фантом использует протокол именно как remote disk.

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

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

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

Протокол работает поверх UDP. Пользуйтесь на здоровье, коли потребуется. При всей простоте в силу асинхронности и out of order resend-а протокол довольно эффективен. Только если нужно упорядоченное исполнение запросов — это нужно обеспечивать снаружи. Сам TRFS счастливо отработает в порядке прихода ответов по сети.

Автор: dzavalishin

Источник ^[5]