Содержание:

Введение

Уже в 50-70-е годы XX века стало очевидно, что человечество вступает в новую эпоху, дорогу к которой проложил прогресс в развитии техники и в частности компьютеров из дорогого, медлительного и громоздкого устройства компьютер превратился сперва в персонального, позже переносного и наконец мобильного помощника.

Современную жизнь сложно представить без информационных технологий. Благодаря прогрессу в области микропроцессоров, сетей передачи данных и в частности беспроводных сетей, у каждого из нас в кармане есть мобильный телефон, постоянно подключенный к интернету, способный предоставить пользователю любые мыслимые сервисы: социальные сети, библиотеки музыки и книг, хранилища видеоматериалов и потоковых видео. Крупные современные сайты, вроде социальных сетей, могут обслуживать сотни миллионов пользователей. В основе этого лежат концепции распределенных систем.

Темой данной курсовой работы является модель организации распределенных систем «клиент-сервер», также известная как технология «клиент-сервер». Выбор темы данной курсовой работы для меня обусловлен её фундаментальностью и важностью для решения задач, как малых, так и крупных, вроде масштабирования распределенных систем. В рамках курсовой работы будут рассмотрены основные принципы, возможные формы организации архитектуры. Подробно будет рассмотрено использование для клиент-серверного взаимодействия протоколов TCP и UDP, их концепции, преимущества и недостатки в различных сценариях. Сложности при выборе архитектуры, и при построении многоуровневых и многозвенных архитектур. Будут рассмотрены популярные в прошлом принципы организации межсетевого взаимодействия компонентов системы, а также современные концепции, отвечающие нынешним вызовам: эффективности, производительности и надежности.

Для демонстрации технологии «клиент-сервер» мною будет разработано приложение-сервер и приложение-клиент, рассчитанные на взаимодействие через сеть, с минимальной функциональностью. Для разработки будет применен язык python версии 3.

Глава 1. Модель «клиент-сервер»

Глава 1.1. Описание модели клиент-сервер

Клиент-серверная модель – распределенная система, в которой задачи и нагрузки распределяются между поставщиками ресурсов или сервисов – называемых Сервера, и потребителями ресурсов именуемые клиенты. Зачастую клиенты и сервера представляют собой физически разные устройства, взаимодействующие с помощью компьютерной сети. Однако клиент и сервер могут быть частями одного устройства и взаимодействовать в его рамках. Устройство-сервер выполняет одну или несколько специализированный программ-серверов, которые предоставляют доступ к данным или службам для клиентов. Клиент не предоставляет никаких ресурсов, он запрашивает данные находящиеся на сервере или же какую-либо функцию сервера. Клиент инициирует соединение и начинает запрос данных, в то время как сервер ожидает входящего запроса.

В базовой модели клиент-сервер все процессы в распределенных системах делятся на две возможно перекрывающиеся группы. Процессы, реализующие некоторую службу, называются серверами (servers). Процессы, запрашивающие службы у серверов путем посылки запроса и последующего ожидания ответа от сервера, называются клиентами (clients). Такое взаимодействие клиента и сервера, известно также под названием режим работы запрос-ответ (request-reply behavior).^[1]

Программы-серверы ожидают от клиентских программ запросы и предоставляют им свои ресурсы в виде данных (например, загрузка файлов посредством HTTP, FTP, BitTorrent, потоковое мультимедиа или работа с базами данных) или в виде сервисных функций (например, работа с электронной почтой, общение посредством систем мгновенного обмена сообщениями или просмотр web-страниц во всемирной паутине).

Сама клиент-серверная архитектура зародилась ещё во времена терминалов доступа к мейнфреймам в 1960-1970х годах. И Описана в одном из ранних документов RFC 5^[2] В этой ранней документации используется терминология server-host и user-host вместо привычной клиент-сервер.

Глава 1.2. Разделение клиент-серверного программного обеспечения по уровням

