Программа типа клиент-сервер для TCP Программа типа

Программа типа клиент-сервер для TCP

Программа типа клиент-сервер для UDP

Программа сервера UDP

Программа сервера UDP

Программа сервера UDP

Программа клиента UDP

Программа клиента UDP

Программа клиента UDP

Клиент с установлением логического соединения (TCP) • Алгоритм: • Шаг 1. Найти IP адрес и номер порта протокола сервера, с которым необходимо установить связь. • Шаг 2. Распределить сокет. • Шаг 3. Указать, что для соединения нужен произвольный, неиспользуемый порт протокола на локальном компьютере, и позволить программному обеспечению TCP выбрать такой порт. • Шаг 4. Подключить сокет к серверу. • Шаг 5. Выполнять обмен данными с сервером по протоколу прикладного уровня. • Шаг 6. Закрыть соединение.

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

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

Проблема выбора локального IP-адреса • Для решения этой проблемы предусмотрена возможность оставлять незаполненным поле локального IP адреса и предоставлять ПО стека TCP/IP возможность выбрать локальный IP адрес автоматически во время подключения клиента к серверу. • Замечание: На практике может создаваться впечатление, что клиентская программа работает правильно, даже если выбран неправильный адрес локальной оконечной точки, поскольку пакеты все равно передаются на клиентский компьютер, хотя и возможно по маршруту, отличному от того, по какому они передаются на сервер. Однако использование неправильного адреса является нарушением спецификации протоколов, затрудняет и вносит путаницу в управление сетью, а также приводит к снижению надежности программы.

Подключение сокета TCP к серверу • Системный вызов connect позволяет клиенту TCP инициировать соединение. Вызов функции connect инициирует процедуру тройного рукопожатия и не возвращает управление до тех пор, пока не будет установлено соединение TCP или не закончится время ожидания. • Функция connect выполняет следующие задачи. 1) Проверяет, является ли действительным указанный сокет и не был ли он уже подключен. 2) Заполняет поле адреса удаленной оконечной точки в дескрипторе сокета. 3) Выбирает адрес локальной оконечной точки для соединения, если в дескрипторе сокета это значение не было задано.

Взаимодействие с сервером с использованием протокола TCP При условии, что вызов функции connect привел к успешному созданию соединения, клиент может использовать это соединение для обмена данными с сервером. • Пример: • • • • #define BLEN 120 /* Длина используемого буфера */ char *req = "request of some sort"; char buf[BLEN] ; /* Буфер для ответа */ char *bptr; /* Указатель на буфер */ int n; /* Количество считанных байтов */ int buflen; /* Место, оставшееся в буфере */ bptr = buf; buflen = BLEN; send(s, req, strlen(req), 0); /* Отправить запрос */ /* Получить ответ (может состоять из нескольких фрагментов) */ while((n = recv(s, bptr, buflen, 0)) > 0) { bptr+= n; buflen–= n; }

