CodeInside
@CodeInside

Как организовать принцип передачи данных между клиентом и сервером?

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

Мои варианты:
  1. Использовать HttpWebRequest/HttpWebResponse
  2. Использовать TcpSocketListener/TcpSocketClient


Первый вариант:
+ более высокий абстракции (т.е. последний (прикладной) уровень модели OSI: проще писать код и передавать данные (есть headers, body ...)
- не знаю как стандартизировать данные (чтобы и клиент и сервер использовали одну и ту же договорённость обмена данными)

Второй вариант:
- более низкий уровень абстракции (транспортный уровень модели OSI): не так удобно писать код
+ можно стандартизировать обмен данными с помощью dll-файла.

То есть как я обычно делал договорённость между клиентом и сервером:
  1. Создал MyRequest.dll, в которой есть enum Command (команда, которую требует клиент от сервера) и byte[] data (сериализованные данные, которые нужны для выполнения команды) и MyResponse.dll.
  2. Подключил обе библиотеки и к клиенту, и к серверу.
  3. Знаю, что клиент/сервер работают по одному и тому же написанному мною "стандарту".


Что скажете? Или может стоит разобраться в SOAP (не особо понял принцип его работы)? Будут рад вашим предложениям.
  • Вопрос задан
  • 1008 просмотров
Решения вопроса 1
Стоит разобраться с RESTful(REST-like) HTTP API как с подходом, который заходит в большем числе типовых задач, и разобраться с OpenAPI, и решатся все ваши проблемы про стандарт и про OSI. А уже потом, если вдруг увидете что RPC поверх какого-нибудь Protocol Buffers вам действительно нужнее - тогда и будете делать

Вы сейчас находитесь в вакууме относительно используемых технологий клиент-серверного взаимодействия, вам нужно из этого вакуума выходить. Про ту же авторизацию/регистрацию уже столько всего наделано, и протоколов (вроде OpenID Connect) и фреймворков (вроде поддержки в ASP.NET всех типовых сценариев), что аж есть из чего выбрать.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
AlexanderYudakov
@AlexanderYudakov
C#, 1С, Android, TypeScript
tls > http > json > свой стандарт

P.S. Но в рамках курсового проекта, в целях упрощения конструкции именно в .Net, я бы заменил json на xml - механизмы сериализации / десериализации xml в стандартной библиотеке уже есть, а json - нет.
Ответ написан
@jershell
Получается такой порядок вопросов
1. Сообщение (текстовое или бинарное) (формат ИЛИ свой ИЛИ protobuf ИЛИ jsonrpc ИЛИ xmlrpc ИЛИ и.т.д)
я бы порекомендовал jsonrpc 2.0 поскольку понятен человекам и как миниум на него посмотреть чтоб взять идею как основу.
2. Транспорт. Если security и не париться, то https, если париться, то TCP в ssl. Если нет security то нет разницы, все есть tcp, Если удивить педагога, то UDP, но тут уж сами с усами, придется слать ACK самому и по какому-то принципу, его придется тоже описывать.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы