Что бы вы использовали для внедрения быстрого и легкого файлового сервера?

Question

Мне нужно иметь в составе настольного приложения файловый сервер, который должен как можно быстрее реагировать на запросы о передаче файлов (от удаленных клиентов, обычно расположенных в той же локальной сети).Будет много запросов на файлы небольшого размера.Сервер должен быть в состоянии предоставлять как услуги загрузки, так и самовывоза.

Я не привязан к какой-либо конкретной технологии, поэтому я открыт для любого языка программирования, наборов инструментов, библиотек, если они могут работать в Windows.

Мое первоначальное решение - перейти к реализации на C / C ++ с использованием Windows Sockets или воспользоваться сервисами, предоставляемыми библиотеками, такими как Boost (asio или подобными).Я также думал об Erlang, но мне придется его выучить, и поэтому преимущества в производительности должны оправдывать увеличение времени разработки из-за необходимости изучать язык.

ПОСЛЕДУЮЩЕЕ РЕДАКТИРОВАНИЕ:Я ценю ответы, в которых говорится использовать FTP или HTTP или в принципе все, что уже было создано, но, учитывая, что вы все еще хотите написать что-то с нуля, что бы вы сделали?

Answer 1

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

1. Команда:1 байт для определения того, что будет сделано:(0x01 для запроса на загрузку, 0x02 для запроса на загрузку, 0x11 для ответа на загрузку, 0x12 для ответа на загрузку и т.д.).
2. Имя файла:может иметь фиксированный размер или иметь префикс байта для обозначения длины (при условии, что имя меньше 255 байт).
3. Контрольная сумма, например MD5 (если запрос на загрузку или ответ на загрузку)
4. Размер файла (если запрос на загрузку или ответ на загрузку)
5. полезная нагрузка (если запрос на загрузку или ответ на загрузку)

Это могло бы быть реализовано поверх простого TCP-сокета.Вы также можете использовать UDP, избегая затрат на установление соединения, но в этом случае вам придется иметь дело с контролем повторной передачи.

Прежде чем принять решение о внедрении собственного протокола, взгляните на HTTP-библиотеки, такие как libcurl, вы могли бы заставить свой сервер использовать стандартные HTTP-команды, такие как GET для загрузки и POST для выгрузки.Это сэкономило бы много работы, и вы сможете протестировать загрузку с помощью любого веб-браузера.

Другое предложение для повышения производительности - использовать в качестве хранилища файлов не файловую систему, а что-то вроде SQLite.Вы можете создать единую таблицу, содержащую один столбец char для имени файла и один столбец blob для содержимого файла.Поскольку SQLite имеет небольшой вес и обеспечивает эффективное кэширование, вы в большинстве случаев избежите накладных расходов на доступ к диску.

Я предполагаю, что вам не нужна аутентификация клиента.

Наконец - то:хотя вы предпочитаете C ++, чтобы обеспечить скорость работы с необработанным машинным кодом, редко это является основным узким местом в приложениях такого типа.Наиболее вероятно, это будет доступ к диску и пропускная способность сети.Я упоминаю об этом, потому что в Java вы, вероятно, сможете создать сервлет, который будет делать точно то же самое (используя HTTP GET для загрузки и POST для выгрузки) с менее чем 100 строками кода.В этом случае используйте Derby вместо SQLite, поместите этот сервлет в любой контейнер (Tomcat, Glassfish и т.д.), И все готово.

Answer 2

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

Это звучит как переосмысление колес.Конечно, FTP не идеален и имеет несколько странных недостатков, но ...это есть, это стандартно, хорошо известно и уже очень широко внедрено.

Answer 3

Если все компьютеры работают под управлением Windows в одной локальной сети, зачем вам вообще нужен сервер?Почему бы просто не использовать общий доступ к файлам Windows?

Answer 4

Я бы посоветовал не использовать FTP, или SFTP, или любой другой метод, ориентированный на подключение.Вместо этого выберите протокол или метод без установления соединения.

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

Я бы посоветовал вам рассмотреть возможность либо использования существующей реализации, либо реализации вашего собственного HTTP- или HTTPS-сервера / службы.

Answer 5

Ваши узкие места, скорее всего, происходят из одного из следующих источников:

• Ввод-вывод на жесткий диск - предполагается, что WD velociraptor имеет скорость произвольного доступа около 100 МБ / с.Кроме того, важно, настроили ли вы его как RAID0, 1, 5 или что-то еще.Некоторые читают быстро, но пишут медленно.Компромиссы.

• Сетевой ввод-вывод - при условии, что у вас самые быстрые жесткие диски при быстрой настройке RAID, если вы не используете ввод-вывод в гигабитном формате, ваша сеть будет работать медленно.Если ваши каналы большие, вам все равно нужно снабдить их данными.

• Кэш памяти - Кэш файловой системы в памяти должен быть достаточно большим, чтобы буферизировать весь сетевой ввод-вывод, чтобы это не замедляло работу.Это потребует больших объемов памяти для того вида работы, на который вы смотрите.

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

Предполагая, что все остальные проблемы решены, тогда беспокоитесь ли вы о самом вашем приложении.Обратите внимание, что большинство узких мест находятся вне вашего программного контроля.Поэтому, независимо от того, кодируете ли вы его на C / C ++ или используете определенные библиотеки, вы по-прежнему будете зависеть от операционной системы и аппаратного обеспечения.

Answer 6

Звучит так, как будто вам следует использовать SFTP (SSH) сервер, это безопасный брандмауэр / NAT, и он уже делает то, что вы хотите, и даже больше.Вы также можете использовать SAMBA или общий доступ к файлам Windows для еще более простой реализации.

Answer 7

Почему бы не использовать что-то существующее, например, обычный веб-сервер очень хорошо и быстро обрабатывает множество небольших файлов (изображений).

И многие люди уже потратили время на оптимизацию кода.

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

Что касается загрузок, то они также не представляют проблем со скриптом или пользовательским модулем - с помощью того же метода вы также можете добавить авторизацию.

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

Answer 8

Это новая часть существующего настольного приложения?Какова цель сервера?Защищает ли это загружаемые файлы и обеспечивает ли аутентификацию и / или авторизацию?Предоставляет ли это какую-то структуру для хранения загрузок?

Одним из вариантов может быть установка HTTP-сервера Apache на компьютере и передача файла через него.Используйте POST для загрузки и переходите к загрузке.

Если клиенты находятся в локальной сети, не могли бы вы просто поделиться диском?