Закрытие соединения TCP • Закрытие соединения может оказаться в сложной задачей, поскольку протокол TCP допускает двухстороннюю связь. Поэтому для закрытия соединения требуется координация действий клиента и сервера. • Для решения проблемы закрытия соединения существует функция shutdown, позволяющая закрывать соединение TCP в одном направлении. Функция принимает два параметра (дескриптор сокета s и спецификацию направления direction. • Параметр direction представляет собой целое число. Если он содержит SHUT_RD, то дальнейший ввод будет запрещен. Если он содержит SHUT_WR, будет запрещен дальнейший вывод. И наконец, если значение этого параметра равно SHUT_RDWR, соединение закрывается в обоих направлениях. • После того как клиент заканчивает отправку запросов, он может использовать функцию shutdown для указания того, что не имеет больше данных для передачи, не освобождая сокет. При этом сервер получает сигнал об обнаружении конца файла. После отправки последнего ответа сервер может закрыть соединение.

Клиент без установления логического соединения (UDP) Алгоритм: • Шаг 1. Найти IP адрес и номер порта протокола сервера, с которым необходимо установить связь. • Шаг 2. Распределить сокет. • Шаг 3. Указать, что для соединения нужен произвольный, неиспользуемый порт протокола на локальном компьютере, и позволить программному обеспечению UDP выбрать такой порт. • Шаг 4. Указать сервер, на который должны передаваться сообщения. • Шаг 5. Выполнять обмен данными с сервером по протоколу прикладного уровня. • Шаг 6. Закрыть сокет.

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

Подключенные и неподключенные сокеты UDP В неподключенном режиме клиентская программа не подключает сокет к указанной удаленной оконечной точке, а задает удаленный адрес назначения при отправке каждого сообщения (функции sendto/recvfrom). Преимуществом неподключенных сокетов является свобода выбора адресата, поскольку решение о передаче данных на конкретный сервер может быть отложено до того, как поступит запрос, предназначенный для отправки. Кроме того, клиентская программа может отправлять каждый запрос на другой сервер.

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

Обмен данными с сервером UDP • В отличии от TCP, протокол UDP предусматривает передачу не потока данных, а сообщений. • При каждом вызове функции send ПО UDP передает единственное сообщение, содержащее все данные, переданные функции send. • Аналогичным образом, каждый вызов функции recv приводит к получению одного полного сообщения. При условии, что в клиенте определен достаточно большой буфер, вызов функции recv возвращает все данные из последнего входящего сообщения. Поэтому в клиенте UDP нет необходимости предусматривать повторные вызовы функции recv для получения одного сообщения.

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

Алгоритмы серверного программного обеспечения Каждый сервер функционирует в соответствии со следующим алгоритмом: • создается сокет и выполняется привязка сокета к общепринятому порту. • Затем сервер входит в бесконечный цикл, в котором он принимает очередной запрос, поступающий от клиента, обрабатывает этот запрос, формирует ответ и отправляет его клиенту. • Модель: клиент 1 (запрос на 1 MB), клиент 2 (запрос на 100 MB)

Алгоритмы серверного программного обеспечения • Параллельный сервер — это сервер, который обрабатывает сразу несколько запросов. Применяется параллельная обработка, обычно основанная на использовании нескольких потоков выполнения, при которой каждый поток обрабатывает отдельный запрос. • Возможны и другие реализации параллельной работы, выбор конкретного метода зависит от прикладного протокола. • • В частности, если сервер выполняет небольшой объем обработки по сравнению с объемом выполняемых операций ввода/вывода, существует возможность реализовать такой сервер в виде единого потока выполнения, в котором используется асинхронный ввод/вывод для обеспечения одновременного применения нескольких каналов связи.

Четыре основных типа серверов • Последовательный без установления логического соединения • Последовательный с установлением логического соединения • Параллельный без установления логического соединения • Параллельный с установлением логического соединения

Последовательный сервер с установлением логического соединения Алгоритм: • Шаг 1. Создать сокет и связать его с общепринятым портом предоставляемой службы. • Шаг 2. Перевести сокет в пассивный режим. • Шаг 3. Принять из сокета следующий запрос на установление соединения и получить новый сокет для соединения. • Шаг 4. Считывать в цикле запросы от клиента, формировать ответы и отправлять клиенту в соответствии с прикладным протоколом. • Шаг 5. После завершения обмена данными с конкретным клиентом закрыть соединение и возвратиться на шаг 3. Замечание: Выбор конкретного IP адреса, через который сервер будет принимать запросы на установление соединения, может оказаться сложным. Для решения этой проблемы в интерфейсе сокетов определена специальная константа INADDR_ANY, которая может использоваться вместо IP-адреса. Эта константа задает шаблон адреса, который соответствует любому из IP-адресов хоста.

Последовательный сервер без установления логического соединения Последовательные серверы в наибольшей степени подходят для создания служб, характеризующихся минимальными затратами времени на обработку запроса. Поэтому в большинстве последовательных серверов используется транспортный протокол без установления логического соединения. Алгоритм: • Шаг 1. Создать сокет и связать его с общепринятым портом предоставляемой службы. • Шаг 2. Считывать в цикле запросы от клиента, формировать ответы и отправлять клиенту в соответствии с прикладным протоколом. В сервере без установления логического соединения применяется неподключенный сокет. В нем явно формируются адреса ответов и используется вызов функции сокетов sendto для указания и передаваемой дейтаграммы, и адреса, по которому она должна быть передана.

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

Параллельный сервер без установления логического соединения Алгоритм: • • Ведущий поток. Шаг 1. Создать сокет и выполнить его привязку к общепринятому адресу предоставляемой службы. Оставить сокет неподключенным. Шаг 2. Вызывать в цикле функцию recvfrom для приема очередно го запроса от клиента и создать новый ведомый поток для формирования ответа. Ведомый поток. Шаг 0. Получен конкретный запрос от ведущего потока и доступ к сокету. Шаг 1. Сформировать ответ согласно прикладному протоколу и отправить его клиенту с использованием функции sendto. Шаг 2. Завершить работу. Необходимо учитывать, что операция создания нового потока выполнения может оказаться дорогостоящей. При использовании протокола без установления логического соединения необходимо убедиться, что затраты, связанные с обеспечением параллельной работы, оправдывают достигнутое повышение скорости.

Параллельный сервер с установлением логического соединения Алгоритм: • Ведущий поток. • Шаг 1. Создать сокет и выполнить его привязку к общепринятому порту предоставляемой службы. Оставить сокет неподключенным. • Шаг 2. Перевести сокет в пассивный режим. • Шаг 3. Вызывать в цикле функцию accept для получения очередного запроса от клиента и создавать новый ведомый поток для формирования ответа. • • Ведомый поток. Шаг 0. Получения доступ к сокету соединения от ведущего потока. Шаг 1. Выполнить обмен данными с клиентом через соединение. Шаг 2. Закрыть соединение и завершить работу.

Способы обеспечения параллельной работы сервера • В ОС Linux предусмотрены две формы организации параллельной работы: процессы и потоки. (Применяются два способа реализации принципа работы "ведущий/ведомый") • В одной реализации сервер создает несколько процессов, содержащих по одному потоку выполнения. • В другой сервер создает несколько потоков выполнения в одном процессе.

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

Функция fork() • /* Создаем ведущий сокет, привязываем его к общепринятому порту и переводим в пассивный режим */ • • • • • for( ; ; ) { if(sock. Client = accept(sock. Main, (struct sockaddr *)&fsin, &len))<0) { /* Сообщение об ошибке */ exit(1); } if(child=fork())<0) { /* Сообщение об ошибке */ exit(1); } else if(child = = 0) { close(sock. Main); /* Обработка поступившего запроса процессом */ close(sock. Client); exit(0); } close(sock. Client); } }

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

