У вас уже есть ответы для стандартного способа, поэтому я дам вам несколько предостережений, на которые стоит обратить внимание.
Если вы намереваетесь развернуть свой файловый сервер в недоверенной среде (например, в Интернете), подумайте о его защите сразу же. Обеспечение безопасности - это , а не , это просто вопрос включения шифрования - вам нужно знать, как вы собираетесь аутентифицировать своих пользователей, как вы хотите авторизовать различные типы доступа к различным частям сервера, как вы будете застраховать подлинность и целостность данных, а также то, как вы собираетесь сохранять конфиденциальность данных.
Вам также нужно подумать о доступности вашего сервера. Это означает, что вы должны быть отказоустойчивыми - то есть соединения могут (и будут) разрываться (независимо от того, были ли они разорваны преднамеренно или нет), поэтому вам нужно обнаружить это, либо произойдет какое-либо поддержание работоспособности (которое будет потерпеть неудачу, если клиент ушел) или с каким-то тайм-аутом активности (который истечет, если клиент ушел). Вам также необходимо подумать о том, сколько клиентов вы хотите поддерживать одновременно, что может радикально изменить архитектуру вашего сервера.
Что касается команд открытия, закрытия, чтения, записи и т. Д., То в большинстве протоколов передачи файлов не так много деталей, но может быть интересно сделать это в зависимости от вашей ситуации. Если ваши файлы огромны и вам нужны только некоторые их фрагменты, или если вы хотите иметь возможность блокировать файлы для работы исключительно с ними и т. Д., Вы можете захотеть вдаваться в такие подробности. Если у вас нет этих требований, более простые транзакционные команды, такие как get & put (а не open, read, read, read, close и open, write, write more, close), могут быть проще в реализации и легче в применении. работа с.
Если вы хотите, чтобы человек взаимодействовал с вашим сервером и давал ему команды, текст является хорошим подходом: его легко отлаживать, когда нюхают, а люди понимают текст и легко набирают текст. Если нет вовлеченных людей, использование целых чисел в качестве команд, вероятно, является лучшим подходом: вы можете структурировать свою команду так, чтобы она начиналась с целого числа, за которым следовал ряд параметров, и всегда просто ожидали, что то же самое на стороне сервера (и выполните switch по команде вы получаете). Однако даже в этом случае хорошей идеей будет иметь удобочитаемые значения в целых числах. Например, если поставить 'READ' в целое число, так как команда чтения использует столько же байтов, сколько 0x00000001, но ее легче прочитать, если ее прослушать с помощью WireShark.
Наконец, вы действительно смотрите на стандартные подходы и пытаетесь понять компромиссы, сделанные в каждом конкретном случае. Например, спросите себя, почему HTTP имеет такие подробные заголовки и почему WebDAV использует его. Почему FTP использует два соединения (одно для команд и одно для данных), в то время как во многих других протоколах используется только одно? Как NFS эволюционировала туда, где она сейчас и почему? Понимание ответов на эти вопросы поможет вам разработать собственный протокол - если после того, как вы поймете эти ответы, вы по-прежнему будете нуждаться в собственном протоколе.