Концепция слоев или уровней (layers) – одна из общеупотребительных моделей, используемых разработчиками программного обеспечения для разделения сложных систем на более простые части. В архитектурах компьютерных систем, например, различают слои кода на языке программирования, функций операционной системы, драйверов устройств, наборов инструкций центрального процессора и внутренней логики чипов. В среде сетевого взаимодействия протокол FTP работает на основе протокола TCP, который, в свою очередь, функционирует "поверх" протокола IP, расположенного "над" протоколом Ethernet.^[3]

Описывая систему в терминах архитектурных слоев, удобно воспринимать составляющие ее подсистемы в виде "слоеного пирога". Слой более высокого уровня пользуется службами, предоставляемыми нижележащим слоем, но тот не "осведомлен" о наличии соседнего верхнего слоя. Более того, обычно каждый промежуточный слой "скрывает" нижний слой от верхнего.

Расчленение системы на слои предоставляет целый ряд преимуществ.

- Отдельный слой можно воспринимать как единое самодостаточное целое, не особенно заботясь о наличии других слоев (скажем, для создания службы FTP необходимо знать протокол TCP, но не тонкости Ethernet).

- Можно выбирать альтернативную реализацию базовых слоев (приложения FTP способны работать без каких-либо изменений в среде Ethernet, по соединению РРР или в любой другой среде передачи информации).

- Зависимость между слоями можно свести к минимуму. Так, при смене среды передачи информации (при условии сохранения функциональности слоя IP) Служба FTP будет продолжать работать как ни в чем не бывало.

- Каждый слой является удачным кандидатом на стандартизацию (например, TCP и IP — стандарты, определяющие особенности функционирования соответствующих слоев системы сетевых коммуникаций).

- Созданный слой может служить основой для нескольких различных слоев более высокого уровня (протоколы TCP/IP используются приложениями FTP, telnet, SSH и HTTP). В противном случае для каждого протокола высокого уровня пришлось бы изобретать собственный протокол низкого уровня.^[4]

Однако схема расслоения обладает и определенными недостатками.

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

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

Четкого разделения между клиентом и сервером обычно нет. Например, сервер распределенной базы данных может выступать клиентом, передающим запросы на различные файловые серверы, отвечающие за реализацию таблиц этой базы данных. В этом случае сервер баз данных сам по себе не делает ничего, кроме обработки запросов. ^[6]

Тем не менее принято разделение на следующие уровни:

- уровень пользовательского интерфейса

- уровень обработки

- уровень данных

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

Уровень пользовательского интерфейса обычно реализуется на клиентах. Этот уровень содержит программы, посредством которых пользователь может взаимодействовать с приложением. Современные пользовательские интерфейсы поддерживают совместную работу приложений через единственное графическое окно и в ходе действий пользователя обеспечивают через это окно обмен данными.^[7]

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

Уровень данных в модели клиент-сервер содержит программы, которые предоставляют данные обрабатывающим их приложениям. Специфическим свойством этого уровня является требование сохранности – когда приложение не работает, данные должны сохраняться в определенном месте в расчете на дальнейшее использование. В простейшем случае уровень данных реализуется файловой системой. В модели клиент-сервер уровень данных обычно находится на стороне сервера.^[8]

Глава 1.3. Варианты архитектуры «клиент-сервер»

В простейшем варианте организации будет существовать всего два типа машин:

- Клиенты, выполняющие только пользовательский интерфейс.

- Серверы, реализующие всё остальное, уровень обработки и уровень данных.

Данная организация взаимодействия по своей сути не является распределенной системой: всё происходит на сервере, а клиент представляет собой лишь терминал. Распределение уровней такой организации отображено на рисунке 1, а. Передав клиенту полностью работу с пользовательским интерфейсом, мы полностью отделим от приложения-сервера графический внешний интерфейс. Организовав его взаимодействие с серверной частью приложения с помощью специфичного для данного приложения протокола (Рисунок 1, б). Мы так же можем перенести часть реализуемого приложением функционала на клиентскую сторону. К примеру, мы можем вынести функционал проверки правильности и соответствия шаблону вводимых данных. Данный вариант распределения функционала отображен на рисунке 1, в. Перечисленные организации распределения функционала клиента можно обобщить понятием «тонкий клиент».