Параллельный сервер с установлением логического соединения, реализованный в виде одного потока выполнения Алгоритм: • Шаг 1. Создать сокет и привязать его к общепринятому порту предоставляемой службы. Добавить сокет к списку сокетов, через которые может осуществляться ввод/вывод. • Шаг 2. Использовать функцию select для получения информации о готовности существующих сокетов к вводу/выводу. • Шаг 3. Если готов первоначальный сокет, использовать функцию accept для получения очередного запроса на установление соединения и добавить новый сокет к списку сокетов, через которые может осуществляться ввод/вывод. • Шаг 4. Если готов сокет, отличный от первоначального, использовать функцию recv или read для получения очередного запроса, сформировать ответ и передать ответ клиенту с использованием функции send или write. • Шаг 5. Продолжить обработку запросов, начиная с шага 2.

Области применения серверов различных типов Последовательный или параллельный? • Последовательные серверы проще в проектировании, реализации и сопровождении, • но параллельные серверы могут (!? ) обеспечить более быстрый отклик на запросы. • Последовательная реализация применяется, если время обработки запросов невелико и последовательное решение обеспечивает достаточно быстрое время отклика для рассматриваемого приложения.

Действительно - параллельный или псевдопараллельный? • В сервере с одним потоком выполнения для поддержки сразу нескольких соединений может применяться асинхронный ввод/вывод, • а многопотоковая реализация, основанная на использовании нескольких однопотоковых процессов или нескольких потоков в одном процессе, позволяет автоматически обеспечить параллельную работу с использованием средств операционной системы.

