клиент серверное приложение net
Клиент-серверное приложение на потоковом сокете TCP
В следующем примере используем TCP, чтобы обеспечить упорядоченные, надежные двусторонние потоки байтов. Построим завершенное приложение, включающее клиент и сервер. Сначала демонстрируем, как сконструировать на потоковых сокетах TCP сервер, а затем клиентское приложение для тестирования нашего сервера.
Следующая программа создает сервер, получающий запросы на соединение от клиентов. Сервер построен синхронно, следовательно, выполнение потока блокируется, пока сервер не даст согласия на соединение с клиентом. Это приложение демонстрирует простой сервер, отвечающий клиенту. Клиент завершает соединение, отправляя серверу сообщение
Сервер TCP
Создание структуры сервера показано на следующей функциональной диаграмме:
Вот полный код программы SocketServer.cs:
Давайте рассмотрим структуру данной программы.
Первый шаг заключается в установлении для сокета локальной конечной точки. Прежде чем открывать сокет для ожидания соединений, нужно подготовить для него адрес локальной конечной точки. Уникальный адрес для обслуживания TCP/IP определяется комбинацией IP-адреса хоста с номером порта обслуживания, которая создает конечную точку для обслуживания.
Класс Dns предоставляет методы, возвращающие информацию о сетевых адресах, поддерживаемых устройством в локальной сети. Если у устройства локальной сети имеется более одного сетевого адреса, класс Dns возвращает информацию обо всех сетевых адресах, и приложение должно выбрать из массива подходящий адрес для обслуживания.
Создадим IPEndPoint для сервера, комбинируя первый IP-адрес хост-компьютера, полученный от метода Dns.Resolve(), с номером порта:
Здесь класс IPEndPoint представляет localhost на порте 11000. Далее новым экземпляром класса Socket создаем потоковый сокет. Установив локальную конечную точку для ожидания соединений, можно создать сокет:
Перечисление AddressFamily указывает схемы адресации, которые экземпляр класса Socket может использовать для разрешения адреса.
В параметре SocketType различаются сокеты TCP и UDP. В нем можно определить в том числе следующие значения:
Dgram
Поддерживает дейтаграммы. Значение Dgram требует указать Udp для типа протокола и InterNetwork в параметре семейства адресов.
Поддерживает доступ к базовому транспортному протоколу.
Stream
Поддерживает потоковые сокеты. Значение Stream требует указать Tcp для типа протокола.
Следующим шагом должно быть назначение сокета с помощью метода Bind(). Когда сокет открывается конструктором, ему не назначается имя, а только резервируется дескриптор. Для назначения имени сокету сервера вызывается метод Bind(). Чтобы сокет клиента мог идентифицировать потоковый сокет TCP, серверная программа должна дать имя своему сокету:
Метод Bind() связывает сокет с локальной конечной точкой. Вызывать метод Bind() надо до любых попыток обращения к методам Listen() и Accept().
Теперь, создав сокет и связав с ним имя, можно слушать входящие сообщения, воспользовавшись методом Listen(). В состоянии прослушивания сокет будет ожидать входящие попытки соединения:
В параметре определяется задел (backlog), указывающий максимальное число соединений, ожидающих обработки в очереди. В приведенном коде значение параметра допускает накопление в очереди до десяти соединений.
В состоянии прослушивания надо быть готовым дать согласие на соединение с клиентом, для чего используется метод Accept(). С помощью этого метода получается соединение клиента и завершается установление связи имен клиента и сервера. Метод Accept() блокирует поток вызывающей программы до поступления соединения.
Метод Accept() извлекает из очереди ожидающих запросов первый запрос на соединение и создает для его обработки новый сокет. Хотя новый сокет создан, первоначальный сокет продолжает слушать и может использоваться с многопоточной обработкой для приема нескольких запросов на соединение от клиентов. Никакое серверное приложение не должно закрывать слушающий сокет. Он должен продолжать работать наряду с сокетами, созданными методом Accept для обработки входящих запросов клиентов.
Как только клиент и сервер установили между собой соединение, можно отправлять и получать сообщения, используя методы Send() и Receive() класса Socket.
Метод Send() записывает исходящие данные сокету, с которым установлено соединение. Метод Receive() считывает входящие данные в потоковый сокет. При использовании системы, основанной на TCP, перед выполнением методов Send() и Receive () между сокетами должно быть установлено соединение. Точный протокол между двумя взаимодействующими сущностями должен быть определен заблаговременно, чтобы клиентское и серверное приложения не блокировали друг друга, не зная, кто должен отправить свои данные первым.
Когда обмен данными между сервером и клиентом завершается, нужно закрыть соединение используя методы Shutdown() и Close():
Сокет закрывается при вызове метода Close(), который также устанавливает в свойстве Connected сокета значение false.
Клиент на TCP
Функции, которые используются для создания приложения-клиента, более или менее напоминают серверное приложение. Как и для сервера, используются те же методы для определения конечной точки, создания экземпляра сокета, отправки и получения данных и закрытия сокета:
Вот полный код для SocketClient.cs и его объяснение:
Пишем мессенджер на C#. Часть 1. Вёрстка
Клиент-серверная разработка — одна из самых востребованных отраслей программирования. Зная её азы, можно создавать как мессенджеры, так и онлайн-игры.
В этой серии статей мы напишем клиент-серверное приложение на C# — простейший мессенджер. Серия состоит из трёх частей:
Язык C# пригодится в разработке чего угодно. Возможности WPF (система создания графических интерфейсов) позволяют создавать красивые и функциональные приложения для Windows, а ASP.NET — мощные серверные приложения.
Я постараюсь объяснить подробно, но охватить всё невозможно, поэтому вам нужно знать основы C#, ООП, ASP.NET, WPF и работы в Visual Studio.
Вот несколько статей, с которыми стоит ознакомиться, если вы чего-то не знаете:
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Структура приложения
Мы не рассматриваем регистрацию, поиск контактов, хранение сообщений, продвинутый дизайн. Вместо этого вы узнаете азы создания клиент-серверных приложений и сможете сделать всё самостоятельно.
Исходный код мессенджера вы найдете на GitHub.
Приложение мы поделим на экраны:
Экран — это элемент Border, который по умолчанию скрыт от пользователя. Виден будет только активный экран.
На экране авторизации пользователь сможет ввести логин и пароль, чтобы войти. Если он ввёл верные данные, то перейдёт на экран с контактами, иначе — увидит сообщение об ошибке.
На экране с контактами видны имена других пользователей, с которыми ведётся переписка. Чат открывается при нажатии на имя другого пользователя.
На экране с чатом видна переписка с одним конкретным контактом. Пользователь может написать и отправить новое сообщение или вернуться к экрану с контактами.
Верстаем экран авторизации
Начнём с определения стилей. В них минимально обозначим, как должны выглядеть элементы, и сразу укажем, что экраны по умолчанию должны быть скрыты:
Теперь сверстаем сам экран авторизации — он должен быть видимым:
Связь между C# и C#: REST, gRPC и все, что между
Оптимальный сценарий
Давайте рассмотрим, как мы хотели бы, чтобы наше клиент-серверное общение выглядело в реальном мире. Я представляю что-то вроде этого:
Я хотел бы иметь полную поддержку Intellisense. Когда я нажимаю server и . хочу, чтобы Visual Studio показывал все контроллеры. И когда я нажимаю CalculatorController и ., я хочу видеть все методы действия. Я также хочу высочайшую производительность, очень малую нагрузку на сеть и двунаправленную передачу данных. И мне нужна надежная система, которая отлично справляется с управлением версиями, чтобы можно было без проблем развертывать новые версии клиентов и новые версии серверов.
Обратите внимание, что я говорю здесь об API без сохранения состояния. Это эквивалентно проекту C #, где есть только два типа классов:
Традиционный REST подход
REST API появился в начале 2000-х и покорил интернет. Сейчас это, безусловно, самый популярный способ создания веб-сервисов.
REST определяет фиксированный набор операций GET, POST, PUT и DELETE для запросов от клиента к серверу. На каждый запрос получаем ответ, содержащий полезную нагрузку(обычно JSON). Запросы включают параметры в сам запрос или как полезную нагрузку (обычно JSON), когда это POST или PUT запрос.
Существует стандарт RESTful API, который определяет следующие правила (который вам на самом деле не нужен):
REST чертовски удобен, но не подходит к оптимальному сценарию. Итак, давайте посмотрим, сможем ли мы сделать это лучше.
ReFit
ReFit не является альтернативой REST. Вместо этого он построен поверх REST и позволяет нам вызывать конечные точки сервера (endpoints ), как если бы они были простым методом. Это достигается путем разделения интерфейса между клиентом и сервером. На стороне сервера ваш контроллер будет реализовывать интерфейс:
Затем на стороне клиента вам нужно будет включить тот же интерфейс и использовать следующий код:
Это так просто. Нет необходимости запускать сложную автоматизацию или использовать сторонние инструменты, кроме пары пакетов NuGet.
Это становится намного ближе к оптимальному сценарию. Теперь у нас есть IntelliSense и надежный контракт между клиентом и сервером. Но есть и другой вариант, который даже лучше в некоторых отношениях.
Swagger
Давайте рассмотрим последствия этого. С помощью JSON-файла, подобного приведенному выше, вы потенциально можете создать клиент C# с полным IntelliSense. В конце концов, вы знаете все пути, операции, какие параметры они ожидают, какие типы параметров, каковы ответы.
Есть несколько инструментов, которые делают именно это. На стороне сервера вы можете использовать Swashbuckle.AspNetCore для добавления Swagger в ваш ASP.NET и создания указанных файлов JSON. Для стороны клиента, вы можете использовать swagger-codegen и AutoRest чтобы обработать эти файлы в формате JSON и сгенерировать клиента. Давайте посмотрим пример того, как это сделать:
Добавление Swagger на ваш сервер ASP.NET
Начните с добавления пакета NuGet Swashbuckle.AspNetCore. В ConfigureServices, зарегистрируйте генератор Swagger:
В файле Startup.cs в методе Configure добавьте:
Наконец, методы действия(actions) внутри контроллера должны быть помечены [HttpXXX] и [FromXXX] атрибутами:
Это так просто для серверной части. При запуске проекта будет сгенерирован файл swagger.json, который вы можете использовать для генерации клиента.
Генерация клиента из Swagger с помощью AutoRest
Это создаст папку GeneratedClient с сгенерированными файлами C#. Обратите внимание, что пространство имен и имя клиента переопределены. Добавьте эту папку в ваш клиентский проект в Visual Studio как показано ниже.
Вам нужно будет установить Microsoft.Rest.ClientRuntime пакет NuGet, потому что сгенерированный код зависит от него. После установки вы можете использовать API, как обычный C# класс:
Есть некоторые тонкости, о которых вы можете прочитать в документации AutoRest. И вам нужно будет автоматизировать этот процесс, поэтому я предлагаю прочитать руководство Патрика Свенссона для получения некоторых полезных советов, а также эту статью Питера Яусовца.
Моя проблема с Swagger заключается в том, что файл JSON создается во время выполнения, поэтому это немного затрудняет автоматизацию процесса CI/CD.
Традиционный REST vs Swagger vs ReFit
Вот несколько моментов, которые следует учитывать при выборе.
gRPC (gRPC — удаленный вызов процедур) — это система удаленного вызова процедур с открытым исходным кодом, разработанная Google. Это немного похоже на REST в том смысле, что он обеспечивает способ отправки запросов от клиента к серверу. Но это во многом отличается, вот сходства и различия:
Это не руководство, а скорее общее представление о том, чего ожидать. Вот как будет выглядеть пример контроллера в gRPC:
Вам нужно добавить следующее в Configure в файле Startup.cs:
API описан в .proto файле, который является частью проекта:
Клиент генерируется из .proto файлов. Сам код очень прост:
gRPC vs REST
GRPC звучит как приятная сделка. Это быстрее и проще под капотом. Так должны ли мы все перейти с REST на gRPC? Ответ в том, что это зависит. Вот некоторые соображения:
По моим впечатлениям, работа с gRPC и ASP.NET все еще невелика. Вам будет лучше со зрелой поддержкой REST. Что касается контрактного общения, это хорошо, за исключением того, что у вас есть похожие альтернативы в REST, о которых мы уже говорили: Swagger и ReFit.
Самым большим преимуществом является производительность. В большинстве случаев, согласно этим критериям, gRPC намного быстрее. Особенно для больших полезных нагрузок, для которых сериализация Protobuf действительно имеет значение. Это означает, что это огромное преимущество для сервера с высокой нагрузкой.
Переход от REST к gRPC в большом приложении ASP.NET будет трудным. Однако если у вас есть архитектура на основе микросервисов, то этот переход станет намного легче выполнять постепенно.
Другие способы общения
Есть несколько других способов общения, о которых я вообще не упоминал, но стоит знать, что они существуют:
ASP.NET Core: Создание серверных служб для мобильных приложений
Представляем вторую часть из серии статей, посвящённых разработке на ASP.NET Core. В этом обучающем материале вы узнаете, как создавать серверные службы с помощью ASP.NET Core MVC для поддержки мобильных приложений.
Второй цикл статей по ASP.NET Core
Первый цикл статей можно найти здесь.
Образец мобильного приложения
Мобильные приложения могут без труда обмениваться данными с серверными службами ASP.NET Core. Здесь можно скачать образец кода серверных служб.
В данном материале в качестве клиента используется приложение Xamarin Forms ToDoRest. Оно включает отдельные клиенты для устройств под Android, iOS и Windows. По ссылке выше вы найдёте руководство, которое поможет создать приложение (и установить необходимые бесплатные инструменты Xamarin), а также сможете скачать образец решения Xamarin. В него входит проект двух служб ASP.NET веб-API, на замену которым приходит приложение ASP.NET Core из этой статьи (со стороны клиента изменения не понадобятся).
Функции
Приложение ToDoRest поддерживает составление списков, добавление, удаление и обновление элементов To-Do. Каждый элемент наделён своим идентификатором, названием, примечаниями и свойством, которое указывает, выполнен ли элемент.
В основном представлении элементов, как показано выше, имеется название каждого элемента, а наличие флажка указывает, был ли он выполнен.
Коснитесь значка +, чтобы открыть диалоговое окно для добавления элементов:
Коснитесь элемента в главном списке, чтобы открыть диалоговое окно для редактирования названия, примечания и статуса выполнения, либо чтобы удалить элемент:
Создание проекта ASP.NET Core
Создайте новое веб-приложение ASP.NET Core в Visual Studio. Выберите шаблон веб-API и отключите аутентификацию. Присвойте проекту имя ToDoApi.
Примечание: обязательно запустите приложение напрямую, а не через IIS Express, который по умолчанию игнорирует не локальные запросы. Выполните dotnet run из командной строки либо выберите название приложения из раскрывающегося меню Debug Target на панели инструментов Visual Studio.
Добавьте класс модели для представления элементов To-Do. Отметьте обязательные поля с помощью атрибута [Required] :
В этом примере при реализации используется частная коллекция элементов:
Настройте реализацию в Startup.cs:
Теперь можно перейти к созданию ToDoItemsController.
Создание контроллера
Для работы контроллера необходим параметр IToDoRepository; запросите экземпляр этого типа через конструктор контроллера. В среде выполнения этот экземпляр будет предоставлен благодаря поддержке платформы для внедрения зависимости.
Этот API поддерживает четыре команды HTTP для операций создания, чтения, обновления и удаления (CRUD) в источнике данных. Самая простая операция — Read (чтение), она соответствует запросу HTTP Get.
Чтение элементов
Метод List выдает код ответа 200 OK и список всех элементов ToDo, сериализованных как JSON.
Вы можете протестировать новый метод API с помощью ряда инструментов, например Postman, как показано ниже:
Создание элементов
Внутри метода проверяется, правильно ли составлен элемент и существовал ли он ранее в хранилище данных; если ошибок нет, он добавляется с помощью репозитория. ModelState.IsValid выполняет проверку модели; это следует сделать в каждом методе API, который принимает вводимые пользователем данные.
В образце используется перечисление кодов ошибок, передаваемых в мобильный клиент.
В ответе метод выдает только что созданный элемент.
Обновление элементов
Чтобы протестировать Postman, измените команду на PUT и добавьте ID обновляемой записи в URL. Укажите данные обновляемого объекта в теле запроса.
При успешном выполнении метод выдает ответ NoContent (204), обеспечивая тем самым согласованность с существующим API.
Удаление элементов
Помните, что при тестировании функции удаления в тело запроса добавлять ничего не нужно.
Использование visual C# для создания удаленного сервера
В этой статье вы можете создать удаленный сервер, к котором можно получить доступ к другому приложению с помощью visual C#.
Оригинальная версия продукта: Visual C #
Исходный номер КБ: 307445
Аннотация
Требования
В этой статье предполагается, что вы знакомы со следующими разделами:
Создание объекта удаленного сервера
Первым шагом в создании приложения-сервера является создание объекта сервера. Объект сервера — это то, с чем клиентские приложения мгновенно взаимодействуют и взаимодействуют на серверном компьютере. Клиентская заявка делает это с помощью прокси-объекта, созданного на клиенте. В этом примере объект сервера находится в библиотеке класса (DLL) и называется myRemoteClass.
В Обозревателе решений переименуем файл кода Class1.cs в ServerClass.cs.
Откройте ServerClass.cs и переименуйте class1 в myRemoteClass. Также необходимо переименовать конструктор по умолчанию для класса таким образом, чтобы он совпадал с именем класса. myRemoteClass должен наследовать от MarshalByRefObject класса. Теперь класс должен отображаться следующим образом:
Добавьте общедоступный метод в myRemoteClass, который принимает строку, отображает сообщение на консоль со значением строки и возвращает True, если строка не пуста.
Создайте проект для создания ServerClass.dll сборки.
Сохранить и закрыть проект.
Создание приложения удаленного сервера
После создания объекта сервера, с который клиент будет общаться, необходимо зарегистрировать этот объект в рамках Remoting. При регистрации объекта необходимо также запустить сервер и подключить сервер к порту для подключения к порту. Для этого необходим тип проекта, который выводит исполняемый файл.
Причина, по которой объект сервера включен в отдельный проект, заключается в том, что вы можете легко ссылаться на объект сервера из клиентского проекта. Если вы включаете его в этот проект, вы не можете ссылаться на него, так как ссылки могут быть заданной только для DLL-файлов.
В Обозревателе решений переименуем файл Class1.cs в RemoteServer.cs.
Добавьте ссылку на System.Runtime.Remoting пространство имен.
Добавьте ссылку на сборку ServerClass.dll, созданную в предыдущем разделе.
Используйте заявление в пространствах имен и имен, чтобы в дальнейшем в коде не требовалось квалифицировать объявления в этих пространствах using Remoting Remoting.Channels Remoting.Channels.TCP имен. Вы должны использовать using заявление до любых других заявлений.
Объявить соответствующую переменную. Объявить и инициализировать объект, который прослушивает подключение клиентов в определенном порту, который является TcpChannel портом 8085 в этом примере. Используйте метод RegisterChannel для регистрации канала службами канала. Добавьте следующий код объявления в Main Class1 процедуру:
Вызов метода объекта для регистрации объекта с помощью фреймворка Remoting и укажите RegisterWellKnownType RemotingConfiguration следующие ServerClass параметры:
Полное имя зарегистрированного объекта (в данном примере — ServerClass.myRemoteClass), а затем имя сборки ServerClass. Укажите как имя пространства имен, так и имя класса здесь. Так как в предыдущем разделе не было указано пространство имен, используется корневое пространство имен по умолчанию.
Назови конечную точку, где объект должен быть опубликован как RemoteTest. Клиенты должны знать это имя, чтобы подключиться к объекту.
Используйте режим SingleCall объекта, чтобы указать конечный параметр. Режим объекта указывает срок службы объекта при его активации на сервере. В случае объектов создается новый экземпляр класса для каждого вызова, который совершает клиент, даже если один и тот же клиент вызывает один и тот же SingleCall метод несколько раз. С другой стороны, Singleton объекты создаются только один раз, и все клиенты взаимодействуют с тем же объектом.
Используйте метод ReadLine объекта Console для поддержания работы серверного приложения.
Выполните построение проекта.
Сохранить и закрыть проект.