Во многих системах клиент-сервер популярна организация, представленная на рисунке 1. г и д. Данные типы организации применяются в том случае, когда клиентская машина – соединена сетью с распределенной файловой системой или базой данных. Большая часть приложения работает на клиентской машине, а все операции с файлами или базой данных передаются на сервер. На рисунке 1, д отображена ситуация когда часть данных содержится на диске клиента, примером может служить веб-браузер, хранящий кэш наиболее часто посещаемых страниц.^[9] Организация распределения функционала клиента рассмотренная на рисунке 1, г и д может быть обобщенно названа «толстый клиент».

Рисунок 1. Различные формы организации архитектуры клиент-сервер(Источник: Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 76)

Рассмотренные выше архитектуры относятся к физически двухзвенным архитектурам.

В случае, если серверу понадобится работать в качестве клиента мы приходим к физически трехзвенной архитектуре.

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

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

Более популярным в настоящее время и более интересным является горизонтальное распределение. При таком типе распределения клиент и сервер могут содержать физически разделенные части логически однородного модуля, причем работа с каждой из частей может происходить независимо. Это позволяет выравнивать нагрузку.^[10]

Распространенным примером горизонтального распределения являются веб-сервера, реплицированные на несколько машин, и содержащие один и тот же набор веб страниц. Всякий раз, когда одна из страниц обновляется, изменения рассылаются на все серверы. Сервер, которому будет передан входящий запрос от пользователя, выбирается по алгоритму round-robin. Это простой алгоритм, заключающийся в цикличном переборе элементов.

Глава 1.4. Роль протоколов TCP и UDP в модели «клиент-сервер»

При реализации клиент-серверного приложения, работающего в рамках локальной сети, где показатель ошибок и потерь при передаче данных заведомо низок, вследствие меньшего количества промежуточных узлов, а также зачастую меньшей загруженности каналов, либо же при работе через высоконадежные глобальные каналы связи, взаимодействие может быть реализовано посредством простого протокола, не требующего установления соединения. Использование не требующего соединения протокола дает существенный выигрыш в эффективности. До тех пор пока сообщения не начнут пропадать или повреждаться, можно вполне успешно применять протокол типа запрос-ответ.^[11]

Таким протоколом является UDP (User Datagram Protocol) реализующий так называемый «ненадежный сервис по возможности», который не гарантирует доставку сообщений адресату. Протокол UDP добавляет к каждому отдельному сообщению свой 8-байтный заголовок, формируя из этих сообщений собственные протокольные единицы, называемые UDP-дейтаграммами, и передает их нижележащему протоколу IP.^[12]

Альтернативой данному протоколу является TCP (Transmission Control Protocol) надежный протокол с установкой соединения, подходящий для работы поверх менее стабильных глобальных каналов связи. При его использовании, прежде чем посылать запрос серверу, клиент должен установить с ним соединение. Сервер обычно использует это-же соединение для посылки ответного сообщения. Протокол TCP рассматривает информацию, поступающую к нему, как неструктурированный поток байтов. Из этого потока вырезается некоторая непрерывная часть данных, называемая сегментом и снабжается заголовком.^[13]

В отличии от протокола UDP, который создает свои дейтаграммы на основе логически обособленных единиц данных – сообщений, генерируемых приложениями, протокол TCP делит поток данных на сегменты без учета их смысла и внутренней структуры.^[14]

Заголовок TCP содержит значительно больше полей, чем заголовок UDP. Однобитные поля несущие служебную информацию называются флагами, или кодовыми битами. Следующие флаги являются ключевыми при рассмотрении работы протокола:

- SYN – запрос на установку соединения

- ACK – квитанция подтверждения на принятый сегмент

- RST – запрос на восстановление соединения

- FIN – признак достижения последнего байта в потоке

Так же ключевыми для работы протокола являются поля:

- Последовательный номер (sequence number) – номер первого байта данных в передаваемом сегменте

