внедряющий сервер для управления лицензированием

Я хотел бы реализовать серверную часть программного обеспечения для управления лицензиями. Я использую C ++ в ОС Linux.

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

Мой вопрос касается реализации связи между клиентом и сервером через Интернет:

Сервер будет иметь статический IP-адрес в Интернете, поэтому достаточно ли использовать простой клиент сокетов TCP / IP, который будет подключаться к серверу сокетов TCP / IP (предоставляя IP / PORT)?

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

С уважением

AFG

1

Решение

Вот некоторые преимущества использования HTTP в качестве транспорта:

  • легче получить права, больше шансов работать на производстве: Да, вам, вероятно, придется добавить дополнительные зависимости для работы с HTTP (на стороне клиента и сервера), но все же предпочтительнее еще один домашний протокол, который вы должны внедрить, поддерживать, заботиться о обратной совместимости, решать проблемы с несколькими платформами ( например, endianness) и т. д. С точки зрения простоты реализации, использование решения на основе HTTP должно быть намного проще в общем случае (особенно верно, если вы создаете API-интерфейс в стиле REST для проверки лицензии).
  • Доступна дополнительная помощьHTTP как основа Интернета — одна из наиболее широко используемых технологий сегодня. Большинство (всех?) Проблем, с которыми вы столкнетесь, вероятно, публично задокументированы с помощью решений / обходных путей.
  • Шифрование «бесплатно»Шифрование — это уже решенная проблема (HTTPS / SSL), как в отношении транспорта, так и в отношении того, что вы должны реализовать на своем конце, и это всего лишь вопрос его настройки.
  • Аутентификация сервера «бесплатно»HTTPS / SSL решает не только шифрование, но и проверку подлинности сервера, поэтому клиент может проверить, действительно ли он обращается к нужному сервису.
  • Гарантированно работать в интернете: HTTP / HTTPS трафик распространен в Интернете, поэтому вы не столкнетесь с проблемами маршрутизации или брандмауэрами, которые трудно пройти. Это может быть проблемой при использовании вашего собственного протокола.
  • Гибкость из коробкиВы также налагаете меньше ограничений на клиентов, взаимодействующих с вашим сервером, поскольку очень просто создать клиент во многих различных средах, если они могут общаться по HTTP (и, возможно, SSL), и они знают, как отправить запрос на ваш сервер. (т.е. как выглядит ваш сервис API).
  • Легко интегрируется с административным веб-приложением: Если вы хотите, чтобы пользователи могли каким-либо образом управлять своими учетными записями, связанными с лицензиями (обновить контактную информацию и т. Д.), Вы можете даже объединить сервер лицензий с этим приложением. Вы также можете встроить часть интерфейса администрирования лицензий в то же приложение, если это полезно.

И последнее замечание (это накладывает дополнительные ограничения на реализацию HTTPS / SSL на стороне клиента): вы даже можете использовать сертификаты SSL на стороне клиента, которые по существу позволяют аутентифицировать клиента на сервере. В зависимости от того, как вы их используете, сертификатами на стороне клиента сложнее управлять, но они могут быть, например. истек или отозван, так что в какой-то степени они на самом деле являются лицензии (для подключения к серверу).

1

Другие решения

  • HTTP не другой механизм. Это протокол, управляемый через соединения TCP / IP.
  • Интернет использует исключительно IP-транспорт. Вы можете использовать уровень сеанса UDP, TCP или SCTP (ну, конечно, UDP не является частью сеанса). TCP это общий выбор.
  • Сокеты являются интерфейсом операционной системы. Они являются единственным интерфейсом к сети в большинстве систем, но некоторые системы имеют другой интерфейс. Ничего общего с самим транспортом.
  • IP-адреса на практике привязаны к топологии сети, поэтому я настоятельно не рекомендую жестко кодировать IP-адрес на сервере. Если по какой-либо причине вам придется сменить поставщика, вы не получите тот же IP-адрес. Используйте DNS, это только один gethostbyname вызов.
  • И не забудьте аутентифицировать сервер; даже с жестко закодированным IP слишком легко перенаправить его.
0