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, и там вообще проблем нет.
Вообще unix-подсистема Фантома «ест» как традиционные Юниксовые имена, /usr/include/stdio.h, так и URL-и, tcp://ya.ru:80.
Для TCP есть очевидная проблема — нужен ли нам listen или connect, но её можно решить через указание в имени «файла» определённого суффикса.
Сказать на эту тему настолько больше нечего, что перейдём без остановки к следующей.
TRFS — тривиальная дистанционная файловая система.
В одной из тестовых сред Фантом работал на машине без диска и хотелось организовать дистанционный пейджинг по сети. Для этого я сделал минимальную сетевую ФС.
Ссылки:
Протокол напоминает дубовостью tftp, но допускает асинхронность — запрос не обязан синхронно ждать ответа, вместо этого клиент отправляет запросы без ожидания и стыда, может получать ответы вразнобой и перезапрашивает неполученное по таймауту.
Обмен идёт секторами. Фактически, сам Фантом использует протокол именно как remote disk.
Обращение к файлу идёт по идентификатору сессии и идентификатору файла. Это позволяет при необходимости опустить разыменование и работать с файлами по фиксированным номерам — опять же, в этой реализации так и сделано, Фантом всегда просит файл номер ноль, сервер сам знает, где его искать. Но есть и запрос «получить номер по имени».
Идентификатор сессии используется как маркер того факта, что сервер был перезапущен и забыл номера файлов. В такой ситуации идентификатор сессии покажет несовпадение и клиент получит ошибку, которую надо обработать перезапросив ещё раз номер файла для данного имени. Впрочем, эту часть протокола я не стал писать, так как мне самому она пока не нужна.
Протокол легковесный в плане реализации настолько, что даже сервер можно затолкать в слабый микроконтроллер. А уж клиента и подавно.
Протокол работает поверх UDP. Пользуйтесь на здоровье, коли потребуется. При всей простоте в силу асинхронности и out of order resend-а протокол довольно эффективен. Только если нужно упорядоченное исполнение запросов — это нужно обеспечивать снаружи. Сам TRFS счастливо отработает в порядке прихода ответов по сети.