- Подтвержденный номер (Acknowledgement number) – номер последнего байта данных в передаваемом сегменте

Для обеспечения надежной передачи протокол TCP использует метод продвижения данных с установкой логического соединения. Логическое соединение состоит из двух потоков данных – от клиента серверу и от сервера к клиенту. Это позволяет участникам обмена данных следить за тем чтобы данные не были искажены, потеряны или продублированы, а также позволяет получателю восстановить правильную последовательность полученных данных.

Установление логического канала производится с помощью механизма трехстороннего квитирования. При установлении соединения, модули TCP участников обмена договариваются между собой о следующих параметрах:

- максимальный размер сегмента который сторона готова принимать

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

- начальный порядковый номер байта, с которого начинается отсчет потока данных в поле последовательный номер (sequence number)

Инициирует соединение клиент, отправляя сегмент, в котором флаг SYN установлен в 1 и указано номер последовательности X с которого будет вестись отсчет данных переданных клиентом.

Сервер отвечает сегментом с установленным флагом ACK, подтверждающим установку потока данных от клиента к серверу, поле подтвержденного номера увеличивается на единицы от значения начального номера последовательности X. Также устанавливается флаг SYN для запроса канала передачи данных от сервера к клиенту и указывается соответственно номер последовательности Y.

Последним этапом установки соединения клиент отвечает сегментом c установленным флагом ACK, и номером подтверждающей последовательности Y увеличенным на единицу.

После этого любая сторона может начать обмен данными или же разорвать связь, так как протокол TCP является методом одноранговой (равноправной) связи.

Размером окна называют количество сегментов, которое может быть передано в процессе ожидания подтверждения. После того как хост-машина передаст определяемое размером окна количество сегментов, она должна будет получить подтверждение и только потом сможет послать какие-либо другие сообщения. ^[15]

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

Рисунок 2. Пересылка данных в протоколе TCP при минимальном размере окна (Источник Основы организации сетей Cisco, том 1, испр. изд. : Пер. с англ. А.А. Голубченко — М. : Издательский дом "Вильямc", 2004. – стр 174)

Концепция скользящего окна (sliding window) заключается в том, что для повышения скорости передачи данных отправителю разрешается передать некоторое количество пакетов, не дожидаясь прихода на эти пакеты квитанций.^[16]

В протоколе TCP используются ожидательные подтверждения, означающие, что номер подтверждения соответствует октету, ожидаемому следующим. Слово "скользящее" в термине скользящее окно отражает тот факт, что размер окна согласуется динамически во время TCP-сеанса. Использование скользящего окна приводит к более эффективному использованию хост-машиной полосы пропускания, поскольку больший размер окна позволяет передавать больший объем данных, откладывая момент получения подтверждения. Схематически этот процесс изображен на рисунке 3.

Рисунок 3. Пересылка данных в TCP при увеличении размера окна.

Для использования в клиент-серверной модели так же было разработано расширение T/TCP, транзакционный протокол TCP или протокол TCP для транзакций.^[17] В части авторитетной литературы[4] данный протокол упоминается как перспективный. Тем не менее серьезного распространения он не получил, также было обнаружено много уязвимостей данного протокола.^[18] В 2011м году вместе с публикацией RFC 6247 данный протокол был признан устаревшим.^[19]

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

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

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

К примеру, компания Google в 2012 году представила собственный протокол QUIC работающий поверх протокола UDP и реализующий контроль получения и правильности данных при меньшей задержке и накладных расходах на заголовки пакетов. В дополнение протокол может производит шифрование передаваемых данных, а также не требует трехзвенного квитирования для начала передачи данных. ^[20] Протокол активно используется в сервисах компании, а его поддержка реализована в их браузере Google Chrome, являющимся самым популярным браузером^[21], а так же других браузерах основанных на общей с ним кодовой базе.

