Для однорангового приложения, которое может возобновить передачу файлов, достаточно ли проверить размер файла / дату изменения на предмет изменений, прежде чем возобновить файл? - PullRequest
1 голос
/ 27 июля 2011

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

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

Я начал с того, что хэшировал файл перед отправкой, поэтому у получателя есть хеш, с которым можно проверить готовый файл. Тем не менее, это только обнаруживает коррупцию в самом конце, если каждое резюме также не хэшируется. Эту проблему можно решить, просмотрев файл по частям и хэшируя каждый из них. Однако большая проблема с хэшированием заключается в том, что это может занять очень, очень много времени, что является плохим опытом для пользователя, когда пользователь просто хочет немедленно что-то отправить (например, Linux ISO на медленном сетевом ресурсе - это файл, который нужно послал).

Я думал о том, чтобы перейти к простой проверке размера файла и измененной даты каждый раз, когда передача начинается или возобновляется. Хотя это явно небезопасно, если только я что-то упустил (и, пожалуйста, поправьте меня, если я есть), почти все средства, которые конечный пользователь будет использовать для изменения файлов, будут вести себя хорошо и, по крайней мере, отмечать дату изменения и даже если нет, изменение размера должно поймать 99% случаев. Похоже ли это на приемлемый компромисс? Плохая идея?

Как установленные протоколы справляются с этим?

1 Ответ

1 голос
/ 31 июля 2011

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

Вместо хешей используйте контрольные суммы (например, CRC32).Это намного быстрее, чтобы проверить, был ли файл изменен.

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

Чанк и контрольные суммы являются лучшим компромиссом по сравнению с полными файлами и хешами в отношении взаимодействия с пользователем.

...