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

Question

[CodeInside]

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

Мои варианты:

1. Использовать HttpWebRequest/HttpWebResponse
   
2. Использовать TcpSocketListener/TcpSocketClient
   

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

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

То есть как я обычно делал договорённость между клиентом и сервером:

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

Что скажете? Или может стоит разобраться в SOAP (не особо понял принцип его работы)? Будут рад вашим предложениям.

Answer 1

[Станислав Макаров]

Стоит разобраться с RESTful(REST-like) HTTP API как с подходом, который заходит в большем числе типовых задач, и разобраться с OpenAPI, и решатся все ваши проблемы про стандарт и про OSI. А уже потом, если вдруг увидете что RPC поверх какого-нибудь Protocol Buffers вам действительно нужнее - тогда и будете делать

Вы сейчас находитесь в вакууме относительно используемых технологий клиент-серверного взаимодействия, вам нужно из этого вакуума выходить. Про ту же авторизацию/регистрацию уже столько всего наделано, и протоколов (вроде OpenID Connect) и фреймворков (вроде поддержки в ASP.NET всех типовых сценариев), что аж есть из чего выбрать.

Comments

[CodeInside]

Это курсовой проект по .NET. Нельзя использовать другие фреймворки/готовые решения. ASP ещё не учили. По сути, функциональность взаимодействия разных ПО нужно самому реализовать (такие условия защиты курсового проекта).

[Станислав Макаров]

CodeInside пишите такие ограничения в вопросе, всё-таки Тостер - ресурс общего назначения и обычно советуют не изобретать велосипед (что полезно именно в учебных, а не в боевых целях).

OpenAPI - это не фреймворк, а язык описания HTTP API, которым, видимо, вам всё-таки можно пользоваться.

Впрочем, нельзя использовать другие фреймворки - понятие такое себе. Другие - какие? Только стандартную библиотеку .Net Framework? Прям так и написано?

[CodeInside]

Станислав Макаров, в документации проекта студент пишет функциональность, которую он собирается реализовать с помощью .NET. Готовые решения можно использовать, если они не представляют собой готовую реализацию с документации. То есть если это какие-то визуальные плюшки, типа подсветки синтаксиса, но при этом проект нацелен на образование студентов и подсветка кода - это второстепенная функциональность, то думаю, что можно.

Answer 2

[Александр Юдаков]

tls > http > json > свой стандарт

P.S. Но в рамках курсового проекта, в целях упрощения конструкции именно в .Net, я бы заменил json на xml - механизмы сериализации / десериализации xml в стандартной библиотеке уже есть, а json - нет.

Comments

[CodeInside]

Да, но в таком случае можно использовать JObject от NewtonSoft. Думаю, комиссия такое не запретит.

Answer 3

[jershell]

Получается такой порядок вопросов
1. Сообщение (текстовое или бинарное) (формат ИЛИ свой ИЛИ protobuf ИЛИ jsonrpc ИЛИ xmlrpc ИЛИ и.т.д)
я бы порекомендовал jsonrpc 2.0 поскольку понятен человекам и как миниум на него посмотреть чтоб взять идею как основу.
2. Транспорт. Если security и не париться, то https, если париться, то TCP в ssl. Если нет security то нет разницы, все есть tcp, Если удивить педагога, то UDP, но тут уж сами с усами, придется слать ACK самому и по какому-то принципу, его придется тоже описывать.