Другой известной реализацией контроля надежной доставки и переполнения поверх UDP является протокол μTP (произносится как мю-ти-пи, так же Micro Transport Protocol) разработанный компанией BitTorrent. Данный протокол был разработан и используется в программах пиринговых соединений (от пользователя к пользователю) и обмена файлами. Он позволяет производить более эффективный обмен данными и при этом меньше влиять на производительность других приложений, работающих поверх сети, за счет того, что в отличии от протокола TCP значительно быстрее обнаруживает перегрузку канала и освобождает его для других приложений.

Вывод по главе 1

В этой главе мною была модель клиент сервер, определение уровней модели и сложности с этим связанные, различные варианты её архитектуры. Были рассмотрены протоколы взаимодействия через сеть, их принципы, основные механизмы, преимущества и недостатки. Рассмотрены современные решения, позволяющие получить максимум преимуществ как протокола TCP так и протокола UDP.

Глава 2. Реализация простейшего приложения-сервера и клиента на языке Python 3

Глава 2.1. Постановка задачи

Для реализации примера архитектуры клиент-сервер мной был выбран язык Python, так как он является простым для освоения и при этом достаточно эффективным. Кроме того, язык является достаточно универсальным, и востребованным, применяется для реализации как простых скриптов и автоматизации, так и крупных решений, таких компаний как DropBox, Google^[22], Facebook^[23] и Instagram^[24]. Одной из любопытных особенностей данного языка является так называемая философия языка^[25] из которой выходит особенность синтаксиса. В Python, выделение блоков кода осуществляется с помощью отступов – пробелов и табуляции, то есть в языке отсутствуют привычные для других языков программирования операторные скобки (язык Паскаль) или фигурные скобки (язык Си). Подобный подход позволяет сократить количество строк и символов в программе, и как бы подталкивает к написанию «хорошего», легко читаемого кода. Плохо написанный код, к примеру написанный «сплошняком» без форматирования отступами просто на просто не заработает. Так же данный язык является мульти платформенным и позволяет разрабатывать ПО как для систем Microsoft Windows, для систем Mac OS, а так же для различных версий ОС Linux (и более того во многих дистрибутивах является предустановленным).

Мною будет использоваться версия Python 3.7.2, так как это последняя на данный момент и самая свежая версия, обладающая наиболее полным набором возможностей.^[26] Большая часть кода третьей версии языка совместима с интерпретаторами второй версии, однако существует и множество изменений и нюансов, необходимо это учитывать при портировании итогового кода в версию для Python 2.

Для упрощения разработки, отладки и рефакторинга кода мной будет использоваться среда разработки (IDE) от фирмы JetBrains – Pycharm 2018.2 (Community Edition). Это мощная и бесплатная среда разработки. Она так же обладает одним из преимуществ Python – мульти платформенностью.

Глава 2.2. Реализация приложения-сервера

Для начала будет разработано приложение-сервер, ожидающее подключение и выводящее в консоль сообщение о подключении, базовую информацию о клиенте, а также выводящее в консоль всю информацию, вводимую клиентом.

Для передачи данных от клиента к серверу, нам понадобится сетевое взаимодействие, реализуемое через сокеты (упрощенно сокетом можно считать пару IP-адрес и порт).

Выполним подключение стандартной библиотеки, отвечающей за взаимодействие с сокетами.

import socket

Далее необходимо создать сам объект сокета

serv_socket = socket.socket()

Следующим шагом будет связывание сокета с машиной на которой исполняется данных код, а так же необходимо выбрать номер используемого порта. Номер порта может быть любым от 0 до 65536, однако большинство операционных систем, требуют для использования портов от 0 до 1023 привилегии системного администратора. Во избежание этого выберем порт не входящий в этот диапазон, выбран порт – 3737. Создадим переменные, host и port, данные переменные позволят в будущем легко менять эти параметры. Значение переменной host оставляем пустым, это позволит принимать соединение от любых адресов. Непосредственно привязка выполняется с помощью встроенного в сокет метода – bind().

serv_socket.bind((host, port))

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

serv_socket.listen(1)

Принимаем входящее соединение при помощи метода accept(). Данный метод ожидает входящее соединение и возвращает номер соединения, адрес клиента и порт.

conn, addr = serv_socket.accept()

