Что бы вам понадобилось, с точки зрения ингредиентов, было бы:
- метод загрузки обновлений - я бы предложил HTTP (S) для этого
- метод длязакодируйте лицензию, включая информацию о том, на какие обновления вы имеете право и как долго вы на это имеете право.В идеале это было бы непрозрачным для пользователя, но легко проверяемым на обоих концах (таким образом, пользователю может быть сообщено о ошибочной записи без необходимости обращаться к серверу)
- простой способ узнать, доступны ли обновления, ивозможно, когда нужно проверить еще раз
Я бы предложил определить простую службу XML через HTTP, используя встраиваемый HTTP-клиент, такой как (бесстыдный плагин) Arachnida , спростой API - что-то вроде:
class UpdateAgent
{
/* boilerplate */
public :
/* set the key to use. Throws an InvalidKey exception if not valid
* validity is checked locally - no HTTP queries are used.
* Key may have been invalidated on the server without notification
* at this point */
void setKey(const std::string &key);
// Get the key currently set
std::string getKey() const;
/* using a synchronous HTTPS query, check with the server if updates are
* available for the current key. Throws on error: one of the QueryError
* subclasses if there has been a query error, or InvalidKey is the
* key is either not set or is not valid (i.e. invalidated server-side) */
bool isUpdateAvailable() const;
/* etc. */
};
Сам ключ, как видно выше, будет представлять собой строку, которая посредством своего кодирования будет содержать некоторую информацию относительно ее действительности - например, какой-то CRC длязнать, является ли введенная строка действительной.Остальная часть ключа - включая дату его истечения - может управляться на стороне сервера, хотя информация об истечении срока действия также может быть закодирована в самом ключе (но это будет означать изменение ключа, если пользователь продлит лицензию).
Что касается серверной стороны, то при представлении ключа и запроса на обновление сервер
- проверяет действительность ключа
- , проверяет, доступны ли какие-либо обновления.для программного обеспечения, для которого предназначен ключ (информация, которая может или не может быть частью самого ключа, в зависимости от того, хотите ли вы управлять им в базе данных или хотите, чтобы он был частью лицензионного ключа)
- copyили жестко свяжите файл с местом, куда его можно загрузить, с уникальным и трудно угадываемым именем
- укажите URL-адрес для загрузки клиенту - например, в XML-потоке, возвращенном для HTTP-запроса
- начать тайм-аут, чтобы удалить файл после того, как он не был загружен в течение N секунд / минут / часов
- удалить файл, как только он был сделанwnloaded by client
Если загрузка не удалась, ее можно перезапустить или запросить снова.Если вы хотите взимать плату за отдельные загрузки, вам потребуется клиент, чтобы подтвердить успешную загрузку - или сообщить об ошибке при сбое - чтобы вы не учитывали отдельные загрузки дважды.
Конечно, все этоот макушки головы - могут быть некоторые детали, о которых я здесь не думал.Каждый из компонентов довольно легко найти.Версия с открытым исходным кодом Arachnida доступна на SourceForge , и у меня есть некоторый код для кодирования лицензионных ключей, если вам это нужно (использовал его для другого из моих продуктов), но я уверен, что вы можете написать это, есливы не хотите использовать мой.
Несколько вещей, о которых вы могли бы подумать, - это безопасная аутентификация ваших клиентов - чтобы они не разделяли лицензионные ключи - защита вашего HTTP-соединения, чтобы вы не заканчивали работупубликация обновлений в мире и т. д. Ни сервер, ни клиент не должны быть очень сложными для реализации, так как большинство строительных блоков уже существует.
HTH
rlc