Иллюстрированный самоучитель по работе в Internet
Сетевые приложения
Существует два типа сетевых приложений: чисто сетевые (pure) и обособленные (standalone). Чисто сетевые приложения разработаны для применения в сетях. Использование их на отдельных компьютерах не имеет смысла. Наоборот, обособленные приложения призваны работать на отдельном компьютере. Для расширения возможностей они перестроены для работы в сетях. Примерами обособленных приложений могут служить текстовый процессор и редактор электронных таблиц.
Чисто сетевые приложения
Эти приложения были созданы для использования возможностей сетей. Каждое из них имеет свой отдельный пользовательский интерфейс и требует выполнения некоторой последовательности «сетевых» команд, индивидуальных для каждого приложения.
Ниже приведены некоторые примеры чисто сетевых приложений:
Эмуляция терминала была одним из первых чисто сетевых приложений. До появления сетей терминалы использовались для доступа к прикладным программам на больших ЭВМ и миникомпьютерах. Когда на смену терминалам пришли ПК, потребовался метод доступа к прикладным программам на существующих больших ЭВМ и миникомпьютерах. Программа эмуляции терминала позволяет представить ПК для большой ЭВМ как подключенный к ней терминал. Функции центрального процессора (ЦП) ПК становятся прозрачными для пользователя, и ему кажется, что он работает с ЦП большой ЭВМ, к которой данный ПК подсоединен. Эмуляция терминала предоставляет пользователю преимущества двух сред компьютерного мира. Приложения больших ЭВМ и миникомпьютеров могут выполняться на ПК наряду с обычными обособленными приложениями типа текстовых процессоров и электронных таблиц.
Передача файла является основным приложением практически во всех сетях. В некоторых случаях файлы, передаваемые от ПК одного типа к ПК другого типа, требуют перевода из одного формата данных в другой.
Электронная почта дает возможность пользователю ввести сообщение на ПК или локальной рабочей станции и оправить его к кому-нибудь по сети. Электронная почта является, возможно, одним из наиболее важных сетевых приложений. Она предоставляет путь, по которому сеть может улучшить межкорпоративные коммуникации.
Групповые приложения используют сети для электронной автоматизации административных функций современного офиса. Большинству крупных офисов присущи бесконечные попытки администраторов скоординировать работу. Групповые приложения позволяют пользователям координировать календарь, встречи, телефонные звонки и другие задачи электронным путем. Они могут предлагать чисто сетевые либо обособленные административные функции. Например, групповые приложения могут включать электронную почту как средство отправления и получения сообщений между сотрудниками. Так же может использоваться календарь для координации расписания работы сотрудников. Групповые приложения стремятся интегрировать эти функции без потерь для каждой из них.
Обособленные приложения
Все приложения, описанные выше, являются чисто сетевыми приложениями, разработанными для функционирования в сетевой среде. В последнее время многие известные обособленные приложения были адаптированы для функционирования в среде клиент-сервер.
Примерами могут служить текстовые процессоры, редакторы электронных таблиц, базы данных, презентационная графика и управление проектами.
Когда обособленные приложения адаптируются для работы в сетевой среде, они разбиваются на две части.
Первая часть приложения включает пользовательский интерфейс и связующую обработку и работает на станции-клиенте. Вторая часть приложения, работающая на сервере, включает операции, требующие значительных процессорных затрат.
Поводом к переводу традиционных обособленных приложений в сетевую среду послужили следующие соображения:
В сетевых версиях приложений используется тот же пользовательский интерфейс, включая команды оператора, что и в предыдущих обособленных версиях. В отличие от чисто сетевых приложений пользователям нет необходимости изучать новые команды для обеспечения нормальной работы.
Пользователи могут получать доступ к важным файлам, таким, как большие базы данных, сохраняемым в общем разделяемом пространстве. Поскольку только одна копия файла существует на сервере, то исчезает опасность дублирования файлов с различными датами модификации.
Некоторые ПК с ограниченными ресурсами (медленный ЦП, малая память) не могут обрабатывать целиком современные большие приложения. Однако если приложение разбивается на две части, то ПК может обрабатывать одну из этих частей, что известно как архитектура «клиент-сервер». Персональный компьютер («клиент») в общем случае обрабатывает часть пользовательского интерфейса от всего приложения, а более мощный компьютер («сервер») обрабатывает интенсивную процессорную часть и ввод/вывод (В/В) информации.
Новое серверное приложение не требуется для каждого пользователя. Если приложение уже существует на сервере, то новая часть пользовательского интерфейса для клиента – это все, что необходимо. Это обычно более дешево, чем использование всей программы для каждого пользователя.
На компьютерную сеть возложены две основные задачи:
1) возможность сотрудникам работать с одной информацией при выполнении разнородных задач(работа в одной команде);
2) возможность делить сотрудникам ресурсы сети (делить один принтер, сканер), что позволяет экономить средства предприятия.
Сетевые программы решают широкий спектр задач: анализ работоспособности сети, программного обеспечения; контроль за правильным использованием сетевых ресурсов; обеспечение информационной безопасности сети; организация общих сетевых ресурсов; инвентаризация оборудования и многое другое.
Сегодня каждая или почти каждая организация имеет свою сеть и диапазон проблем приблизительно одинаков. Для решения этих проблем есть системный администратор. Чтобы админу быть в курсе всех его происходящей работой в компьютерной сети, сетевые программы должны реагировать на все необычное в сети. Например, на отсутствие отклика какого-либо оборудования, т.к. это может свидетельствовать либо о его поломке, либо о проблемах с программным обеспечением.
При работе в сеты, часто источником информации является сервер организации, так как не целесообразно хранить информацию на каждой машине. И вот картина вы менеджер и вы проводите какую либо транзакцию, а сеть пропала и клиент начинает жаловаться на ваш сервис, хотя сеть не работала до этого 30 минут. А если у системного администратора есть программное обеспечение которое ему кричит и мигает нет сети, то уже заранее можно было-бы этой ситуации избежать, а не ждать злого клиента. Для решения этой цели есть множество различных программ для мониторинга сети.
Сетевые программы должны контролировать трафик организации, который выделен для каждого пользователя (дабы некий пользователь Пупкин в служебное время не качал файлы не понятного назначения), а также реальность скорости предоставления Интернета провайдером (дабы не было денег на ветер).
Также не оценимую помощь системному администратору сетевые программы дают по учету техники и комплектующих (так называемая инвентаризация). В нашем случае, когда речь уже дойдет о нематериальных активах компании, о ее собственности, важно довести до сведения системного администратора о произошедших проблемах.
Вывод: сетевые утилиты имеют своей целью предотвратить неисправность оборудования, а также решают проблему по своевременному оповещению системного администратора о возникающих проблемах сети.
Компьютер, подключенный к сети, может выполнять следующие типы приложений:
Очевидным преимуществом распределенных приложений является возможность распараллеливания вычислений, а также специализация компьютеров. Так, в приложении, предназначенном, скажем, для анализа климатических изменений, можно выделить три достаточно самостоятельные части (см. рис. в), допускающие распараллеливание.
Однако чтобы добиться всех тех преимуществ, которые сулят распределенные приложения, разработчикам этих приложений приходится решать множество проблем, например: на сколько частей следует разбить приложение, какие функции возложить на каждую часть, как организовать взаимодействие этих частей, чтобы в случае сбоев и отказов оставшиеся части корректно завершали работу и т. д., и т. п. Заметим, что все сетевые службы, включая файловую службу, службу печати, службу электронной почты, службу удаленного доступа, интернет-телефонию и т. д., по определению относятся к классу распределенных приложений.
Действительно, любая сетевая служба включает в себя клиентскую и серверную части, которые могут и обычно выполняются на разных компьютерах. На следующем рисунке иллюстрирующем распределенный характер веб-службы, мы видим различные виды клиентских устройств — персональные компьютеры, ноутбуки и мобильные телефоны — с установленными на них веб-браузерами, которые взаимодействуют по сети с веб-сервером. Таким образом, с одним и тем же веб-сайтом может одновременно работать множество — сотни и тысячи — сетевых пользователей.
Многочисленные примеры распределенных приложений можно встретить и в такой области, как обработка данных научных экспериментов. Это не удивительно, так как многие эксперименты порождают такие большие объемы данных, генерируемых в реальном масштабе времени, которые просто невозможно обработать на одном, даже очень мощном, суперкомпьютере. Кроме того, алгоритмы обработки экспериментальных данных часто легко распараллеливаются, что также важно для успешного применения взаимосвязанных компьютеров с целью решения какой-либо общей задачи. Одним из последних и очень известных примеров распределенного научного приложения является программное обеспечение обработки данных большого адронного коллайдера (Large Hadron Collider, LHC), запущенного 10 сентября 2008 года в CERN — это приложение работает более чем на 30 тысячах компьютеров, объединенных в сеть.
QoS (англ. Quality of Service — качество обслуживания) — этим термином в области компьютерных сетей называют вероятность того, что сеть связи соответствует заданному соглашению о трафике, или же, в ряде случаев, неформальное обозначение вероятности прохождения пакета между двумя точками сети.
Механизм работы
Для большинства случаев качество связи определяется четырьмя параметрами:
· Полоса пропускания (Bandwidth), описывает номинальную пропускную способность среды передачи информации, определяет ширину канала. Измеряется в bit/s (bps), kbit/s (Kbps), Mbit/s (Mbps), Gbit/s (Gbps).
· Задержка при передаче пакета (Delay), измеряется в миллисекундах.
· Колебания (дрожание) задержки при передаче пакетов — джиттер.
· Потеря пакетов (Packet loss). Определяет количество пакетов, потерянных в сети во время передачи.
Для простоты понимания канал связи можно представить в виде условной трубы, а пропускную способность описать как функцию двух параметров: диаметра трубы и её длины.
Когда передача данных сталкивается с проблемой «бутылочного горлышка» для приёма и отправки пакетов на маршрутизаторах, то обычно используется метод FIFO: первый пришел — первый ушёл (First In — First Out). При интенсивном трафике это создаёт заторы, которые разрешаются крайне простым образом: все пакеты, не вошедшие в буфер очереди FIFO (на вход или на выход), игнорируются маршрутизатором и, соответственно, теряются безвозвратно. Более разумный метод — использовать «умную» очередь, в которой приоритет у пакетов зависит от типа сервиса — ToS. Необходимое условие: пакеты должны уже нести метку типа сервиса для создания «умной» очереди. Обычные пользователи чаще всего сталкиваются с термином QoS в домашних маршрутизаторах с поддержкой QoS. Например, весьма логично дать высокий приоритет пакетам VoIP и низкий — пакетам FTP, SMTP и клиентам файлообменной сети.
Начинающему сетевому программисту
В общем, посмотрев на всё это, я решил написать базовую статью по созданию простейшего клиент-сервер приложения на С++ под Windows с детальным описанием всех используемых функций. Это приложение будет использовать Win32API и делать незамысловатую вещь, а именно: передавать сообщения от клиента к серверу и обратно, или, иначе говоря – напишем программу по реализации чата для двух пользователей.
Сразу оговорюсь, что статья рассчитана на начинающих программистов, которые только входят в сетевое программирование под Windows. Необходимые навыки – базовое знание С++, а также теоретическая подготовка по теме сетевых сокетов и стека технологии TCP/IP.
Теория сокетов за 30 секунд для «dummies»
Начну всё-таки немного с теории в стиле «for dummies». В любой современной операционной системе, все процессы инкапсулируются, т.е. скрываются друг от друга, и не имеют доступа к ресурсам друг друга. Однако существуют специальные разрешенные способы взаимодействия процессов между собой. Все эти способы взаимодействия процессов можно разделить на 3 группы: (1) сигнальные, (2) канальные и (3) разделяемая память.
Для того, чтобы сокеты заработали под Windows, необходимо при написании программы пройти следующие Этапы:
Инициализация сокетных интерфейсов Win32API.
Инициализация сокета, т.е. создание специальной структуры данных и её инициализация вызовом функции.
«Привязка» созданного сокета к конкретной паре IP-адрес/Порт – с этого момента данный сокет (его имя) будет ассоциироваться с конкретным процессом, который «висит» по указанному адресу и порту.
Для серверной части приложения: запуск процедуры «прослушки» подключений на привязанный сокет.
Для клиентской части приложения: запуск процедуры подключения к серверному сокету (должны знать его IP-адрес/Порт).
Акцепт / Подтверждение подключения (обычно на стороне сервера).
Обмен данными между процессами через установленное сокетное соединение.
Закрытие сокетного соединения.
Итак, попытаемся реализовать последовательность Этапов, указанных выше, для организации простейшего чата между клиентом и сервером. Запускаем Visual Studio, выбираем создание консольного проекта на С++ и поехали.
Этап 0: Подключение всех необходимых библиотек Win32API для работы с сокетами
Сокеты не являются «стандартными» инструментами разработки, поэтому для их активизации необходимо подключить ряд библиотек через заголовочные файлы, а именно:
WinSock2.h – заголовочный файл, содержащий актуальные реализации функций для работы с сокетами.
WS2tcpip.h – заголовочный файл, который содержит различные программные интерфейсы, связанные с работой протокола TCP/IP (переводы различных данных в формат, понимаемый протоколом и т.д.).
Также нам потребуется прилинковать к приложению динамическую библиотеку ядра ОС: ws2_32.dll. Делаем это через директиву компилятору: #pragma comment(lib, “ws2_32.lib”)
Ну и в конце Этапа 0 подключаем стандартные заголовочные файлы iostream и stdio.h
Итого по завершению Этапа 0 в Серверной и Клиентской частях приложения имеем:
Обратите внимание: имя системной библиотеки ws2_32.lib именно такое, как это указано выше. В Сети есть различные варианты написания имени данной библиотеки, что, возможно, связано иным написанием в более ранних версиях ОС Windows. Если вы используете Windows 10, то данная библиотека называется именно ws2_32.lib и находится в стандартной папке ОС: C:/Windows/System32 (проверьте наличие библиотеки у себя, заменив расширение с “lib” на “dll”).
Этап 1: Инициализация сокетных интерфейсов Win32API
Прежде чем непосредственно создать объект сокет, необходимо «запустить» программные интерфейсы для работы с ними. Под Windows это делается в два шага следующим образом:
Нужно определить с какой версией сокетов мы работаем (какую версию понимает наша ОС) и
Запустить программный интерфейс сокетов в Win32API. Ну либо расстроить пользователя тем, что ему не удастся поработать с сокетами до обновления системных библиотек
Итого код Этапа 1 следующий:
Да, кода мало, а описания много. Так обычно и бывает, когда хочешь глубоко в чем-то разобраться. Так что на лабе будешь в первых рядах.
Этап 2: Создание сокета и его инициализация
Тип сокета: обычно задается тип транспортного протокола TCP ( SOCK_STREAM ) или UDP ( SOCK_DGRAM ). Но бывают и так называемые «сырые» сокеты, функционал которых сам программист определяет в процессе использования. Тип обозначается SOCK_RAW
Тип протокола: необязательный параметр, если тип сокета указан как TCP или UDP – можно передать значение 0. Тут более детально останавливаться не будем, т.к. в 95% случаев используются типы сокетов TCP/UDP.
При необходимости подробно почитать про функцию socket() можно здесь.
Код Этапа 2 будет выглядеть так:
Этап 3: Привязка сокета к паре IP-адрес/Порт
Сокет уже существует, но еще неполноценный, т.к. ему не назначен внешний адрес, по которому его будут находить транспортные протоколы по заданию подключающихся процессов, а также не назначен порт, по которому эти подключающиеся процессы будут идентифицировать процесс-получатель.
В ней уже более понятные пользователю поля, а именно:
Технический массив на 8 байт ( sin_zero[8] )
Соответственно, ввод данных для структуры типа sockaddr_in выглядит следующим образом:
Создание структуры типа sockaddr_in : sockaddr_in servInfo;
Заполнение полей созданной структуры servInfo
В случае ошибки функция возвращает значение меньше 0.
Соответственно, если мы хотим привязать сокет к локальному серверу, то наш код по преобразованию IPv4 адреса будет выглядеть так:
erStat = inet_pton(AF_INET, “127.0.0.1”, &ip_to_num);
Результат перевода IP-адреса содержится в структуре ip_to_num. И далее мы передаем уже в нашу переменную типа sockaddr_in значение преобразованного адреса:
Этап 4 (для сервера): «Прослушивание» привязанного порта для идентификации подключений
После вызова данной функции исполнение программы приостанавливается до тех пор, пока не будет соединения с Клиентом, либо пока не будет возвращена ошибка прослушивания порта. Код Этапа 4 для Сервера:
Этап 4 (для Клиента). Организация подключения к серверу
Функция возвращает 0 в случае успешного подключения и код ошибки в ином случае.
Этап 5 (только для Сервера). Подтверждение подключения
Всё, соединение между Клиентом и Сервером установлено! Самое время попробовать передать информацию от Клиента к Серверу и обратно. Как мы в начале и договорились, мы будет реализовывать простейший чат между ними.
Этап 6: Передача данных между Клиентом и Сервером
Рассмотрим прототипы функций recv() и send() :
Флаги в большинстве случаев игнорируются – передается значение 0.
Функции возвращают количество переданных/полученных по факту байт.
Как видно из прототипов, по своей структуре и параметрам эти функции совершенно одинаковые. Что важно знать:
и та, и другая функции не гарантируют целостности отправленной/полученной информации. Это значит, что при реализации прикладных задач по взаимодействию Клиента и Сервера с их использованием требуется принимать дополнительные меры для контроля того, что все посланные байты действительно посланы и, что еще более важно, получены в том же объеме на другой стороне
предельно внимательно надо относиться к параметру «размер буфера». Он должен в точности равняться реальному количеству передаваемых байт. Если он будет отличаться, то есть риск потери части информации или «замусориванию» отправляемой порции данных, что ведет к автоматической поломке данных в процессе отправки/приёма. И совсем замечательно будет, если размер буфера по итогу работы функции равен возвращаемому значению функции – размеру принятых/отправленных байт.
В качестве буфера рекомендую использовать не классические массивы в С-стиле, а стандартный класс С++ типа char, т.к. он показал себя как более надежный и гибкий механизм при передаче данных, в особенности при передаче текстовых строк, где важен терминальный символ и «чистота» передаваемого массива.
Процесс непрерывного перехода от send() к recv() и обратно реализуется через бесконечный цикл, из которого совершается выход по вводу особой комбинации клавиш. Пример блока кода для Серверной части:
Пришло время показать итоговый рабочий код для Сервера и Клиента. Чтобы не загромождать и так большой текст дополнительным кодом, даю ссылки на код на GitHub:
Несколько важных финальных замечаний:
В итоговом коде я не использую проверку на точное получение отосланной информации, т.к. при единичной (не циклической) отсылке небольшого пакета информации накладные расходы на проверку его получения и отправку ответа будут выше, чем выгоды от такой проверки. Иными словами – такие пакеты теряются редко, а проверять их целостность и факт доставки очень долго.
При тестировании примера также видно, что чат рабочий, но очень уж несовершенный. Наиболее проблемное место – невозможность отправить сообщение пока другая сторона не ответила на твоё предыдущее сообщение. Суть проблемы в том, что после отсылки сообщения сторона-отправитель вызывает функцию recv(), которая, как я писал выше, блокирует исполнение последующего кода, в том числе блокирует вызов прерываний для осуществления ввода. Это приводит к тому, что набирать сообщение и что-то отправлять невозможно до тех пор, пока процесс не получит ответ от другой стороны, и вызов функции recv() не будет завершен. Благо введенная информация с клавиатуры не будет потеряна, а, накапливаясь в системном буфере ввода/вывода, будет выведена на экран как только блокировка со стороны recv() будет снята. Таким образом, мы реализовали так называемый прямой полудуплексный канал связи. Сделать его полностью дуплексным в голой сокетной архитектуре достаточно нетривиальная задача, частично решаемая за счет создания нескольких параллельно работающих потоков или нитей (threads) исполнения. Один поток будет принимать информацию, а второй – отправлять.
В последующих статьях я покажу реализацию полноценного чата между двумя сторонами (поможет разобраться в понятии «нити процесса»), а также покажу полноценную реализацию прикладного протокола по копированию файлов с Сервера на Клиент.
Сетевые приложения для стабильной работы компьютерных сетей
На компьютерную сеть возложены две основные задачи:
1) возможность сотрудникам работать с одной информацией при выполнении разнородных задач(работа в одной команде);
2) возможность делить сотрудникам ресурсы сети (делить один принтер, сканер), что позволяет экономить средства предприятия.
Сетевые программы решают широкий спектр задач: анализ работоспособности сети, программного обеспечения; контроль за правильным использованием сетевых ресурсов; обеспечение информационной безопасности сети; организация общих сетевых ресурсов; инвентаризация оборудования и многое другое.
Сегодня каждая или почти каждая организация имеет свою сеть и диапазон проблем приблизительно одинаков. Для решения этих проблем есть системный администратор. Чтобы админу быть в курсе всех его происходящей работой в компьютерной сети, сетевые программы должны реагировать на все необычное в сети. Например, на отсутствие отклика какого-либо оборудования, т.к. это может свидетельствовать либо о его поломке, либо о проблемах с программным обеспечением.
При работе в сеты, часто источником информации является сервер организации, так как не целесообразно хранить информацию на каждой машине. И вот картина вы менеджер и вы проводите какую либо транзакцию, а сеть пропала и клиент начинает жаловаться на ваш сервис, хотя сеть не работала до этого 30 минут. А если у системного администратора есть программное обеспечение которое ему кричит и мигает нет сети, то уже заранее можно было-бы этой ситуации избежать, а не ждать злого клиента. Для решения этой цели есть множество различных программ для мониторинга сети.
Сетевые программы должны контролировать трафик организации, который выделен для каждого пользователя (дабы некий пользователь Пупкин в служебное время не качал файлы не понятного назначения), а также реальность скорости предоставления Интернета провайдером (дабы не было денег на ветер).
Также не оценимую помощь системному администратору сетевые программы дают по учету техники и комплектующих (так называемая инвентаризация). В нашем случае, когда речь уже дойдет о нематериальных активах компании, о ее собственности, важно довести до сведения системного администратора о произошедших проблемах.
Вывод: сетевые утилиты имеют своей целью предотвратить неисправность оборудования, а также решают проблему по своевременному оповещению системного администратора о возникающих проблемах сети.
Понравилась полезная статья? Подпишитесь на RSS и получайте больше нужной информации!