В объекте conn у нас сохраняется сокет, с помощью которого мы в дальнейшем сможем взаимодействовать с клиентом, в массиве addr – IP-адрес подключившегося клиента. Выведем в консоль информацию о подключении клиента

print('connected: ', addr)

Уже в данный момент клиент может подключиться к серверу, однако никак не сможет с ним взаимодействовать. Реализуем цикл, чтения порции данных от клиента. Читать данные от клиента мы будем порциями по 100 байт, именно этот параметр указывается методу recv(). Все входящие данные мы так же будем выводить в консоль, и так же отправлять их назад клиенту, предварительно переведя все символы в нижний регистр.

while True:

data = conn.recv(100)

if not data:

break

print('recieved data: ', data)

conn.send(data.lower())

По окончанию обмена закрываем соединение методом close()

conn.close()

Реализация простейшего серверного приложения готова.

Глава 2.2. Реализация приложения-клиента

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

import socket

client_socket = socket.socket()

server = '127.0.0.1'

port = 3737

client_socket.connect((server, port))

Для демонстрации передачи данных, клиент будет отсылать серверу строку «HELLO!!!» Сервер должен будет получить данную строку, привести её к нижнему регистру и отправить клиенту. После этого работа клиента и сервера будет завершена, а соединения закрыты..

client_socket.send('HELLO!!!'.encode())

data = client_socket.recv(100)

print(data)

client_socket.close()

Глава 2.3. Проверка работоспособности

Запустим сервер. Получим в консоль следующий вывод:

Рисунок 4. Окно запущенного серверного приложения

Сервер ожидает подключения. Запускаем клиент. Вывод сервера изменился, он сообщил о установлении соединения, и получении данных: строки «HELLO!!!» передал строку в нижнем регистре и завершил работу

Рисунок 5. Вывод информации о подключенном клиенте, строки полученной от клиента и успешном завершении работы

Клиент тем временем сообщил о получении строки «hello!!!» и также завершил работу

Рисунок 6. Вывод измененного сообщения полученного клиентом от сервера, а так же сообщение о успешном завершении работы

Вывод по главе 2

Мной были реализованы простые приложения сервер и клиент, продемонстрировавшие обмен сообщениями. В приложении 1 и 2 предоставлен полный листинг программ.

Заключение

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

Список литературы 

Мною были использованы следующие книги:

Архитектура корпоративных программных приложений.: Пер. с англ. – М.: Издательский дом "Вильямс", 2006.

В этой книге подробно рассматривается вопрос корпоративных программных решений. Автор на основании своего опыта, а так же на множество исследований и руководств представляет основные способы построения архитектуры приложений, особенности и способы взаимодействия с базами данных.

Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 5-е изд./В. Олифер Н. Олифер – СПб.: Питер, 2016.

Данная книга является крупным справочником, рассматривающим широкий спектр технологий и протоколов. Данный справочник рекомендован Министерством образования и науки Российской Федерации в качестве учебного пособия для студентов высших учебных заведений, обучающихся по направлению 552800 «Информатика и вычислительная техника» и по специальностям 220100 «Вычислительные машины, комплексы, системы и сети», 220200 «Автоматизированные системы обработки информации и управления» и 220400 «Программное обеспечение вычислительной техники и автоматизированных систем»

Основы организации сетей Cisco, том 1, испр. изд. : Пер. с англ.
А.А. Голубченко — М. : Издательский дом "Вильямc", 2004.

В книге подробно рассматриваются принципы организации сети на примере оборудования компании Cisco, имеющей длительный опыт разработки оборудования сетей и внесшей неоценимый вклад в развите отрасли и интернета в целом.

Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003.

Одна из книг известного в кругах информационных технологий преподавателя MIT (Масачусетского Технологического Института) а также разработчика операционной системы MiniX. Огромный опыт и глубочайшие познания этого человека не оставляли вариантов. Данная книга являлась основной при подготовке данной курсовой работы.

Список литературы

