Многопоточный сервер обновлений

Question

Мы хотим заменить нашу текущую систему обновления программного обеспечения POS в наших магазинах. В настоящее время на нашем веб-сервере есть папка, в которой размещается скрипт, который наши регистры вызывают примерно каждые 30 минут. Они передают номер своей текущей версии, а сервер возвращает ответ XML, содержащий все файлы, которые необходимо обновить, хэш и любую другую соответствующую информацию для регистра, чтобы загрузить обновленные файлы.

Нам нужен сервис, который будет прослушивать отправляемые нами UDP-пакеты, которые мы можем использовать для запуска обновления. Это предотвратит ненужный опрос регистров на наличие обновлений. Мы пишем сервер обновлений, который будет прослушивать TCP-соединение с компьютера, проверять подлинность, вести некоторые журналы, а затем отправлять обновления для файлов, которые изменились. Мы хотим перейти на пользовательский сервер обновлений, поскольку нам необходимо выпустить версии POS на определенных компьютерах для пробного запуска после тестирования перед выпуском его в масштабах всей компании.

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

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

Каков наилучший способ получения доступа к этим файлам с диска / памяти в поточно-ориентированном режиме без использования большого количества памяти или не заставляя потоки ждать, пока другие потоки закончат работу с файлами? * *

РЕДАКТИРОВАТЬ: Забыл упомянуть, что мы используем C #.

Answer 1

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

Вы получите ошибки (по крайней мере, в Windows), если два потока попытаются открыть дескриптор чтения / записи в файл.

Answer 2

См. Документацию C # async IO.

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

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

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

Answer 3

Windows имеет функцию TransmitFile , которая может представлять интерес. Таким образом, вы позволяете ОС обрабатывать любое кеширование для вас. Это вызов C, но он должен быть довольно простым в использовании из проекта C ++ / CLI. Вызов может быть выполнен асинхронно с использованием перекрывающегося ввода-вывода.

Таким образом, диспетчер кэша Windows считывает файл и отправляет данные в сокет без необходимости вообще их трогать. Функция предназначена для высокопроизводительной передачи файловых данных через сокеты.

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