Действительно - параллельный или псевдопараллельный? • Однопотоковое, псевдопараллельное решение применяется, если создание или переключение между потоками требует больших затрат, а сервер должен обеспечить совместное использование данных или обмен данными между соединениями. • Многопотоковое решение применяется, если сервер должен обеспечить совместное использование или обмен данными между соединениями, а использование потоков не требует больших затрат. • Мультипроцессное решение применяется, если каждый ведомый поток может работать в изоляции от других; такое решение может также применяться для достижения максимального распараллеливания (например, в многопроцессорной системе).

С установлением или без установления логического соединения? • • Поскольку доступ с установлением логического соединения подразумевает использование протокола TCP, он также подразумевает и надежную доставку, а транспортный протокол без установления логического соединения (UDP) не может обеспечить надежную доставку. • При использовании транспортного протокола без установления логического соединения требуемая надежность может быть достигнута, только если функции повышения надежности реализованы в прикладном протоколе или каждый клиент обращается к своему серверу по локальной сети, которая характеризуется исключительно низкими потерями и отсутствием переупорядочения пакетов. • Если между клиентом и сервером лежит распределенная сеть, для связи между ними должен применяться транспортный протокол с установлением логического соединения. Клиент и сервер без установления логического соединения нельзя переносить в среду глобальной сети без проверки способности прикладного протокола обеспечить требуемую надежность.

Проблема тупиковых ситуаций в работе сервера • Рассмотрим последовательный сервер с установлением логического соединения. • Предположим, что клиентское приложение (например, С) выполняет недопустимые действия. В простейшем случае предположим, что приложение С формирует соединение с сервером, но не присылает никаких запросов. Сервер принимает запрос на установление соединения и вызывает функцию recv или read для получения ожидаемого запроса. • Серверная программа заблокируется в этом системном вызове, ожидая запроса, который никогда не поступит.

Проблема тупиковых ситуаций в работе сервера • • • Тупиковая ситуация в сервере может возникнуть, если клиенты действуют неправильно, не считывая отправленные сервером ответы. Например, предположим, что клиент С установил соединение с сервером, передал ему ряд запросов, но не прочитал ни одного ответа. • Сервер принял один за другим запросы, сформировал ответы и отправил их клиенту. Применяемое на сервере программное обеспечение протокола TCP выполнило передачу нескольких первых байтов через соединение с клиентом. • В этот момент вступает в действие механизм управления потоком данных TCP. После заполнения буфера приема данных клиента протокол TCP прекращает передачу данных. Серверная прикладная программа продолжает формировать ответы. • • Локальный выходной буфер TCP, применяемый программным обеспечением этого протокола для хранения исходящих данных соединения, заполняется, а сервер блокируется.

Проблема тупиковых ситуаций в работе сервера Тупиковая ситуация возникает в связи с тем, что при отсутствии возможности выполнения ОС системного вызова вызывающая программа блокируется. • В частности, при вызове функции send или write вызывающая программа блокируется, если программное обеспечение TCP не имеет свободного локального буферного пространства для размещения передаваемых данных, а при вызове функции recv или read вызывающая программа блокируется до тех пор, пока программное обеспечение TCP не получит данные. В параллельных серверах блокируется только один ведомый поток, связанный с конкретным клиентом, если этот клиент окажется не в состоянии отправлять запросы или читать ответы. Однако в реализациях, основанных на использовании одного потока выполнения, блокируется весь сервер. • После возникновения блокировки сервер теряет способность поддерживать остальные соединения. Это означает, что любой сервер, в котором используется только один поток, может оказаться в тупиковой ситуации.