1. Архитектура корпоративных программных приложений.: Пер. с англ. – М.: Издательский дом "Вильямс", 2006. – 544 с.
2. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 5-е изд./В. Олифер Н. Олифер – СПб.: Питер, 2016. – 992 с.
3. Основы организации сетей Cisco, том 1, испр. изд. : Пер. с англ.
   А.А. Голубченко — М. : Издательский дом "Вильямc", 2004. – 512 с
4. Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – 877 с.
5. https://tools.ietf.org/html/rfc5
6. https://tools.ietf.org/html/rfc1644
7. https://tools.ietf.org/html/rfc6247
8. http://phrack.org/issues/53/6.html
9. https://blog.chromium.org/2013/06/experimenting-with-quic.html
10. https://netmarketshare.com/browser-market-share.aspx
11. https://opensource.googleblog.com/2017/01/grumpy-go-running-python.html
12. https://code.fb.com/production-engineering/python-in-production-engineering/
13. https://instagram-engineering.com/what-powers-instagram-hundreds-of-instances-dozens-of-technologies-adf2e22da2ad
14. https://www.python.org/dev/peps/pep-0020/
15. https://www.python.org

Приложения

Приложение 1. Листинг программы-сервера

import socket

serv_socket = socket.socket()

host = ''

port = 3737

serv_socket.bind((host, port))

serv_socket.listen(1)

conn, addr = serv_socket.accept()

print('connected: ', addr)

while True:

data = conn.recv(100)

if not data:

break

print('recieved data: ', data)

conn.send(data.lower())

conn.close()

Приложение 2. Листинг программы-клиента

import socket

client_socket = socket.socket()

server = '127.0.0.1'

port = 3737

client_socket.connect((server, port))

client_socket.send('HELLO!!!'.encode())

data = client_socket.recv(100)

print(data)

client_socket.close()

1. Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 67 ↑

2. https://tools.ietf.org/html/rfc5 ↑

3. Архитектура корпоративных программных приложений.: Пер. с англ. – М.: Издательский дом "Вильямс", 2006. – C 43 ↑

4. Архитектура корпоративных программных приложений.: Пер. с англ. – М.: Издательский дом "Вильямс", 2006. – C 43 ↑

5. Архитектура корпоративных программных приложений.: Пер. с англ. – М.: Издательский дом "Вильямс", 2006. – C 44 ↑

6. Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 72 ↑

7. Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 73 ↑

8. Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 74 ↑

9. Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 76 ↑

10. Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 77 ↑

11. Распределенные системы. Принципы и парадигмы/Э. Таненбаум, М. ван Стеен. – СПб.: Питер, 2003. – С 69 ↑

12. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 5-е изд./В. Олифер
    Н. Олифер – СПб.: Питер, 2016. – С 492 ↑

13. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 5-е изд./В. Олифер
    Н. Олифер – СПб.: Питер, 2016. – С 493 ↑

14. ↑

15. Основы организации сетей Cisco, том 1, испр. изд. : Пер. с англ.
    А.А. Голубченко — М. : Издательский дом "Вильямc", 2004. – стр 173 ↑

16. Компьютерные сети. Принципы, технологии, протоколы: учебник для вузов. 5-е изд./В. Олифер Н. Олифер – СПб.: Питер, 2016. – стр 501 ↑

17. https://tools.ietf.org/html/rfc1644 ↑

18. http://phrack.org/issues/53/6.html ↑

19. https://tools.ietf.org/html/rfc6247 ↑

20. https://blog.chromium.org/2013/06/experimenting-with-quic.html ↑

21. https://netmarketshare.com/browser-market-share.aspx (дата обращения: 24.12.2018) ↑

22. https://opensource.googleblog.com/2017/01/grumpy-go-running-python.html ↑

23. https://code.fb.com/production-engineering/python-in-production-engineering/ ↑

24. https://instagram-engineering.com/what-powers-instagram-hundreds-of-instances-dozens-of-technologies-adf2e22da2ad ↑

25. https://www.python.org/dev/peps/pep-0020/ ↑

26. https://www.python.org/downloads/ (дата обращения 24.12.2018) ↑