Linuxformat - Вклад участника [ru]

LXF82:Python

2009-02-08T13:53:33Z

AndrewDjVu: /* HTTP */

{{цикл/Python}}

== РАЗРАБОТКА клиент-серверных приложений ==
''ЧАСТЬ 2 Вознамерились написать открытую альтернативу Skype или собственный клиент BitTorrent? '''Сергей Супрунов''' научит всему необходимому – от основ архитектуры «клиент-сервер» до готовых библиотек для работы с существующими интернет-протоколами.''

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

=== Клиент всегда прав ===
{{Врезка
|Заголовок=UDP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
from socket import *
hostname = sys.argv[1]
HEADER = '\x00\x01\x00\x00\x00\x01'
HEADER += '\x00\x00\x00\x00\x00\x00'
QUESTION = ''
parts = hostname.split('.')
for p in parts:
QUESTION += '%c%s' % (chr(len(p)), p)
QUESTION += '\x00\x00\x01\x00\x01'
QUERY = HEADER + QUESTION
cs = socket(AF_INET, SOCK_DGRAM)
cs.sendto(QUERY, ('127.0.0.1', 53))
rsp = cs.recv(1024)
start = len(QUERY) + 12
print '%s.%s.%s.%s' % (ord(rsp[start]),
ord(rsp[start+1]),
ord(rsp[start+2]),
ord(rsp[start+3]))</source>
|Ширина=310px}}
Наиболее распространенным способом взаимодействия двух приложений через сеть являются уже знакомые нам сокеты. Модуль
socket, входящий в стандартную поставку Python, помимо рассмотренных в прошлый раз Unix-сокетов поддерживает также сокеты
домена Internet. Методология использования мало чем отличается от
Unix-сокетов, за исключением того, что вместо параметра AF_UNIX
используется AF_INET, а вместо имени файла указываются имя хоста
и номер порта, которые будут обслуживаться создаваемым сокетом.

В качестве второго параметра в конструкторе сокета можно указать
его тип: с установлением соединения, соответствующий протоколу TCP,
или без соединения – протокол UDP. Допустимые значения – SOCK_STREAM и SOCK_DGRAM соответственно. По умолчанию подразумевается SOCK_STREAM.

Как пример, рассмотрим работу приложения, выполняющего роль
примитивного (и весьма ограниченного функционально) клиента DNS,
работающего по протоколу UDP (см. листинг udp-client.py).

Некоторую сложность здесь представляет то, что DNS относится к
так называемым «двоичным» протоколам, в отличие от «текстовых»,
таких как HTTP или SMTP, где обмен идет обычными текстовыми строками. В случае с DNS оперировать приходится «сырыми» байтами.
Сведения по формату сообщений можно почерпнуть из RFC 1035, раздел «4. MESSAGES».

В 6-й и 7-й строках рассматриваемого кода формируется заголовок
(12 байт). Пренебрегая всем богатством возможностей протокола DNS,
мы ограничиваемся простым запросом (OPCODE=0) одного доменного
имени (QDCOUNT=1). Конструкции вида «\x00» позволяют задать в
строке произвольный шестнадцатиричный код.

В строках 8–12 формируется поле запроса. Оно состоит из частей
доменного имени (в оригинале разделенных точками), перед которыми
указывается число символов в этой части. Например, имя mail.ru состоит из двух частей (mail – 4 символа, ru – 2 символа) и в запросе должно выглядеть так: \x04mail\x02ru\x00. Завершающий ноль, а также
два двухбайтовых поля (QTYPE и QCLASS) добавляются к переменной
QUESTION в строке 12.

Наконец, строки 14 и 15 – создание сокета (обратите внимание на
второй параметр, SOCK_DGRAM, указывающий тип транспортного протокола UDP) и отправка запроса. Поскольку UDP работает без установки
соединения, то вместо знакомой нам пары методов «connect – send» мы
используем один «sendto», в котором указывается сразу и отправляемая информация, и адрес получателя. В данном примере предполагается, что DNS-сервер работает на локальной машине. Вы можете указать
здесь свой DNS-сервер или передавать его имя в качестве параметра.

И в строках 17–21 из всей полезной информации, возвращаемой
сервером, мы, игнорируя любые возможные ошибки, выбираем только
IP-адрес, размещаемый по смещению, которое формируется в переменной start. Результат работы:
serg$ ./udp-client.py donpac.ru
80.254.111.2

=== Всегда к вашим услугам ===
{{Врезка
|Заголовок=IAMOK.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import os, re
from socket import *
class IamOK:
def __init__(self, host='localhost', port=12345):
self.socket = socket(AF_INET, SOCK_STREAM)
self.socket.bind((host, port))
self.socket.listen(5)
def process(self):
while 1:
csocket, caddress = self.socket.accept()
csocket.send('IamOK server v.0.0. Ready to serve.\n')
csocket.send('You are from %s, port %s...\n' % caddress)
while 1:
request = csocket.recv(64)
if re.match('get\s+uptime', request, re.IGNORECASE):
csocket.send(os.popen('/usr/bin/uptime').read())
elif re.match('quit|bye|exit', request, re.IGNORECASE):
break
else:
csocket.send('Unknown command.\n')
csocket.close()
if __name__ == '__main__':
serv = IamOK()
serv.process()
</source>
|Ширина=550px}}
В качестве примера сервера, на этот раз работающего по протоколу TCP,
рассмотрим такой код (см Листинг iamok.py).

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

Здесь все должно быть понятно по прошлому уроку. Два отличия – в конструкторе socket.socket() указывается второй параметр –
SOCK_STREAM (в данном случае его можно было бы и опустить, т.к.
для Internet-домена и так по умолчанию используется протокол TCP).
И метод bind() осуществляет привязку сокета не к файлу, а к имени
хоста и номеру порта, на котором будут ожидаться входящие соединения. Кстати, выбирая номер порта, не забывайте, что порты до 1024-го
относятся к привилегированным и могут быть задействованы только
пользователем root.

Наш сервер понимает две команды: «get uptime», по которой возвращается информация о времени работы сервера, и «quit» (с двумя
синонимами – «bye» и «exit»), по которой сеанс завершается.

Проверить работу сервера можно с помощью обычной
telnet-сессии:
<source lang="text">
admin@dom:~/lxf/propy/l2$ telnet localhost 12345
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is ‘^]’.
IamOK server v.0.0. Ready to serve.
You are from 127.0.0.1, port 2650...
helo
Unknown command.
get uptime
23:09:26 up 58 min, 3 users, load average: 0.04, 0.15, 0.63
quit
Connection closed by foreign host.
</source>
Какая от этого может быть польза – решайте сами.

=== «Гуртом и батьку бить веселей» ===
{{Врезка
|Заголовок=THREAD-TEST.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import threading as t
import time, re
diskbusy = t.Lock()
def parseit(lognum):
global errors, total
diskbusy.acquire()
log = open('logs/syslog.%d' % lognum)
lines = log.readlines()
diskbusy.release()
for line in lines:
if re.search('failed|error', line):
errors += 1
total += 1
class ParseLog(t.Thread):
def __init__(self, num):
self.lognum = num
t.Thread.__init__(self)
def run(self):
parseit(self.lognum)
#------------------ 1
def test1():
global errors, total
errors = total = 0
for i in range(10):
parseit(i)
print errors, total
#------------------ 2
def test2():
global errors, total
errors = total = 0
running = []
for i in range(10):
tr = ParseLog(i)
tr.start()
running.append(tr)
for tr in running:
tr.join()
print errors, total

start = time.time()
test1()
print 'Послед.: %f' % (time.time() - start)
start = time.time()
test2()
print 'Потоки: %f' % (time.time() - start)
</source>
|Ширина=350px}}
Потоки, наряду с рассмотренными ранее процессами, являются эффективным способом параллельного выполнения различных задач. В
ряде случаев этим можно воспользоваться не только для одновременного обслуживания нескольких подключений в клиент-серверных
приложениях, но и для повышения производительности «автономных»
программ.

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

В стандартной поставке Python для работы с потоками есть два
модуля – thread и threading. Первый позволяет управлять потоками на
достаточно низком уровне, второй – использует средства первого для
предоставления более удобного объектно-ориентированного интерфейса. Класс threading.Thread предоставляет «шаблон» потока. Для его
использования в своей программе вам нужно переопределить метод
run(), описав в нем действия, которые должны выполняться этим потоком. Ниже приведен пример, из которого все должно стать понятно.

Нужно заметить, что при распараллеливании «в лоб», когда просто
запускается сразу несколько потоков, по одному на каждый обрабатываемый файл, нас поджидает один неприятный сюрприз (можете
проверить это на досуге) – при старте сценария все созданные потоки
одновременно попытаются выполнить чтение нужных им для дальнейшей работы данных. Это приведет к жесткой конкуренции за право переместить головки винчестера в нужное место и вызовет, вопреки ожидаемому, катастрофическое падение производительности. Если размеры
файлов сопоставимы с объемом оперативной памяти, система, ко всему
прочему, может «впасть в своппинг», когда считанные одним потоком
данные будут тут же записываться на диск, чтобы освободить место для
данных другого потока.

Вот если бы нам удалось организовать работу потоков таким образом, чтобы, пока один из них выполняет чтение файла, другие не обращались к диску... Для решения этой задачи в языке Python доступно
несколько средств синхронизации работы потоков.
Простейшее из них – использование обычных переменных-флагов.
Как вы помните, потоки разделяют оперативную память, принадлежащую процессу, в рамках которого они исполняются, так что изменения
переменных будут «видны» всем процессам. Идея здесь проста:
<source lang="python">
if DISKBUSY:
# ожидание
else:
DISKBUSY = 1
# чтение файла
DISKBUSY = 0
</source>
То есть первый поток выставит истинное значение глобальной переменной DISKBUSY и приступит к чтению файла. «Опоздавшие» потоки
будут ждать, пока переменная вновь не примет значение «ложь».

В такой реализации программисту предстоит решить не такую уж
простую, как может показаться на первый взгляд, задачу – грамотно
обеспечить ожидание. Бесконечный цикл проверки значения переменной слишком сильно нагружает процессор (не даром такие циклы
называют напряженными). Напрашивающееся time.sleep(1) очень
не эффективно – если ресурс освободится до того, как истечет время «спячки», то он будет простаивать. [Кроме того, подобный метод
синхронизации сам по себе не атомарен – подробности ищите в статье
«[[LXF82:Unix API|Очереди сообщений и семафоры]]»]

Однако в модуле threading есть готовая реализация описанной
выше идеи – класс Lock, который предоставляет программисту так
называемые блокировки, иногда именуемые «мьютексами» (mutex).
Идя проста – создается объект данного класса (threading.Lock()),
который имеет два метода: acquire() позволяет захватить объект,
release() – освободить его. Метод aquire() является блокирующим:
очередной поток, вызвавший его, будет ждать до тех пор, пока мьютекс
не освободится.

Дальнейшим развитием идеи блокировок являются семафоры.
Фактически, семафор – это тот же мьютекс, но позволяющий захватить себя несколько раз. Если вы создадите семафор командой
semaphore = threading.Semaphore(3), то его смогут захватить (тем
же методом semaphore.acquire()) одновременно три потока (каждый раз отнимая по единице из указанного при инициализации числа).
Четвертый поток сможет захватить семафор только после того, как он
будет высвобожден (semaphore.release()) одним из тех, которые
удерживают его в настоящее время.

Впрочем, для нашей задачи лучше всего подходят мьютексы – диск
объявим неразделяемым ресурсом, и посмотрим, какой выигрыш по
времени это нам даст (см. листинг thread-test.py).

Здесь мы проводим два теста – последовательная обработка (1) и
использование потоков с эксклюзивным доступом к диску (2). В строках
16–21 мы создаем подкласс класса Thread, в котором переопределяем
метод run(). Запуск потока выполняется в строке 36. Обратите внимание
на список running (строки 33, 37–39). С его помощью мы отслеживаем активность потоков – метод join() заставляет ждать, пока поток не
завершит свою работу. Дальнейшая работа основного сценария продолжится только после того, как отработают все порожденные потоки.

В строке 5 мы создаем мьютекс, с помощью которого в строках 8 и 11
будет регулироваться доступ потоков к диску. В глобальной переменной
errors ведется подсчет числа строк, в которых есть подстрока «failed» или
«error», в total – общее число обработанных строк. Результат работы:
21931 2302755 Послед.: 33.271387
21931 2302755 Потоки: 22.867245
Как видите, мы получили выигрыш по времени более чем на 30%.
Но нужно заметить, что распараллеливание подобных скриптов даст
заметный эффект только в том случае, если нагрузка на дисковую систему сопоставима с нагрузкой на процессор. Если какой-то из ресурсов
будет востребован намного больше второго, то потокам все равно придется ждать его высвобождения, а с учетом дополнительных затрат на
обслуживание самих потоков, суммарный результат может оказаться
даже хуже, чем при последовательной обработке.

=== Все включено ===
В поставку Python входит несколько готовых модулей, позволяющих
легко и быстро разработать сетевую программу, например, HTTP-сервер или FTP-клиент. Более детально вы сможете познакомиться с ними
в документации или в хорошо прокомментированных исходных кодах
самих модулей. Здесь же рассмотрим их возможности обзорно.

=== HTTP ===
{{Врезка
|Заголовок=HTTP-SERVER.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf8 -*-
import SimpleHTTPServer as http
handler = http.SimpleHTTPRequestHandler
server = http.BaseHTTPServer.HTTPServer((‘localhost’, 8080), handler)
server.serve_forever()
</source>
|Ширина=310px}}
{{Врезка
|Заголовок=HTTP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf8 -*-
import httplib
host = httplib.HTTP(‘localhost:8080’)
host.putrequest(‘GET’, ‘/testpage.html’)
host.putheader(‘accept’, ‘text/html’)
host.endheaders()
code, msg, headers = host.getreply()
print code, msg
if code == 200:
print host.getfile().read()
</source>
|Ширина=310px}}
Для работы с HTTP Python предоставляет четыре основных модуля:
BaseHTTPServer, SimpleHTTPServer, CGIHTTPServer и httplib.
Первые три реализуют простейшие серверы, причем второй и третий
модули используют возможности первого, предоставляя программисту
более высокоуровневый интерфейс к его методам. Модуль httplib служит для разработки HTTP-клиентов.

Например, простейший HTTP-сервер может выглядеть таким образом (см. листинг http-server.py).

Как видите – всего четыре «рабочих» строчки, и то строка под номером 4 служит лишь для присвоения столь длинного имени метода-обработчика более короткой и удобной переменной. Вести себя этот сервер
будет как «самый настоящий»: он будет возвращаться запрошенные
html-страницы или файлы из текущего и вложенных в него каталогов,
при наличии файлов index.html или index.htm в каталоге, из которого сервер запущен, клиенту по умолчанию (когда указано только имя
каталога) будут отдаваться они. Если индексные файлы отсутствуют,
автоматически будет строиться страница-содержание каталога (аналогично работает Apache с включенным модулем mod_autoindex). В
ответ на запрос несуществующего ресурса будут возвращаться сообщения об ошибке, и т.д.

Клиентское приложение будет не намного сложнее (см Листинг
http-client.py).

В строках 4–7 формируется нужный HTTP-заголовок, затем получаем и распечатываем ответ сервера:
<source lang="html4strict">
admin@dom:~/lxf/propy/l2$ ./http-client.py
200 OK
<HTML><HEAD>
<TITLE>Test page</TITLE>
</HEAD><BASE>
<H2>It is a test page</H2>
</BASE></HTML>
</source>
Конечно, чтобы представить эту страницу в графическом отформатированном виде, придется приложить еще немало усилий. Но это, как
говорится, уже дело техники.

=== Электронная почта ===
Модули smtplib, poplib, imaplib предоставляют клиентские интерфейсы к соответствующим протоколам. Их использование не намного
сложнее рассмотренного выше httplib, и, думаю, вы без труда в них
разберетесь. Для более тонкой обработки содержимого почтовых сообщений (выделения заголовков, вложений и т.д.) вам помогут модули
rfc822, mimetools, multifile, base64, mailbox и другие. Все они
очень хорошо прокомментированы и снабжены достаточно подробной
документацией. Простейший способ получить к ней доступ – функция
help(). Например:
<source lang="python">
>>> import mailbox
>>> help(mailbox)
</source>
Этот код выведет встроенную справку по работе с модулем mailbox
прямо в окне интерактивного терминала.

=== FTP ===
{{Врезка
|Заголовок=FTP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: uft-8 -*-
import ftplib
ftp = ftplib.FTP(‘ftp.freebsd.org’)
ftp.login(‘ftp’, ‘my@mail.ru’)
ftp.cwd(‘pub/FreeBSD’)
retfile = ‘README.TXT’
ftp.retrbinary(‘RETR %s’ % retfile,
open(retfile, ‘w+’).write, 1024)
ftp.quit()
</source>
|Ширина=310px}}
Для работы с протоколом FTP к вашим услугам модуль ftplib. Работа с
ним ведется на достаточно низком уровне, и порой напоминает обычный
сеанс FTP, выполняемый вручную (см. листинг ftp-client.py).

В итоге выполнения этого скрипта в текущем каталоге должен появиться файл README.TXT, скачанный с ftp-сервера ftp://ftp.freebsd.org.

=== Заключение ===
Итак, на этом мы завершим знакомство с основными сетевыми возможностями языка Python. Хочу заметить, что они выходят далеко за рамки
простейших сценариев, пригодных для тестирования «больших» серверов или встраивания некоторых сетевых возможностей в ваши приложения. Приведу лишь несколько примеров. Так, в 90-х годах большой популярностью пользовался web-браузер Grail, разработанный на Python и
предоставляющий весьма широкие для того времени возможности по
обработке интернет-страниц – полная поддержка стандарта HTML 2.0
и, в значительной мере, HTML 3.2, поддержка различных форматов
изображений и звука, способность работать с языком разметки SGML,
поддержка FTP, и т.д.

Менеджер почтовых рассылок Mailman обеспечивает широкие возможности по управлению списками рассылок, включая web-интерфейс. Интернет-сервер Medusa обладает достаточно хорошими
характеристиками, позволяя использовать его как для тестовых
целей, так и для промышленной эксплуатации. Популярный
сервер web-приложений Zope также полностью разработан
на языке Python.

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

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

LXF82:Python

2009-02-08T13:52:16Z

AndrewDjVu: /* «Гуртом и батьку бить веселей» */

LXF82:Python

2009-02-08T10:58:36Z

AndrewDjVu: /* Всегда к вашим услугам */

{{цикл/Python}}

== РАЗРАБОТКА клиент-серверных приложений ==
''ЧАСТЬ 2 Вознамерились написать открытую альтернативу Skype или собственный клиент BitTorrent? '''Сергей Супрунов''' научит всему необходимому – от основ архитектуры «клиент-сервер» до готовых библиотек для работы с существующими интернет-протоколами.''

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

=== Клиент всегда прав ===
{{Врезка
|Заголовок=UDP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
from socket import *
hostname = sys.argv[1]
HEADER = '\x00\x01\x00\x00\x00\x01'
HEADER += '\x00\x00\x00\x00\x00\x00'
QUESTION = ''
parts = hostname.split('.')
for p in parts:
QUESTION += '%c%s' % (chr(len(p)), p)
QUESTION += '\x00\x00\x01\x00\x01'
QUERY = HEADER + QUESTION
cs = socket(AF_INET, SOCK_DGRAM)
cs.sendto(QUERY, ('127.0.0.1', 53))
rsp = cs.recv(1024)
start = len(QUERY) + 12
print '%s.%s.%s.%s' % (ord(rsp[start]),
ord(rsp[start+1]),
ord(rsp[start+2]),
ord(rsp[start+3]))</source>
|Ширина=310px}}
Наиболее распространенным способом взаимодействия двух приложений через сеть являются уже знакомые нам сокеты. Модуль
socket, входящий в стандартную поставку Python, помимо рассмотренных в прошлый раз Unix-сокетов поддерживает также сокеты
домена Internet. Методология использования мало чем отличается от
Unix-сокетов, за исключением того, что вместо параметра AF_UNIX
используется AF_INET, а вместо имени файла указываются имя хоста
и номер порта, которые будут обслуживаться создаваемым сокетом.

В качестве второго параметра в конструкторе сокета можно указать
его тип: с установлением соединения, соответствующий протоколу TCP,
или без соединения – протокол UDP. Допустимые значения – SOCK_STREAM и SOCK_DGRAM соответственно. По умолчанию подразумевается SOCK_STREAM.

Как пример, рассмотрим работу приложения, выполняющего роль
примитивного (и весьма ограниченного функционально) клиента DNS,
работающего по протоколу UDP (см. листинг udp-client.py).

Некоторую сложность здесь представляет то, что DNS относится к
так называемым «двоичным» протоколам, в отличие от «текстовых»,
таких как HTTP или SMTP, где обмен идет обычными текстовыми строками. В случае с DNS оперировать приходится «сырыми» байтами.
Сведения по формату сообщений можно почерпнуть из RFC 1035, раздел «4. MESSAGES».

В 6-й и 7-й строках рассматриваемого кода формируется заголовок
(12 байт). Пренебрегая всем богатством возможностей протокола DNS,
мы ограничиваемся простым запросом (OPCODE=0) одного доменного
имени (QDCOUNT=1). Конструкции вида «\x00» позволяют задать в
строке произвольный шестнадцатиричный код.

В строках 8–12 формируется поле запроса. Оно состоит из частей
доменного имени (в оригинале разделенных точками), перед которыми
указывается число символов в этой части. Например, имя mail.ru состоит из двух частей (mail – 4 символа, ru – 2 символа) и в запросе должно выглядеть так: \x04mail\x02ru\x00. Завершающий ноль, а также
два двухбайтовых поля (QTYPE и QCLASS) добавляются к переменной
QUESTION в строке 12.

Наконец, строки 14 и 15 – создание сокета (обратите внимание на
второй параметр, SOCK_DGRAM, указывающий тип транспортного протокола UDP) и отправка запроса. Поскольку UDP работает без установки
соединения, то вместо знакомой нам пары методов «connect – send» мы
используем один «sendto», в котором указывается сразу и отправляемая информация, и адрес получателя. В данном примере предполагается, что DNS-сервер работает на локальной машине. Вы можете указать
здесь свой DNS-сервер или передавать его имя в качестве параметра.

И в строках 17–21 из всей полезной информации, возвращаемой
сервером, мы, игнорируя любые возможные ошибки, выбираем только
IP-адрес, размещаемый по смещению, которое формируется в переменной start. Результат работы:
serg$ ./udp-client.py donpac.ru
80.254.111.2

=== Всегда к вашим услугам ===
{{Врезка
|Заголовок=IAMOK.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import os, re
from socket import *
class IamOK:
def __init__(self, host='localhost', port=12345):
self.socket = socket(AF_INET, SOCK_STREAM)
self.socket.bind((host, port))
self.socket.listen(5)
def process(self):
while 1:
csocket, caddress = self.socket.accept()
csocket.send('IamOK server v.0.0. Ready to serve.\n')
csocket.send('You are from %s, port %s...\n' % caddress)
while 1:
request = csocket.recv(64)
if re.match('get\s+uptime', request, re.IGNORECASE):
csocket.send(os.popen('/usr/bin/uptime').read())
elif re.match('quit|bye|exit', request, re.IGNORECASE):
break
else:
csocket.send('Unknown command.\n')
csocket.close()
if __name__ == '__main__':
serv = IamOK()
serv.process()
</source>
|Ширина=550px}}
В качестве примера сервера, на этот раз работающего по протоколу TCP,
рассмотрим такой код (см Листинг iamok.py).

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

Здесь все должно быть понятно по прошлому уроку. Два отличия – в конструкторе socket.socket() указывается второй параметр –
SOCK_STREAM (в данном случае его можно было бы и опустить, т.к.
для Internet-домена и так по умолчанию используется протокол TCP).
И метод bind() осуществляет привязку сокета не к файлу, а к имени
хоста и номеру порта, на котором будут ожидаться входящие соединения. Кстати, выбирая номер порта, не забывайте, что порты до 1024-го
относятся к привилегированным и могут быть задействованы только
пользователем root.

Наш сервер понимает две команды: «get uptime», по которой возвращается информация о времени работы сервера, и «quit» (с двумя
синонимами – «bye» и «exit»), по которой сеанс завершается.

Проверить работу сервера можно с помощью обычной
telnet-сессии:
<source lang="text">
admin@dom:~/lxf/propy/l2$ telnet localhost 12345
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is ‘^]’.
IamOK server v.0.0. Ready to serve.
You are from 127.0.0.1, port 2650...
helo
Unknown command.
get uptime
23:09:26 up 58 min, 3 users, load average: 0.04, 0.15, 0.63
quit
Connection closed by foreign host.
</source>
Какая от этого может быть польза – решайте сами.

=== «Гуртом и батьку бить веселей» ===
{{Врезка
|Заголовок=THREAD-TEST.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf8 -*-
import threading as t
import time, re
diskbusy = t.Lock()
def parseit(lognum):
global errors, total
diskbusy.acquire()
log = open(‘logs/syslog.%d’ % lognum)
lines = log.readlines()
diskbusy.release()
for line in lines:
if re.search(‘failed|error’, line):
errors += 1
total += 1
class ParseLog(t.Thread):
def __init__(self, num):
self.lognum = num
t.Thread.__init__(self)

def run(self):
parseit(self.lognum)
#------------------ 1
def test1():
global errors, total
errors = total = 0
for i in range(10):
parseit(i)
print errors, total,
#------------------ 2
def test2():
global errors, total
errors = total = 0
running = []
for i in range(10):
tr = ParseLog(i)
tr.start()
running.append(tr)
for tr in running:
tr.join()

print errors, total,
start = time.time()
test1()
print ‘Послед.: %f’ % (time.time() - start)
start = time.time()
test2()
print ‘Потоки: %f’ % (time.time() - start)
</source>
|Ширина=310px}}
Потоки, наряду с рассмотренными ранее процессами, являются эффективным способом параллельного выполнения различных задач. В
ряде случаев этим можно воспользоваться не только для одновременного обслуживания нескольких подключений в клиент-серверных
приложениях, но и для повышения производительности «автономных»
программ.

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

В стандартной поставке Python для работы с потоками есть два
модуля – thread и threading. Первый позволяет управлять потоками на
достаточно низком уровне, второй – использует средства первого для
предоставления более удобного объектно-ориентированного интерфейса. Класс threading.Thread предоставляет «шаблон» потока. Для его
использования в своей программе вам нужно переопределить метод
run(), описав в нем действия, которые должны выполняться этим потоком. Ниже приведен пример, из которого все должно стать понятно.

Нужно заметить, что при распараллеливании «в лоб», когда просто
запускается сразу несколько потоков, по одному на каждый обрабатываемый файл, нас поджидает один неприятный сюрприз (можете
проверить это на досуге) – при старте сценария все созданные потоки
одновременно попытаются выполнить чтение нужных им для дальнейшей работы данных. Это приведет к жесткой конкуренции за право переместить головки винчестера в нужное место и вызовет, вопреки ожидаемому, катастрофическое падение производительности. Если размеры
файлов сопоставимы с объемом оперативной памяти, система, ко всему
прочему, может «впасть в своппинг», когда считанные одним потоком
данные будут тут же записываться на диск, чтобы освободить место для
данных другого потока.

Вот если бы нам удалось организовать работу потоков таким образом, чтобы, пока один из них выполняет чтение файла, другие не обращались к диску... Для решения этой задачи в языке Python доступно
несколько средств синхронизации работы потоков.
Простейшее из них – использование обычных переменных-флагов.
Как вы помните, потоки разделяют оперативную память, принадлежащую процессу, в рамках которого они исполняются, так что изменения
переменных будут «видны» всем процессам. Идея здесь проста:
<source lang="python">
if DISKBUSY:
# ожидание
else:
DISKBUSY = 1
# чтение файла
DISKBUSY = 0
</source>
То есть первый поток выставит истинное значение глобальной переменной DISKBUSY и приступит к чтению файла. «Опоздавшие» потоки
будут ждать, пока переменная вновь не примет значение «ложь».

В такой реализации программисту предстоит решить не такую уж
простую, как может показаться на первый взгляд, задачу – грамотно
обеспечить ожидание. Бесконечный цикл проверки значения переменной слишком сильно нагружает процессор (не даром такие циклы
называют напряженными). Напрашивающееся time.sleep(1) очень
не эффективно – если ресурс освободится до того, как истечет время «спячки», то он будет простаивать. [Кроме того, подобный метод
синхронизации сам по себе не атомарен – подробности ищите в статье
«[[LXF82:Unix API|Очереди сообщений и семафоры]]»]

Однако в модуле threading есть готовая реализация описанной
выше идеи – класс Lock, который предоставляет программисту так
называемые блокировки, иногда именуемые «мьютексами» (mutex).
Идя проста – создается объект данного класса (threading.Lock()),
который имеет два метода: acquire() позволяет захватить объект,
release() – освободить его. Метод aquire() является блокирующим:
очередной поток, вызвавший его, будет ждать до тех пор, пока мьютекс
не освободится.

Дальнейшим развитием идеи блокировок являются семафоры.
Фактически, семафор – это тот же мьютекс, но позволяющий захватить себя несколько раз. Если вы создадите семафор командой
semaphore = threading.Semaphore(3), то его смогут захватить (тем
же методом semaphore.acquire()) одновременно три потока (каждый раз отнимая по единице из указанного при инициализации числа).
Четвертый поток сможет захватить семафор только после того, как он
будет высвобожден (semaphore.release()) одним из тех, которые
удерживают его в настоящее время.

Впрочем, для нашей задачи лучше всего подходят мьютексы – диск
объявим неразделяемым ресурсом, и посмотрим, какой выигрыш по
времени это нам даст (см. листинг thread-test.py).

Здесь мы проводим два теста – последовательная обработка (1) и
использование потоков с эксклюзивным доступом к диску (2). В строках
16–22 мы создаем подкласс класса Thread, в котором переопределяем
метод run(). Запуск потока выполняется в строке 37. Обратите внимание
на список running (строки 34, 38, 39–40). С его помощью мы отслеживаем активность потоков – метод join() заставляет ждать, пока поток не
завершит свою работу. Дальнейшая работа основного сценария продолжится только после того, как отработают все порожденные потоки.

В строке 5 мы создаем мьютекс, с помощью которого в строках 8 и 11
будет регулироваться доступ потоков к диску. В глобальной переменной
errors ведется подсчет числа строк, в которых есть подстрока «failed» или
«error», в total – общее число обработанных строк. Результат работы:
21931 2302755 Послед.: 33.271387
21931 2302755 Потоки: 22.867245
Как видите, мы получили выигрыш по времени более чем на 30%.
Но нужно заметить, что распараллеливание подобных скриптов даст
заметный эффект только в том случае, если нагрузка на дисковую систему сопоставима с нагрузкой на процессор. Если какой-то из ресурсов
будет востребован намного больше второго, то потокам все равно придется ждать его высвобождения, а с учетом дополнительных затрат на
обслуживание самих потоков, суммарный результат может оказаться
даже хуже, чем при последовательной обработке.

=== Все включено ===
В поставку Python входит несколько готовых модулей, позволяющих
легко и быстро разработать сетевую программу, например, HTTP-сервер или FTP-клиент. Более детально вы сможете познакомиться с ними
в документации или в хорошо прокомментированных исходных кодах
самих модулей. Здесь же рассмотрим их возможности обзорно.

=== HTTP ===
{{Врезка
|Заголовок=HTTP-SERVER.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf8 -*-
import SimpleHTTPServer as http
handler = http.SimpleHTTPRequestHandler
server = http.BaseHTTPServer.HTTPServer((‘localhost’, 8080), handler)
server.serve_forever()
</source>
|Ширина=310px}}
{{Врезка
|Заголовок=HTTP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf8 -*-
import httplib
host = httplib.HTTP(‘localhost:8080’)
host.putrequest(‘GET’, ‘/testpage.html’)
host.putheader(‘accept’, ‘text/html’)
host.endheaders()
code, msg, headers = host.getreply()
print code, msg
if code == 200:
print host.getfile().read()
</source>
|Ширина=310px}}
Для работы с HTTP Python предоставляет четыре основных модуля:
BaseHTTPServer, SimpleHTTPServer, CGIHTTPServer и httplib.
Первые три реализуют простейшие серверы, причем второй и третий
модули используют возможности первого, предоставляя программисту
более высокоуровневый интерфейс к его методам. Модуль httplib служит для разработки HTTP-клиентов.

Например, простейший HTTP-сервер может выглядеть таким образом (см. листинг http-server.py).

Как видите – всего четыре «рабочих» строчки, и то строка под номером 4 служит лишь для присвоения столь длинного имени метода-обработчика более короткой и удобной переменной. Вести себя этот сервер
будет как «самый настоящий»: он будет возвращаться запрошенные
html-страницы или файлы из текущего и вложенных в него каталогов,
при наличии файлов index.html или index.htm в каталоге, из которого сервер запущен, клиенту по умолчанию (когда указано только имя
каталога) будут отдаваться они. Если индексные файлы отсутствуют,
автоматически будет строиться страница-содержание каталога (аналогично работает Apache с включенным модулем mod_autoindex). В
ответ на запрос несуществующего ресурса будут возвращаться сообщения об ошибке, и т.д.

Клиентское приложение будет не намного сложнее (см Листинг
http-client.py).

В строках 4–7 формируется нужный HTTP-заголовок, затем получаем и распечатываем ответ сервера:
<source lang="html4strict">
admin@dom:~/lxf/propy/l2$ ./http-client.py
200 OK
<HTML><HEAD>
<TITLE>Test page</TITLE>
</HEAD><BASE>
<H2>It is a test page</H2>
</BASE></HTML>
</source>
Конечно, чтобы представить эту страницу в графическом отформатированном виде, придется приложить еще немало усилий. Но это, как
говорится, уже дело техники.

=== Электронная почта ===
Модули smtplib, poplib, imaplib предоставляют клиентские интерфейсы к соответствующим протоколам. Их использование не намного
сложнее рассмотренного выше httplib, и, думаю, вы без труда в них
разберетесь. Для более тонкой обработки содержимого почтовых сообщений (выделения заголовков, вложений и т.д.) вам помогут модули
rfc822, mimetools, multifile, base64, mailbox и другие. Все они
очень хорошо прокомментированы и снабжены достаточно подробной
документацией. Простейший способ получить к ней доступ – функция
help(). Например:
<source lang="python">
>>> import mailbox
>>> help(mailbox)
</source>
Этот код выведет встроенную справку по работе с модулем mailbox
прямо в окне интерактивного терминала.

=== FTP ===
{{Врезка
|Заголовок=FTP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: uft-8 -*-
import ftplib
ftp = ftplib.FTP(‘ftp.freebsd.org’)
ftp.login(‘ftp’, ‘my@mail.ru’)
ftp.cwd(‘pub/FreeBSD’)
retfile = ‘README.TXT’
ftp.retrbinary(‘RETR %s’ % retfile,
open(retfile, ‘w+’).write, 1024)
ftp.quit()
</source>
|Ширина=310px}}
Для работы с протоколом FTP к вашим услугам модуль ftplib. Работа с
ним ведется на достаточно низком уровне, и порой напоминает обычный
сеанс FTP, выполняемый вручную (см. листинг ftp-client.py).

В итоге выполнения этого скрипта в текущем каталоге должен появиться файл README.TXT, скачанный с ftp-сервера ftp://ftp.freebsd.org.

=== Заключение ===
Итак, на этом мы завершим знакомство с основными сетевыми возможностями языка Python. Хочу заметить, что они выходят далеко за рамки
простейших сценариев, пригодных для тестирования «больших» серверов или встраивания некоторых сетевых возможностей в ваши приложения. Приведу лишь несколько примеров. Так, в 90-х годах большой популярностью пользовался web-браузер Grail, разработанный на Python и
предоставляющий весьма широкие для того времени возможности по
обработке интернет-страниц – полная поддержка стандарта HTML 2.0
и, в значительной мере, HTML 3.2, поддержка различных форматов
изображений и звука, способность работать с языком разметки SGML,
поддержка FTP, и т.д.

Менеджер почтовых рассылок Mailman обеспечивает широкие возможности по управлению списками рассылок, включая web-интерфейс. Интернет-сервер Medusa обладает достаточно хорошими
характеристиками, позволяя использовать его как для тестовых
целей, так и для промышленной эксплуатации. Популярный
сервер web-приложений Zope также полностью разработан
на языке Python.

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

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

LXF82:Python

2009-02-05T19:45:44Z

AndrewDjVu: /* Клиент всегда прав */

{{цикл/Python}}

== РАЗРАБОТКА клиент-серверных приложений ==
''ЧАСТЬ 2 Вознамерились написать открытую альтернативу Skype или собственный клиент BitTorrent? '''Сергей Супрунов''' научит всему необходимому – от основ архитектуры «клиент-сервер» до готовых библиотек для работы с существующими интернет-протоколами.''

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

=== Клиент всегда прав ===
{{Врезка
|Заголовок=UDP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys
from socket import *
hostname = sys.argv[1]
HEADER = '\x00\x01\x00\x00\x00\x01'
HEADER += '\x00\x00\x00\x00\x00\x00'
QUESTION = ''
parts = hostname.split('.')
for p in parts:
QUESTION += '%c%s' % (chr(len(p)), p)
QUESTION += '\x00\x00\x01\x00\x01'
QUERY = HEADER + QUESTION
cs = socket(AF_INET, SOCK_DGRAM)
cs.sendto(QUERY, ('127.0.0.1', 53))
rsp = cs.recv(1024)
start = len(QUERY) + 12
print '%s.%s.%s.%s' % (ord(rsp[start]),
ord(rsp[start+1]),
ord(rsp[start+2]),
ord(rsp[start+3]))</source>
|Ширина=310px}}
Наиболее распространенным способом взаимодействия двух приложений через сеть являются уже знакомые нам сокеты. Модуль
socket, входящий в стандартную поставку Python, помимо рассмотренных в прошлый раз Unix-сокетов поддерживает также сокеты
домена Internet. Методология использования мало чем отличается от
Unix-сокетов, за исключением того, что вместо параметра AF_UNIX
используется AF_INET, а вместо имени файла указываются имя хоста
и номер порта, которые будут обслуживаться создаваемым сокетом.

В качестве второго параметра в конструкторе сокета можно указать
его тип: с установлением соединения, соответствующий протоколу TCP,
или без соединения – протокол UDP. Допустимые значения – SOCK_STREAM и SOCK_DGRAM соответственно. По умолчанию подразумевается SOCK_STREAM.

Как пример, рассмотрим работу приложения, выполняющего роль
примитивного (и весьма ограниченного функционально) клиента DNS,
работающего по протоколу UDP (см. листинг udp-client.py).

Некоторую сложность здесь представляет то, что DNS относится к
так называемым «двоичным» протоколам, в отличие от «текстовых»,
таких как HTTP или SMTP, где обмен идет обычными текстовыми строками. В случае с DNS оперировать приходится «сырыми» байтами.
Сведения по формату сообщений можно почерпнуть из RFC 1035, раздел «4. MESSAGES».

В 6-й и 7-й строках рассматриваемого кода формируется заголовок
(12 байт). Пренебрегая всем богатством возможностей протокола DNS,
мы ограничиваемся простым запросом (OPCODE=0) одного доменного
имени (QDCOUNT=1). Конструкции вида «\x00» позволяют задать в
строке произвольный шестнадцатиричный код.

В строках 8–12 формируется поле запроса. Оно состоит из частей
доменного имени (в оригинале разделенных точками), перед которыми
указывается число символов в этой части. Например, имя mail.ru состоит из двух частей (mail – 4 символа, ru – 2 символа) и в запросе должно выглядеть так: \x04mail\x02ru\x00. Завершающий ноль, а также
два двухбайтовых поля (QTYPE и QCLASS) добавляются к переменной
QUESTION в строке 12.

Наконец, строки 14 и 15 – создание сокета (обратите внимание на
второй параметр, SOCK_DGRAM, указывающий тип транспортного протокола UDP) и отправка запроса. Поскольку UDP работает без установки
соединения, то вместо знакомой нам пары методов «connect – send» мы
используем один «sendto», в котором указывается сразу и отправляемая информация, и адрес получателя. В данном примере предполагается, что DNS-сервер работает на локальной машине. Вы можете указать
здесь свой DNS-сервер или передавать его имя в качестве параметра.

И в строках 17–21 из всей полезной информации, возвращаемой
сервером, мы, игнорируя любые возможные ошибки, выбираем только
IP-адрес, размещаемый по смещению, которое формируется в переменной start. Результат работы:
serg$ ./udp-client.py donpac.ru
80.254.111.2

=== Всегда к вашим услугам ===
{{Врезка
|Заголовок=IAMOK.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import os, re
from socket import *
class IamOK:
def __init__(self, host=’localhost’, port=12345):
self.socket = socket(AF_INET, SOCK_STREAM)
self.socket.bind((host, port))
self.socket.listen(5)
def process(self):
while 1:
csocket, caddress = self.socket.accept()
csocket.send(‘IamOK server v.0.0. Ready to serve.\n’)
csocket.send(‘You are from %s, port %s...\n’ % caddress)
while 1:
request = csocket.recv(64)
if re.match(‘get\s+uptime’, request, re.IGNORECASE):
csocket.send(os.popen(‘/usr/bin/uptime’).read())
elif re.match(‘quit|bye|exit’, request, re.IGNORECASE):
break
else:
csocket.send(‘Unknown command.\n’)
csocket.close()
if __name__ == ‘__main__’:
serv = IamOK()
serv.process()
</source>
|Ширина=310px}}
В качестве примера сервера, на этот раз работающего по протоколу TCP,
рассмотрим такой код (см Листинг iamok.py).

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

Здесь все должно быть понятно по прошлому уроку. Два отличия – в конструкторе socket.socket() указывается второй параметр –
SOCK_STREAM (в данном случае его можно было бы и опустить, т.к.
для Internet-домена и так по умолчанию используется протокол TCP).
И метод bind() осуществляет привязку сокета не к файлу, а к имени
хоста и номеру порта, на котором будут ожидаться входящие соединения. Кстати, выбирая номер порта, не забывайте, что порты до 1024-го
относятся к привилегированным и могут быть задействованы только
пользователем root.

Наш сервер понимает две команды: «get uptime», по которой возвращается информация о времени работы сервера, и «quit» (с двумя
синонимами – «bye» и «exit»), по которой сеанс завершается.

Проверить работу сервера можно с помощью обычной
telnet-сессии:
<source lang="text">
admin@dom:~/lxf/propy/l2$ telnet localhost 12345
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is ‘^]’.
IamOK server v.0.0. Ready to serve.
You are from 127.0.0.1, port 2650...
helo
Unknown command.
get uptime
23:09:26 up 58 min, 3 users, load average: 0.04, 0.15, 0.63
quit
Connection closed by foreign host.
</source>
Какая от этого может быть польза – решайте сами.

=== «Гуртом и батьку бить веселей» ===
{{Врезка
|Заголовок=THREAD-TEST.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf8 -*-
import threading as t
import time, re
diskbusy = t.Lock()
def parseit(lognum):
global errors, total
diskbusy.acquire()
log = open(‘logs/syslog.%d’ % lognum)
lines = log.readlines()
diskbusy.release()
for line in lines:
if re.search(‘failed|error’, line):
errors += 1
total += 1
class ParseLog(t.Thread):
def __init__(self, num):
self.lognum = num
t.Thread.__init__(self)

def run(self):
parseit(self.lognum)
#------------------ 1
def test1():
global errors, total
errors = total = 0
for i in range(10):
parseit(i)
print errors, total,
#------------------ 2
def test2():
global errors, total
errors = total = 0
running = []
for i in range(10):
tr = ParseLog(i)
tr.start()
running.append(tr)
for tr in running:
tr.join()

print errors, total,
start = time.time()
test1()
print ‘Послед.: %f’ % (time.time() - start)
start = time.time()
test2()
print ‘Потоки: %f’ % (time.time() - start)
</source>
|Ширина=310px}}
Потоки, наряду с рассмотренными ранее процессами, являются эффективным способом параллельного выполнения различных задач. В
ряде случаев этим можно воспользоваться не только для одновременного обслуживания нескольких подключений в клиент-серверных
приложениях, но и для повышения производительности «автономных»
программ.

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

В стандартной поставке Python для работы с потоками есть два
модуля – thread и threading. Первый позволяет управлять потоками на
достаточно низком уровне, второй – использует средства первого для
предоставления более удобного объектно-ориентированного интерфейса. Класс threading.Thread предоставляет «шаблон» потока. Для его
использования в своей программе вам нужно переопределить метод
run(), описав в нем действия, которые должны выполняться этим потоком. Ниже приведен пример, из которого все должно стать понятно.

Нужно заметить, что при распараллеливании «в лоб», когда просто
запускается сразу несколько потоков, по одному на каждый обрабатываемый файл, нас поджидает один неприятный сюрприз (можете
проверить это на досуге) – при старте сценария все созданные потоки
одновременно попытаются выполнить чтение нужных им для дальнейшей работы данных. Это приведет к жесткой конкуренции за право переместить головки винчестера в нужное место и вызовет, вопреки ожидаемому, катастрофическое падение производительности. Если размеры
файлов сопоставимы с объемом оперативной памяти, система, ко всему
прочему, может «впасть в своппинг», когда считанные одним потоком
данные будут тут же записываться на диск, чтобы освободить место для
данных другого потока.

Вот если бы нам удалось организовать работу потоков таким образом, чтобы, пока один из них выполняет чтение файла, другие не обращались к диску... Для решения этой задачи в языке Python доступно
несколько средств синхронизации работы потоков.
Простейшее из них – использование обычных переменных-флагов.
Как вы помните, потоки разделяют оперативную память, принадлежащую процессу, в рамках которого они исполняются, так что изменения
переменных будут «видны» всем процессам. Идея здесь проста:
<source lang="python">
if DISKBUSY:
# ожидание
else:
DISKBUSY = 1
# чтение файла
DISKBUSY = 0
</source>
То есть первый поток выставит истинное значение глобальной переменной DISKBUSY и приступит к чтению файла. «Опоздавшие» потоки
будут ждать, пока переменная вновь не примет значение «ложь».

В такой реализации программисту предстоит решить не такую уж
простую, как может показаться на первый взгляд, задачу – грамотно
обеспечить ожидание. Бесконечный цикл проверки значения переменной слишком сильно нагружает процессор (не даром такие циклы
называют напряженными). Напрашивающееся time.sleep(1) очень
не эффективно – если ресурс освободится до того, как истечет время «спячки», то он будет простаивать. [Кроме того, подобный метод
синхронизации сам по себе не атомарен – подробности ищите в статье
«[[LXF82:Unix API|Очереди сообщений и семафоры]]»]

Однако в модуле threading есть готовая реализация описанной
выше идеи – класс Lock, который предоставляет программисту так
называемые блокировки, иногда именуемые «мьютексами» (mutex).
Идя проста – создается объект данного класса (threading.Lock()),
который имеет два метода: acquire() позволяет захватить объект,
release() – освободить его. Метод aquire() является блокирующим:
очередной поток, вызвавший его, будет ждать до тех пор, пока мьютекс
не освободится.

Дальнейшим развитием идеи блокировок являются семафоры.
Фактически, семафор – это тот же мьютекс, но позволяющий захватить себя несколько раз. Если вы создадите семафор командой
semaphore = threading.Semaphore(3), то его смогут захватить (тем
же методом semaphore.acquire()) одновременно три потока (каждый раз отнимая по единице из указанного при инициализации числа).
Четвертый поток сможет захватить семафор только после того, как он
будет высвобожден (semaphore.release()) одним из тех, которые
удерживают его в настоящее время.

Впрочем, для нашей задачи лучше всего подходят мьютексы – диск
объявим неразделяемым ресурсом, и посмотрим, какой выигрыш по
времени это нам даст (см. листинг thread-test.py).

Здесь мы проводим два теста – последовательная обработка (1) и
использование потоков с эксклюзивным доступом к диску (2). В строках
16–22 мы создаем подкласс класса Thread, в котором переопределяем
метод run(). Запуск потока выполняется в строке 37. Обратите внимание
на список running (строки 34, 38, 39–40). С его помощью мы отслеживаем активность потоков – метод join() заставляет ждать, пока поток не
завершит свою работу. Дальнейшая работа основного сценария продолжится только после того, как отработают все порожденные потоки.

В строке 5 мы создаем мьютекс, с помощью которого в строках 8 и 11
будет регулироваться доступ потоков к диску. В глобальной переменной
errors ведется подсчет числа строк, в которых есть подстрока «failed» или
«error», в total – общее число обработанных строк. Результат работы:
21931 2302755 Послед.: 33.271387
21931 2302755 Потоки: 22.867245
Как видите, мы получили выигрыш по времени более чем на 30%.
Но нужно заметить, что распараллеливание подобных скриптов даст
заметный эффект только в том случае, если нагрузка на дисковую систему сопоставима с нагрузкой на процессор. Если какой-то из ресурсов
будет востребован намного больше второго, то потокам все равно придется ждать его высвобождения, а с учетом дополнительных затрат на
обслуживание самих потоков, суммарный результат может оказаться
даже хуже, чем при последовательной обработке.

=== Все включено ===
В поставку Python входит несколько готовых модулей, позволяющих
легко и быстро разработать сетевую программу, например, HTTP-сервер или FTP-клиент. Более детально вы сможете познакомиться с ними
в документации или в хорошо прокомментированных исходных кодах
самих модулей. Здесь же рассмотрим их возможности обзорно.

=== HTTP ===
{{Врезка
|Заголовок=HTTP-SERVER.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf8 -*-
import SimpleHTTPServer as http
handler = http.SimpleHTTPRequestHandler
server = http.BaseHTTPServer.HTTPServer((‘localhost’, 8080), handler)
server.serve_forever()
</source>
|Ширина=310px}}
{{Врезка
|Заголовок=HTTP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf8 -*-
import httplib
host = httplib.HTTP(‘localhost:8080’)
host.putrequest(‘GET’, ‘/testpage.html’)
host.putheader(‘accept’, ‘text/html’)
host.endheaders()
code, msg, headers = host.getreply()
print code, msg
if code == 200:
print host.getfile().read()
</source>
|Ширина=310px}}
Для работы с HTTP Python предоставляет четыре основных модуля:
BaseHTTPServer, SimpleHTTPServer, CGIHTTPServer и httplib.
Первые три реализуют простейшие серверы, причем второй и третий
модули используют возможности первого, предоставляя программисту
более высокоуровневый интерфейс к его методам. Модуль httplib служит для разработки HTTP-клиентов.

Например, простейший HTTP-сервер может выглядеть таким образом (см. листинг http-server.py).

Как видите – всего четыре «рабочих» строчки, и то строка под номером 4 служит лишь для присвоения столь длинного имени метода-обработчика более короткой и удобной переменной. Вести себя этот сервер
будет как «самый настоящий»: он будет возвращаться запрошенные
html-страницы или файлы из текущего и вложенных в него каталогов,
при наличии файлов index.html или index.htm в каталоге, из которого сервер запущен, клиенту по умолчанию (когда указано только имя
каталога) будут отдаваться они. Если индексные файлы отсутствуют,
автоматически будет строиться страница-содержание каталога (аналогично работает Apache с включенным модулем mod_autoindex). В
ответ на запрос несуществующего ресурса будут возвращаться сообщения об ошибке, и т.д.

Клиентское приложение будет не намного сложнее (см Листинг
http-client.py).

В строках 4–7 формируется нужный HTTP-заголовок, затем получаем и распечатываем ответ сервера:
<source lang="html4strict">
admin@dom:~/lxf/propy/l2$ ./http-client.py
200 OK
<HTML><HEAD>
<TITLE>Test page</TITLE>
</HEAD><BASE>
<H2>It is a test page</H2>
</BASE></HTML>
</source>
Конечно, чтобы представить эту страницу в графическом отформатированном виде, придется приложить еще немало усилий. Но это, как
говорится, уже дело техники.

=== Электронная почта ===
Модули smtplib, poplib, imaplib предоставляют клиентские интерфейсы к соответствующим протоколам. Их использование не намного
сложнее рассмотренного выше httplib, и, думаю, вы без труда в них
разберетесь. Для более тонкой обработки содержимого почтовых сообщений (выделения заголовков, вложений и т.д.) вам помогут модули
rfc822, mimetools, multifile, base64, mailbox и другие. Все они
очень хорошо прокомментированы и снабжены достаточно подробной
документацией. Простейший способ получить к ней доступ – функция
help(). Например:
<source lang="python">
>>> import mailbox
>>> help(mailbox)
</source>
Этот код выведет встроенную справку по работе с модулем mailbox
прямо в окне интерактивного терминала.

=== FTP ===
{{Врезка
|Заголовок=FTP-CLIENT.PY
|Содержание=
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: uft-8 -*-
import ftplib
ftp = ftplib.FTP(‘ftp.freebsd.org’)
ftp.login(‘ftp’, ‘my@mail.ru’)
ftp.cwd(‘pub/FreeBSD’)
retfile = ‘README.TXT’
ftp.retrbinary(‘RETR %s’ % retfile,
open(retfile, ‘w+’).write, 1024)
ftp.quit()
</source>
|Ширина=310px}}
Для работы с протоколом FTP к вашим услугам модуль ftplib. Работа с
ним ведется на достаточно низком уровне, и порой напоминает обычный
сеанс FTP, выполняемый вручную (см. листинг ftp-client.py).

В итоге выполнения этого скрипта в текущем каталоге должен появиться файл README.TXT, скачанный с ftp-сервера ftp://ftp.freebsd.org.

=== Заключение ===
Итак, на этом мы завершим знакомство с основными сетевыми возможностями языка Python. Хочу заметить, что они выходят далеко за рамки
простейших сценариев, пригодных для тестирования «больших» серверов или встраивания некоторых сетевых возможностей в ваши приложения. Приведу лишь несколько примеров. Так, в 90-х годах большой популярностью пользовался web-браузер Grail, разработанный на Python и
предоставляющий весьма широкие для того времени возможности по
обработке интернет-страниц – полная поддержка стандарта HTML 2.0
и, в значительной мере, HTML 3.2, поддержка различных форматов
изображений и звука, способность работать с языком разметки SGML,
поддержка FTP, и т.д.

Менеджер почтовых рассылок Mailman обеспечивает широкие возможности по управлению списками рассылок, включая web-интерфейс. Интернет-сервер Medusa обладает достаточно хорошими
характеристиками, позволяя использовать его как для тестовых
целей, так и для промышленной эксплуатации. Популярный
сервер web-приложений Zope также полностью разработан
на языке Python.

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

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

LXF81:Python

2009-02-03T19:29:26Z

AndrewDjVu: /* logclient2.py */

{{Цикл/Python}}

==Задачи многозадачности==
''часть 1 '''Сергей Супрунов''' открывает новый цикл статей, в котором будут более полно освещены некоторые практические моменты разработки приложений на языке Python. Начнём, пожалуй, с вопросов параллельных вычислений...''

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

В большинстве современных ОС эта идея имеет две реализации: процессы и потоки (причем в Linux одно практически неотличимо от другого).
Процесс, если говорить упрощённо, представляет собой некоторый набор
ресурсов (область памяти, значения процессорных регистров, открытые
дескрипторы файлов и т.д.), принадлежащих какой-то задаче. На однопроцессорных машинах одновременно может обрабатываться только
один процесс, остальные в это время находятся в очереди. Ядро системы,
точнее, его планировщик, в соответствии с заданным алгоритмом предоставляет доступ к процессору ожидающим процессам в соответствии с
их приоритетом. Если текущий процесс переходит в состояние ожидания
ввода-вывода, то доступ к процессору передаётся следующему процессу
в очереди. Благодаря этому, во-первых, реализуется более эффективное
использование ресурсов системы, а во-вторых, несколько задач могут
выполняться в одно и то же (с точки зрения пользователя) время.

Потоки (threads, их также называют нитями или облегчёнными процессами) решают аналогичную задачу, но в рамках одного процесса.
При управлении как потоками, так и процессами операционная система
вынуждена «непроизводительно» расходовать некоторые ресурсы на
так называемое переключение контекста (т.е. на выполнение «подготовительных» мероприятий, таких как восстановление значения регистров и адресного пространства). Благодаря тому, что потоки разделяют
некоторые ресурсы (например, память процесса, в рамках которого они
исполняются), переключение их контекста происходит заметно быстрее,
чем контекста процесса. Благодаря этому можно распараллеливать
задачи с заметно меньшими затратами. Хорошим примером может служить производительность Apache 2.x (см. обзор в [[LXF77:Apache 2.2|LXF77]]).

Хватит, пожалуй, теории. Посмотрим, какие средства предоставляет
язык Python программисту, желающему воспользоваться многозадачностью операционной системы, а заодно рассмотрим такие вещи как
сокеты и межпроцессорное взаимодействие.
===Сокеты===
Сокет (конечная точка сетевых коммуникаций) – это основа клиент-серверных приложений. Фактически, это интерфейс, с помощью которого процессы могут осуществлять обмен информацией между собой.
Конкретная реализация определяется так называемым коммуникационным доменом, наиболее распространённые из них – Internet-домен и
Unix-домен. Internet-сокеты позволяют реализовать взаимодействие на
базе протоколов сети Интернет, таких как TCP или UDP. О них мы подробнее поговорим в одной из следующих статей цикла.

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

В языке Python работа с сокетами реализована в модуле socket. Со стороны сервера создание сокета
(рассмотрим пример для домена Unix) выглядит следующим образом:
<source lang="python">
import socket # импортируем модуль
s = socket.socket(socket.AF_UNIX) # создаём сокет домена AF_UNIX
s.bind('/tmp/test.sock') # привязываем его к файлу
s.listen(1) # начинаем прослушивать
conn, addr = s.accept() # ждём подключения
conn.send('HELO') # дождавшись, отправляем клиенту строку
data = conn.recv(1024) # получаем от клиента данные
s.close() # закрываем сокет
</source>

Обратите внимание на то, что методы accept(), send(), recv() являются по умолчанию блокирующими,
т.е. работа программы приостанавливается до тех пор, пока не будет выполнено необходимое действие. Это
означает, что клиент и сервер должны (по крайней мере, в нашей простейшей реализации) строго придерживаться определённой последовательности действий (протокола). В нашем случае после установки соединения
сервер посылает строку приветствия. Если клиент, вместо того чтобы принять эту информацию, сам начнёт
что-то передавать, то мы получим взаимную блокировку – клиент будет ждать, пока сервер примет его данные,
сервер же будет ждать аналогичных действий со стороны клиента.

Для нормальной работы клиентская реализация должна выглядеть примерно так:
<source lang="python">
import socket # импортируем модуль
c = socket.socket(socket.AF_UNIX) # создаём сокет такого-же домена
c.connect('/tmp/test.sock') # подключаемся к сокету сервера
greeting = c.recv(1024) # принимаем строку приветсвия
c.send('Hello, server!') # отправляем свои данные
c.close() # закрываем соединение
</source>

Понятно, что в данном примере мы получили «одноразовый» сервер, который, дождавшись соединения и
приняв данные, завершает свою работу. Для постоянной работы фрагмент, начиная с метода accept(), нужно
поместить в бесконечный цикл (см. пример ниже).

===Модуль select===
В Python доступен ещё один способ повысить эффективность работы за счёт параллельного выполнения некоторых операций – модуль select. Он использует системный вызов select для мультиплексирования соединений клиентов в одном цикле событий – метод select этого модуля позволяет отслеживать одновременно
несколько сокетов или других файловых объектов (только на Unix-подобных системах) в ожидании готовности
одного из них, после чего управление возвращается основной программе. Благодаря этому программа может
обрабатывать сразу несколько сокетов по мере их готовности к взаимодействию. Познакомимся с этим модулем поближе.

Чтобы не замусоривать статью множеством фрагментов кода, приступим сразу к рассмотрению серьёзного примера, к которому будем обращаться по мере необходимости. Данный пример – простейший аналог
демона syslog, задача которого – получать через Unix-сокет информацию от клиентов и записывать её в файл
журнала. Если что-то не совсем понятно сразу, не обращайте на это внимание – всё прояснится к концу изложения. Код представлен на врезке logserver.py.

Чтобы в дальнейшем было проще модифицировать код, реализуем его в виде класса. В его конструкторе (метод __init__()) решаются три задачи:
открытие файла (стр. 8-9), удаление файла-сокета,
который может остаться в случае аварийного завершения сценария (стр. 10-15) и собственно создание
сокета (стр. 16-18). На строки 19-21 пока не обращайте внимания.

Методы openlog() и writelog() соответственно открывают лог-файл и записывают в него строку, предваряя текущей датой. Ну и метод start() –
основной, в котором и осуществляется обработка
входящих соединений.

Для того, чтобы сервер постоянно обслуживал
вверенный ему сокет, создаётся бесконечный цикл
(строка 37). Однако здесь есть небольшая проблема.
Вы же ещё помните, что методы accept(), recv() и
send() являются по умолчанию блокирующими? То
есть при «последовательной» обработке первый клиент, достучавшийся до сервера, полностью завладеет вниманием последнего, пока не завершит работу
согласно заданному протоколу. Остальные же будут
либо поставлены в очередь, либо вообще отброшены,
если размер очереди превысит установленное значение (задаётся параметром метода listen()). Только
полностью обслужив первого клиента, сервер сможет
вернуться к строке 44 и снова вызвать accept().

Если обмен с клиентом происходит быстро, то
такая схема работы вполне приемлема. Однако если
протокол требует ведения «диалога», в ходе которого возможны задержки, то это может стать серьёзной
проблемой. В рассматриваемом примере мы специально усложнили протокол, сделав его двухэтапным –
сначала клиент должен представиться, дождаться от
сервера подтверждения, затем отправить данные и
снова дождаться подтверждения.

Если между первой и второй отправкой данных возникнет пауза (в коде клиента она искусственно реализована функцией time.sleep()), то
сервер будет понапрасну простаивать, хотя вполне мог бы заняться обслуживанием других клиентов. Собственно, для этого и используется метод
select() одноимённого модуля (строка 39).

Принцип действия его следующий – он берёт на
себя ожидание данных в сокетах (массивы обслуживаемых сокетов передаются ему в виде параметров),
передавая управление основной программе, если
один из сокетов будет готов к обслуживанию.

Чтобы было понятнее, рассмотрим, что происходит
в нашем примере. В строке 39 мы запускаем метод
select(). Как только один (или несколько) из обслуживаемых сокетов (первоначально такой сокет только
один, созданный при инициализации объекта в строке 16) будет готов к обслуживанию, select() передаёт
основной программе массив сокетов, готовых к работе,
который обрабатывается в цикле (строка 42). Так, если
к работе готов «родительский» сокет, для него вызывается метод accept(). Поскольку метод select()
гарантирует, что запрос на соединение уже есть, то
основной программе не придётся тратить время на
ожидание – accept() будет обработан сразу, вернув
объект – новый сокет, предназначенный для работы с
данным клиентом. Но мы не начинаем сразу же выполнять установленный протокол, а просто помещаем этот
новый сокет в список rsocks, обслуживаемый методом
select() (строка 45).

Когда на этот сокет поступят данные от клиента, select() вновь сообщит о готовности. На этот
раз обработка пойдёт по ветке «else» (строка 46).
Поскольку наш протокол двухэтапный, то считывать
данные мы должны два раза, что и реализуется
дополнительной конструкцией «if – else» (строки 47-56): при первом «подходе» словарь senders не
будет содержать упоминания данного сокета (обратные кавычки позволяют работать не с самим сокетом,
а с его «строковым представлением»); при втором
же этот словарь уже будет содержать имя отправителя, ассоциированное с сокетом. На втором этапе
выполняется запись строки в лог-файл (строка 54),
удаление сокета из массива rsocks (строка 55), что-бы select() уже не занимался его обслуживанием, и
удаление записи из словаря (строка 56).

Обратите внимание, что мы не можем просто
взять и последовательно вызвать два метода recv()
для получения всех данных, поскольку второй вызов
окажется уже блокирующим – ведь на первый recv()
мы попадаем, только когда select() обнаружит готовые для обработки данные; во втором же случае
готовности придётся ждать самостоятельно.

По большому счёту, вызовы send() в нашем
примере получились блокирующие – если клиент
не сможет сразу принять переданное ему подтверждение, то сервер будет простаивать. Решается это
аналогичным путём, но уже с помощью массива
wsocks, однако из боязни сделать код чрезмерно
сложным и нечитаемым, в данном примере мы проигнорируем эту проблему, оставив её решение вам в
качестве упражнения.
===Сигналы===
Остались ещё две проблемы. Во-первых, хотелось
бы, чтобы сервер перед завершением своей работы (поскольку используется бесконечный цикл, то
это придётся делать «грубыми» методами вроде
команды kill или Ctrl+C) успевал выполнить некоторые полезные действия (например, закрыть файл
журнала, удалить файл сокета). Во-вторых, если в
процессе работы сервера удалить или переименовать лог-файл и создать новый с таким же именем
(например, это может происходить при ротации журнала утилитами типа logrotate), то дескриптор открытого файла (self.log в нашем примере) не изменится, продолжая указывать на прежнее расположение
файла в файловой системе. Так что запись будет
вестись по этому дескриптору, в уже переименованный или удалённый файл (поскольку на файл будет
оставаться ссылка, «привязанная» к дескриптору, то
при удалении из каталога он физически будет оставаться на месте, пока не будет удалён этот дескриптор) То есть нужно предусмотреть переинициализацию файла журнала.

Как команда kill, так и комбинация [Ctrl+C] реализуют метод межпроцессорного взаимодействия,
именуемый сигналами. Например, kill 3942 отправит
процессу номер 3942 сигнал 15 (SIGTERM), дающий
указание завершить работу. Ctrl+C отправляет сигнал 2 (SIGINT). Большинство сигналов процесс может
перехватить и обработать по собственному желанию,
чем мы и воспользуемся.

В Python для этого предназначен модуль signal.
Собственно, его мы и используем в строках 19–21,
назначая на некоторые сигналы в качестве обработчика метод stop(). Для сигнала 1 (SIGHUP) в качестве обработчика
назначается метод reinit(), который решает задачу переинициализации
открытого файла журнала.
===Тестирование===
Чтобы проверить работу нашего сервера, нам нужен клиент. Его код
представлен во врезке logclient.py. Никаких сложностей здесь нет.
Поясню лишь, что конструкции time.sleep(5) (стр. 15 и 21) искусственно создают задержку между первым и вторым этапами диалога.

Чтобы убедиться в том, что все клиенты обслуживаются сервером
параллельно, нужно запустить их в нескольких экземплярах (например, с разных консолей). В результате в файле журнала появятся такие
записи:
<pre>
Sun Jun 4 15:30:17 2006: ===> LogServer started
Sun Jun 4 15:30:55 2006: [test2] Test message
Sun Jun 4 15:30:56 2006: [test3] Test message
Sun Jun 4 15:31:00 2006: ===> LogServer stopped [signal 2]
</pre>

Как видите, между записью сообщений от test2 и test3 прошла
одна секунда, хотя каждый клиент требует для своей обработки как
минимум 10. Значит, ожидание ответа от обоих клиентов выполняется
одновременно, чего мы и добивались.
===Ветвления===
Впрочем, select – это не единственный способ организовать параллельную работу в Python. Модуль os предоставляет функцию fork(),
которая использует одноимённый системный вызов, порождающий
копию текущего процесса. Чтобы посмотреть, как это работает на практике, напишем небольшой сценарий, который будет автоматически
запускать скрипты-клиенты для тестирования нашего сервера (действительно, негоже делать вручную то, что можно поручить программе). Код
представлен на врезке logclient2.py.

Здесь всё до безобразия просто – функция fork() (строка 6) порождает копию текущего процесса. В каждой копии выполнение кода будет
продолжено как ни в чём не бывало со следующей команды. Чтобы код
мог понять, где он выполняется – в родительском процессе или в дочернем, используется значение, возвращаемое функцией fork(). Дочерний
процесс получает значение 0, родительский – идентификатор порождённого дочернего процесса (PID).

Кстати, функция os._exit(0) в строке 10 позволяет завершить
дочерний процесс. Если этого не сделать, то он пойдёт на выполнение
цикла for (строка 5), уже сам выступая в качестве родительского и
порождая, таким образом, настоящую лавину новых процессов.

Естественно, таким образом можно было бы реализовать и наш
сервер – после метода accept() ответвлять дочерний процесс, который
занимался бы обслуживанием конкретного клиента, в то время как родительский продолжал бы «висеть» на методе accept(), ожидая входящие
соединения. Именно так и работают многие серверы, например, Apache
(версия 1.х – только так и никак иначе, а в 2.х появились потоки).

----

=== БЛОКИРОВАТЬ НЕОБЯЗАТЕЛЬНО ===
Модуль '''socket''' также предоставляет возможность работы с неблокирующими вызовами ''accept()'', ''send()'' и ''recv()''. Для
этого следует предварительно установить значение соответствующего атрибута объекта-сокета с помощью следующего
метода:
<source lang="python">
socket.setblocking(0)
</source>

Значение '''0''' переключает сокет в неблокирующий режим работы (по умолчанию используется блокирующий –
значение '''1'''). При этом методы ''accept()'', ''send()'' и ''recv()'' при отсутствии данных для обработки не останавливают
выполнение программы до их появления, а генерируют исключение ''socket.error''. Что с ним делать дальше – решать
вам. Например, можно просто игнорировать:
<source lang="python">
while(1):
try:
data = sock.recv()
except socket.error, errcode:
if errcode[0] == 35:
pass
else:
raise(socket.error)
</source>

Второй параметр оператора ''except'' – переменная, в которую будет занесён код ошибки. Этот код представляет собой
кортеж вида ('''35''', ‘Resource temporarily unavailable’), где первый элемент – числовой код ошибки, а второй –
текстовая строка-пояснение. При отсутствии данных генерируется ошибка '''35''', которую мы и игнорируем (''pass''). Здесь
мы получаем то же ожидание данных, но уже реализованное самим кодом Python. Но преимущество здесь в том, что
вместо оператора ''pass'' можно реализовать любую обработку. Например, переходить к опросу другого сокета.

===logserver.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-

import os, socket, time, signal, select

class LogServer:
def __init__(self, sockfile='./lserv.sock',
logfile='./lserv.log',
maxqueue=5):
self.logfilename = logfile
self.openlog()
self.sockfilename = sockfile
try:
if os.path.exists(sockfile):
os.unlink(sockfile)
except:
raise 'error'

self.socket = socket.socket(socket.AF_UNIX)
self.socket.bind(sockfile)
self.socket.listen(maxqueue)

signal.signal(signal.SIGHUP, self.reinit)
signal.signal(signal.SIGINT, self.stop)
signal.signal(signal.SIGTERM, self.stop)

self.writelog('===> LogServer started')

def openlog(self):
self.log = open(self.logfilename, 'a+')

def writelog(self, message):
self.log.write('%s: %s\n' % (time.asctime(), message))

def reinit(self, signum, frame):
self.log.close()
self.openlog()
self.start()

def start(self):
rsocks = []
wsocks = []
rsocks.append(self.socket)
senders = {}
while 1:
try:
reads, writes, errs = select.select(rsocks, wsocks, [])
except:
return

for sock in reads:
if sock == self.socket:
client, name = sock.accept()
rsocks.append(client)
elif not `sock` in senders.keys():
sender = sock.recv(1024)
sock.send('Sender OK')
senders[`sock`] = sender
else:
message = sock.recv(1024)
sock.send('Message OK')
self.writelog('[%s] %s' % (senders[`sock`], message))
rsocks.remove(sock)
del senders[`sock`]

def stop(self, signum, frame):
self.writelog('===> LogServer stopped [signal %s]' % (signum))
self.log.close()
os.unlink(self.sockfilename)

if __name__ == '__main__':
serv = LogServer(maxqueue=3)
serv.start()
</source>

===logclient.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-

import sys, socket, time

class LogClient:
def __init__(self, sender='generic client',
sockfile='./lserv.sock',
buffersize=1024,
testmode=0):
self.sender = sender
self.sockfile = sockfile
self.buffersize = buffersize
self.testmode = testmode

def writelog(self, message):
if self.testmode:
time.sleep(5)
self.socket = socket.socket(socket.AF_UNIX)
self.socket.connect(self.sockfile)
self.socket.send(self.sender)
if self.socket.recv(self.buffersize) == 'Sender OK':
if self.testmode:
time.sleep(5)
self.socket.send(message)
if not self.socket.recv(self.buffersize) == 'Message OK':
print 'Ошибка: нет подтверждения Message'
else:
print 'Ошибка: нет подтверждения Sender'
self.socket.close()

if __name__ == '__main__':
sendername = sys.argv[1]
client = LogClient(sender=sendername, testmode=1)
client.writelog('Test message')
</source>

===logclient2.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-

import os
from logclient import LogClient

for i in xrange(25):
pid = os.fork()
if pid == 0:
client = LogClient(sender='client%d' % i, testmode=1)
client.writelog('Test from client%d' % i)
os._exit(0)
else:
print 'Start child[%d]' % pid
</source>

LXF81:Python

2009-02-03T19:23:26Z

AndrewDjVu: /* logclient.py */

{{Цикл/Python}}

==Задачи многозадачности==
''часть 1 '''Сергей Супрунов''' открывает новый цикл статей, в котором будут более полно освещены некоторые практические моменты разработки приложений на языке Python. Начнём, пожалуй, с вопросов параллельных вычислений...''

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

В большинстве современных ОС эта идея имеет две реализации: процессы и потоки (причем в Linux одно практически неотличимо от другого).
Процесс, если говорить упрощённо, представляет собой некоторый набор
ресурсов (область памяти, значения процессорных регистров, открытые
дескрипторы файлов и т.д.), принадлежащих какой-то задаче. На однопроцессорных машинах одновременно может обрабатываться только
один процесс, остальные в это время находятся в очереди. Ядро системы,
точнее, его планировщик, в соответствии с заданным алгоритмом предоставляет доступ к процессору ожидающим процессам в соответствии с
их приоритетом. Если текущий процесс переходит в состояние ожидания
ввода-вывода, то доступ к процессору передаётся следующему процессу
в очереди. Благодаря этому, во-первых, реализуется более эффективное
использование ресурсов системы, а во-вторых, несколько задач могут
выполняться в одно и то же (с точки зрения пользователя) время.

Потоки (threads, их также называют нитями или облегчёнными процессами) решают аналогичную задачу, но в рамках одного процесса.
При управлении как потоками, так и процессами операционная система
вынуждена «непроизводительно» расходовать некоторые ресурсы на
так называемое переключение контекста (т.е. на выполнение «подготовительных» мероприятий, таких как восстановление значения регистров и адресного пространства). Благодаря тому, что потоки разделяют
некоторые ресурсы (например, память процесса, в рамках которого они
исполняются), переключение их контекста происходит заметно быстрее,
чем контекста процесса. Благодаря этому можно распараллеливать
задачи с заметно меньшими затратами. Хорошим примером может служить производительность Apache 2.x (см. обзор в [[LXF77:Apache 2.2|LXF77]]).

Хватит, пожалуй, теории. Посмотрим, какие средства предоставляет
язык Python программисту, желающему воспользоваться многозадачностью операционной системы, а заодно рассмотрим такие вещи как
сокеты и межпроцессорное взаимодействие.
===Сокеты===
Сокет (конечная точка сетевых коммуникаций) – это основа клиент-серверных приложений. Фактически, это интерфейс, с помощью которого процессы могут осуществлять обмен информацией между собой.
Конкретная реализация определяется так называемым коммуникационным доменом, наиболее распространённые из них – Internet-домен и
Unix-домен. Internet-сокеты позволяют реализовать взаимодействие на
базе протоколов сети Интернет, таких как TCP или UDP. О них мы подробнее поговорим в одной из следующих статей цикла.

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

В языке Python работа с сокетами реализована в модуле socket. Со стороны сервера создание сокета
(рассмотрим пример для домена Unix) выглядит следующим образом:
<source lang="python">
import socket # импортируем модуль
s = socket.socket(socket.AF_UNIX) # создаём сокет домена AF_UNIX
s.bind('/tmp/test.sock') # привязываем его к файлу
s.listen(1) # начинаем прослушивать
conn, addr = s.accept() # ждём подключения
conn.send('HELO') # дождавшись, отправляем клиенту строку
data = conn.recv(1024) # получаем от клиента данные
s.close() # закрываем сокет
</source>

Обратите внимание на то, что методы accept(), send(), recv() являются по умолчанию блокирующими,
т.е. работа программы приостанавливается до тех пор, пока не будет выполнено необходимое действие. Это
означает, что клиент и сервер должны (по крайней мере, в нашей простейшей реализации) строго придерживаться определённой последовательности действий (протокола). В нашем случае после установки соединения
сервер посылает строку приветствия. Если клиент, вместо того чтобы принять эту информацию, сам начнёт
что-то передавать, то мы получим взаимную блокировку – клиент будет ждать, пока сервер примет его данные,
сервер же будет ждать аналогичных действий со стороны клиента.

Для нормальной работы клиентская реализация должна выглядеть примерно так:
<source lang="python">
import socket # импортируем модуль
c = socket.socket(socket.AF_UNIX) # создаём сокет такого-же домена
c.connect('/tmp/test.sock') # подключаемся к сокету сервера
greeting = c.recv(1024) # принимаем строку приветсвия
c.send('Hello, server!') # отправляем свои данные
c.close() # закрываем соединение
</source>

Понятно, что в данном примере мы получили «одноразовый» сервер, который, дождавшись соединения и
приняв данные, завершает свою работу. Для постоянной работы фрагмент, начиная с метода accept(), нужно
поместить в бесконечный цикл (см. пример ниже).

===Модуль select===
В Python доступен ещё один способ повысить эффективность работы за счёт параллельного выполнения некоторых операций – модуль select. Он использует системный вызов select для мультиплексирования соединений клиентов в одном цикле событий – метод select этого модуля позволяет отслеживать одновременно
несколько сокетов или других файловых объектов (только на Unix-подобных системах) в ожидании готовности
одного из них, после чего управление возвращается основной программе. Благодаря этому программа может
обрабатывать сразу несколько сокетов по мере их готовности к взаимодействию. Познакомимся с этим модулем поближе.

Чтобы не замусоривать статью множеством фрагментов кода, приступим сразу к рассмотрению серьёзного примера, к которому будем обращаться по мере необходимости. Данный пример – простейший аналог
демона syslog, задача которого – получать через Unix-сокет информацию от клиентов и записывать её в файл
журнала. Если что-то не совсем понятно сразу, не обращайте на это внимание – всё прояснится к концу изложения. Код представлен на врезке logserver.py.

Чтобы в дальнейшем было проще модифицировать код, реализуем его в виде класса. В его конструкторе (метод __init__()) решаются три задачи:
открытие файла (стр. 8-9), удаление файла-сокета,
который может остаться в случае аварийного завершения сценария (стр. 10-15) и собственно создание
сокета (стр. 16-18). На строки 19-21 пока не обращайте внимания.

Методы openlog() и writelog() соответственно открывают лог-файл и записывают в него строку, предваряя текущей датой. Ну и метод start() –
основной, в котором и осуществляется обработка
входящих соединений.

Для того, чтобы сервер постоянно обслуживал
вверенный ему сокет, создаётся бесконечный цикл
(строка 37). Однако здесь есть небольшая проблема.
Вы же ещё помните, что методы accept(), recv() и
send() являются по умолчанию блокирующими? То
есть при «последовательной» обработке первый клиент, достучавшийся до сервера, полностью завладеет вниманием последнего, пока не завершит работу
согласно заданному протоколу. Остальные же будут
либо поставлены в очередь, либо вообще отброшены,
если размер очереди превысит установленное значение (задаётся параметром метода listen()). Только
полностью обслужив первого клиента, сервер сможет
вернуться к строке 44 и снова вызвать accept().

Если обмен с клиентом происходит быстро, то
такая схема работы вполне приемлема. Однако если
протокол требует ведения «диалога», в ходе которого возможны задержки, то это может стать серьёзной
проблемой. В рассматриваемом примере мы специально усложнили протокол, сделав его двухэтапным –
сначала клиент должен представиться, дождаться от
сервера подтверждения, затем отправить данные и
снова дождаться подтверждения.

Если между первой и второй отправкой данных возникнет пауза (в коде клиента она искусственно реализована функцией time.sleep()), то
сервер будет понапрасну простаивать, хотя вполне мог бы заняться обслуживанием других клиентов. Собственно, для этого и используется метод
select() одноимённого модуля (строка 39).

Принцип действия его следующий – он берёт на
себя ожидание данных в сокетах (массивы обслуживаемых сокетов передаются ему в виде параметров),
передавая управление основной программе, если
один из сокетов будет готов к обслуживанию.

Чтобы было понятнее, рассмотрим, что происходит
в нашем примере. В строке 39 мы запускаем метод
select(). Как только один (или несколько) из обслуживаемых сокетов (первоначально такой сокет только
один, созданный при инициализации объекта в строке 16) будет готов к обслуживанию, select() передаёт
основной программе массив сокетов, готовых к работе,
который обрабатывается в цикле (строка 42). Так, если
к работе готов «родительский» сокет, для него вызывается метод accept(). Поскольку метод select()
гарантирует, что запрос на соединение уже есть, то
основной программе не придётся тратить время на
ожидание – accept() будет обработан сразу, вернув
объект – новый сокет, предназначенный для работы с
данным клиентом. Но мы не начинаем сразу же выполнять установленный протокол, а просто помещаем этот
новый сокет в список rsocks, обслуживаемый методом
select() (строка 45).

Когда на этот сокет поступят данные от клиента, select() вновь сообщит о готовности. На этот
раз обработка пойдёт по ветке «else» (строка 46).
Поскольку наш протокол двухэтапный, то считывать
данные мы должны два раза, что и реализуется
дополнительной конструкцией «if – else» (строки 47-56): при первом «подходе» словарь senders не
будет содержать упоминания данного сокета (обратные кавычки позволяют работать не с самим сокетом,
а с его «строковым представлением»); при втором
же этот словарь уже будет содержать имя отправителя, ассоциированное с сокетом. На втором этапе
выполняется запись строки в лог-файл (строка 54),
удаление сокета из массива rsocks (строка 55), что-бы select() уже не занимался его обслуживанием, и
удаление записи из словаря (строка 56).

Обратите внимание, что мы не можем просто
взять и последовательно вызвать два метода recv()
для получения всех данных, поскольку второй вызов
окажется уже блокирующим – ведь на первый recv()
мы попадаем, только когда select() обнаружит готовые для обработки данные; во втором же случае
готовности придётся ждать самостоятельно.

По большому счёту, вызовы send() в нашем
примере получились блокирующие – если клиент
не сможет сразу принять переданное ему подтверждение, то сервер будет простаивать. Решается это
аналогичным путём, но уже с помощью массива
wsocks, однако из боязни сделать код чрезмерно
сложным и нечитаемым, в данном примере мы проигнорируем эту проблему, оставив её решение вам в
качестве упражнения.
===Сигналы===
Остались ещё две проблемы. Во-первых, хотелось
бы, чтобы сервер перед завершением своей работы (поскольку используется бесконечный цикл, то
это придётся делать «грубыми» методами вроде
команды kill или Ctrl+C) успевал выполнить некоторые полезные действия (например, закрыть файл
журнала, удалить файл сокета). Во-вторых, если в
процессе работы сервера удалить или переименовать лог-файл и создать новый с таким же именем
(например, это может происходить при ротации журнала утилитами типа logrotate), то дескриптор открытого файла (self.log в нашем примере) не изменится, продолжая указывать на прежнее расположение
файла в файловой системе. Так что запись будет
вестись по этому дескриптору, в уже переименованный или удалённый файл (поскольку на файл будет
оставаться ссылка, «привязанная» к дескриптору, то
при удалении из каталога он физически будет оставаться на месте, пока не будет удалён этот дескриптор) То есть нужно предусмотреть переинициализацию файла журнала.

Как команда kill, так и комбинация [Ctrl+C] реализуют метод межпроцессорного взаимодействия,
именуемый сигналами. Например, kill 3942 отправит
процессу номер 3942 сигнал 15 (SIGTERM), дающий
указание завершить работу. Ctrl+C отправляет сигнал 2 (SIGINT). Большинство сигналов процесс может
перехватить и обработать по собственному желанию,
чем мы и воспользуемся.

В Python для этого предназначен модуль signal.
Собственно, его мы и используем в строках 19–21,
назначая на некоторые сигналы в качестве обработчика метод stop(). Для сигнала 1 (SIGHUP) в качестве обработчика
назначается метод reinit(), который решает задачу переинициализации
открытого файла журнала.
===Тестирование===
Чтобы проверить работу нашего сервера, нам нужен клиент. Его код
представлен во врезке logclient.py. Никаких сложностей здесь нет.
Поясню лишь, что конструкции time.sleep(5) (стр. 15 и 21) искусственно создают задержку между первым и вторым этапами диалога.

Чтобы убедиться в том, что все клиенты обслуживаются сервером
параллельно, нужно запустить их в нескольких экземплярах (например, с разных консолей). В результате в файле журнала появятся такие
записи:
<pre>
Sun Jun 4 15:30:17 2006: ===> LogServer started
Sun Jun 4 15:30:55 2006: [test2] Test message
Sun Jun 4 15:30:56 2006: [test3] Test message
Sun Jun 4 15:31:00 2006: ===> LogServer stopped [signal 2]
</pre>

Как видите, между записью сообщений от test2 и test3 прошла
одна секунда, хотя каждый клиент требует для своей обработки как
минимум 10. Значит, ожидание ответа от обоих клиентов выполняется
одновременно, чего мы и добивались.
===Ветвления===
Впрочем, select – это не единственный способ организовать параллельную работу в Python. Модуль os предоставляет функцию fork(),
которая использует одноимённый системный вызов, порождающий
копию текущего процесса. Чтобы посмотреть, как это работает на практике, напишем небольшой сценарий, который будет автоматически
запускать скрипты-клиенты для тестирования нашего сервера (действительно, негоже делать вручную то, что можно поручить программе). Код
представлен на врезке logclient2.py.

Здесь всё до безобразия просто – функция fork() (строка 6) порождает копию текущего процесса. В каждой копии выполнение кода будет
продолжено как ни в чём не бывало со следующей команды. Чтобы код
мог понять, где он выполняется – в родительском процессе или в дочернем, используется значение, возвращаемое функцией fork(). Дочерний
процесс получает значение 0, родительский – идентификатор порождённого дочернего процесса (PID).

Кстати, функция os._exit(0) в строке 10 позволяет завершить
дочерний процесс. Если этого не сделать, то он пойдёт на выполнение
цикла for (строка 5), уже сам выступая в качестве родительского и
порождая, таким образом, настоящую лавину новых процессов.

Естественно, таким образом можно было бы реализовать и наш
сервер – после метода accept() ответвлять дочерний процесс, который
занимался бы обслуживанием конкретного клиента, в то время как родительский продолжал бы «висеть» на методе accept(), ожидая входящие
соединения. Именно так и работают многие серверы, например, Apache
(версия 1.х – только так и никак иначе, а в 2.х появились потоки).

----

=== БЛОКИРОВАТЬ НЕОБЯЗАТЕЛЬНО ===
Модуль '''socket''' также предоставляет возможность работы с неблокирующими вызовами ''accept()'', ''send()'' и ''recv()''. Для
этого следует предварительно установить значение соответствующего атрибута объекта-сокета с помощью следующего
метода:
<source lang="python">
socket.setblocking(0)
</source>

Значение '''0''' переключает сокет в неблокирующий режим работы (по умолчанию используется блокирующий –
значение '''1'''). При этом методы ''accept()'', ''send()'' и ''recv()'' при отсутствии данных для обработки не останавливают
выполнение программы до их появления, а генерируют исключение ''socket.error''. Что с ним делать дальше – решать
вам. Например, можно просто игнорировать:
<source lang="python">
while(1):
try:
data = sock.recv()
except socket.error, errcode:
if errcode[0] == 35:
pass
else:
raise(socket.error)
</source>

Второй параметр оператора ''except'' – переменная, в которую будет занесён код ошибки. Этот код представляет собой
кортеж вида ('''35''', ‘Resource temporarily unavailable’), где первый элемент – числовой код ошибки, а второй –
текстовая строка-пояснение. При отсутствии данных генерируется ошибка '''35''', которую мы и игнорируем (''pass''). Здесь
мы получаем то же ожидание данных, но уже реализованное самим кодом Python. Но преимущество здесь в том, что
вместо оператора ''pass'' можно реализовать любую обработку. Например, переходить к опросу другого сокета.

===logserver.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-

import os, socket, time, signal, select

class LogServer:
def __init__(self, sockfile='./lserv.sock',
logfile='./lserv.log',
maxqueue=5):
self.logfilename = logfile
self.openlog()
self.sockfilename = sockfile
try:
if os.path.exists(sockfile):
os.unlink(sockfile)
except:
raise 'error'

self.socket = socket.socket(socket.AF_UNIX)
self.socket.bind(sockfile)
self.socket.listen(maxqueue)

signal.signal(signal.SIGHUP, self.reinit)
signal.signal(signal.SIGINT, self.stop)
signal.signal(signal.SIGTERM, self.stop)

self.writelog('===> LogServer started')

def openlog(self):
self.log = open(self.logfilename, 'a+')

def writelog(self, message):
self.log.write('%s: %s\n' % (time.asctime(), message))

def reinit(self, signum, frame):
self.log.close()
self.openlog()
self.start()

def start(self):
rsocks = []
wsocks = []
rsocks.append(self.socket)
senders = {}
while 1:
try:
reads, writes, errs = select.select(rsocks, wsocks, [])
except:
return

for sock in reads:
if sock == self.socket:
client, name = sock.accept()
rsocks.append(client)
elif not `sock` in senders.keys():
sender = sock.recv(1024)
sock.send('Sender OK')
senders[`sock`] = sender
else:
message = sock.recv(1024)
sock.send('Message OK')
self.writelog('[%s] %s' % (senders[`sock`], message))
rsocks.remove(sock)
del senders[`sock`]

def stop(self, signum, frame):
self.writelog('===> LogServer stopped [signal %s]' % (signum))
self.log.close()
os.unlink(self.sockfilename)

if __name__ == '__main__':
serv = LogServer(maxqueue=3)
serv.start()
</source>

===logclient.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-

import sys, socket, time

class LogClient:
def __init__(self, sender='generic client',
sockfile='./lserv.sock',
buffersize=1024,
testmode=0):
self.sender = sender
self.sockfile = sockfile
self.buffersize = buffersize
self.testmode = testmode

def writelog(self, message):
if self.testmode:
time.sleep(5)
self.socket = socket.socket(socket.AF_UNIX)
self.socket.connect(self.sockfile)
self.socket.send(self.sender)
if self.socket.recv(self.buffersize) == 'Sender OK':
if self.testmode:
time.sleep(5)
self.socket.send(message)
if not self.socket.recv(self.buffersize) == 'Message OK':
print 'Ошибка: нет подтверждения Message'
else:
print 'Ошибка: нет подтверждения Sender'
self.socket.close()

if __name__ == '__main__':
sendername = sys.argv[1]
client = LogClient(sender=sendername, testmode=1)
client.writelog('Test message')
</source>

===logclient2.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import os
from logclient import LogClient
for i in xrange(25):
pid = os.fork()
if pid == 0:
client = LogClient(sender='client%d' % i, testmode=1)
client.writelog('Test from client%d' % i)
os._exit(0)
else:
print 'Start child[%d]' % pid
</source>

LXF81:Python

2009-02-03T19:18:43Z

AndrewDjVu: /* logserver.py */

{{Цикл/Python}}

==Задачи многозадачности==
''часть 1 '''Сергей Супрунов''' открывает новый цикл статей, в котором будут более полно освещены некоторые практические моменты разработки приложений на языке Python. Начнём, пожалуй, с вопросов параллельных вычислений...''

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

В большинстве современных ОС эта идея имеет две реализации: процессы и потоки (причем в Linux одно практически неотличимо от другого).
Процесс, если говорить упрощённо, представляет собой некоторый набор
ресурсов (область памяти, значения процессорных регистров, открытые
дескрипторы файлов и т.д.), принадлежащих какой-то задаче. На однопроцессорных машинах одновременно может обрабатываться только
один процесс, остальные в это время находятся в очереди. Ядро системы,
точнее, его планировщик, в соответствии с заданным алгоритмом предоставляет доступ к процессору ожидающим процессам в соответствии с
их приоритетом. Если текущий процесс переходит в состояние ожидания
ввода-вывода, то доступ к процессору передаётся следующему процессу
в очереди. Благодаря этому, во-первых, реализуется более эффективное
использование ресурсов системы, а во-вторых, несколько задач могут
выполняться в одно и то же (с точки зрения пользователя) время.

Потоки (threads, их также называют нитями или облегчёнными процессами) решают аналогичную задачу, но в рамках одного процесса.
При управлении как потоками, так и процессами операционная система
вынуждена «непроизводительно» расходовать некоторые ресурсы на
так называемое переключение контекста (т.е. на выполнение «подготовительных» мероприятий, таких как восстановление значения регистров и адресного пространства). Благодаря тому, что потоки разделяют
некоторые ресурсы (например, память процесса, в рамках которого они
исполняются), переключение их контекста происходит заметно быстрее,
чем контекста процесса. Благодаря этому можно распараллеливать
задачи с заметно меньшими затратами. Хорошим примером может служить производительность Apache 2.x (см. обзор в [[LXF77:Apache 2.2|LXF77]]).

Хватит, пожалуй, теории. Посмотрим, какие средства предоставляет
язык Python программисту, желающему воспользоваться многозадачностью операционной системы, а заодно рассмотрим такие вещи как
сокеты и межпроцессорное взаимодействие.
===Сокеты===
Сокет (конечная точка сетевых коммуникаций) – это основа клиент-серверных приложений. Фактически, это интерфейс, с помощью которого процессы могут осуществлять обмен информацией между собой.
Конкретная реализация определяется так называемым коммуникационным доменом, наиболее распространённые из них – Internet-домен и
Unix-домен. Internet-сокеты позволяют реализовать взаимодействие на
базе протоколов сети Интернет, таких как TCP или UDP. О них мы подробнее поговорим в одной из следующих статей цикла.

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

В языке Python работа с сокетами реализована в модуле socket. Со стороны сервера создание сокета
(рассмотрим пример для домена Unix) выглядит следующим образом:
<source lang="python">
import socket # импортируем модуль
s = socket.socket(socket.AF_UNIX) # создаём сокет домена AF_UNIX
s.bind('/tmp/test.sock') # привязываем его к файлу
s.listen(1) # начинаем прослушивать
conn, addr = s.accept() # ждём подключения
conn.send('HELO') # дождавшись, отправляем клиенту строку
data = conn.recv(1024) # получаем от клиента данные
s.close() # закрываем сокет
</source>

Обратите внимание на то, что методы accept(), send(), recv() являются по умолчанию блокирующими,
т.е. работа программы приостанавливается до тех пор, пока не будет выполнено необходимое действие. Это
означает, что клиент и сервер должны (по крайней мере, в нашей простейшей реализации) строго придерживаться определённой последовательности действий (протокола). В нашем случае после установки соединения
сервер посылает строку приветствия. Если клиент, вместо того чтобы принять эту информацию, сам начнёт
что-то передавать, то мы получим взаимную блокировку – клиент будет ждать, пока сервер примет его данные,
сервер же будет ждать аналогичных действий со стороны клиента.

Для нормальной работы клиентская реализация должна выглядеть примерно так:
<source lang="python">
import socket # импортируем модуль
c = socket.socket(socket.AF_UNIX) # создаём сокет такого-же домена
c.connect('/tmp/test.sock') # подключаемся к сокету сервера
greeting = c.recv(1024) # принимаем строку приветсвия
c.send('Hello, server!') # отправляем свои данные
c.close() # закрываем соединение
</source>

Понятно, что в данном примере мы получили «одноразовый» сервер, который, дождавшись соединения и
приняв данные, завершает свою работу. Для постоянной работы фрагмент, начиная с метода accept(), нужно
поместить в бесконечный цикл (см. пример ниже).

===Модуль select===
В Python доступен ещё один способ повысить эффективность работы за счёт параллельного выполнения некоторых операций – модуль select. Он использует системный вызов select для мультиплексирования соединений клиентов в одном цикле событий – метод select этого модуля позволяет отслеживать одновременно
несколько сокетов или других файловых объектов (только на Unix-подобных системах) в ожидании готовности
одного из них, после чего управление возвращается основной программе. Благодаря этому программа может
обрабатывать сразу несколько сокетов по мере их готовности к взаимодействию. Познакомимся с этим модулем поближе.

Чтобы не замусоривать статью множеством фрагментов кода, приступим сразу к рассмотрению серьёзного примера, к которому будем обращаться по мере необходимости. Данный пример – простейший аналог
демона syslog, задача которого – получать через Unix-сокет информацию от клиентов и записывать её в файл
журнала. Если что-то не совсем понятно сразу, не обращайте на это внимание – всё прояснится к концу изложения. Код представлен на врезке logserver.py.

Чтобы в дальнейшем было проще модифицировать код, реализуем его в виде класса. В его конструкторе (метод __init__()) решаются три задачи:
открытие файла (стр. 8-9), удаление файла-сокета,
который может остаться в случае аварийного завершения сценария (стр. 10-15) и собственно создание
сокета (стр. 16-18). На строки 19-21 пока не обращайте внимания.

Методы openlog() и writelog() соответственно открывают лог-файл и записывают в него строку, предваряя текущей датой. Ну и метод start() –
основной, в котором и осуществляется обработка
входящих соединений.

Для того, чтобы сервер постоянно обслуживал
вверенный ему сокет, создаётся бесконечный цикл
(строка 37). Однако здесь есть небольшая проблема.
Вы же ещё помните, что методы accept(), recv() и
send() являются по умолчанию блокирующими? То
есть при «последовательной» обработке первый клиент, достучавшийся до сервера, полностью завладеет вниманием последнего, пока не завершит работу
согласно заданному протоколу. Остальные же будут
либо поставлены в очередь, либо вообще отброшены,
если размер очереди превысит установленное значение (задаётся параметром метода listen()). Только
полностью обслужив первого клиента, сервер сможет
вернуться к строке 44 и снова вызвать accept().

Если обмен с клиентом происходит быстро, то
такая схема работы вполне приемлема. Однако если
протокол требует ведения «диалога», в ходе которого возможны задержки, то это может стать серьёзной
проблемой. В рассматриваемом примере мы специально усложнили протокол, сделав его двухэтапным –
сначала клиент должен представиться, дождаться от
сервера подтверждения, затем отправить данные и
снова дождаться подтверждения.

Если между первой и второй отправкой данных возникнет пауза (в коде клиента она искусственно реализована функцией time.sleep()), то
сервер будет понапрасну простаивать, хотя вполне мог бы заняться обслуживанием других клиентов. Собственно, для этого и используется метод
select() одноимённого модуля (строка 39).

Принцип действия его следующий – он берёт на
себя ожидание данных в сокетах (массивы обслуживаемых сокетов передаются ему в виде параметров),
передавая управление основной программе, если
один из сокетов будет готов к обслуживанию.

Чтобы было понятнее, рассмотрим, что происходит
в нашем примере. В строке 39 мы запускаем метод
select(). Как только один (или несколько) из обслуживаемых сокетов (первоначально такой сокет только
один, созданный при инициализации объекта в строке 16) будет готов к обслуживанию, select() передаёт
основной программе массив сокетов, готовых к работе,
который обрабатывается в цикле (строка 42). Так, если
к работе готов «родительский» сокет, для него вызывается метод accept(). Поскольку метод select()
гарантирует, что запрос на соединение уже есть, то
основной программе не придётся тратить время на
ожидание – accept() будет обработан сразу, вернув
объект – новый сокет, предназначенный для работы с
данным клиентом. Но мы не начинаем сразу же выполнять установленный протокол, а просто помещаем этот
новый сокет в список rsocks, обслуживаемый методом
select() (строка 45).

Когда на этот сокет поступят данные от клиента, select() вновь сообщит о готовности. На этот
раз обработка пойдёт по ветке «else» (строка 46).
Поскольку наш протокол двухэтапный, то считывать
данные мы должны два раза, что и реализуется
дополнительной конструкцией «if – else» (строки 47-56): при первом «подходе» словарь senders не
будет содержать упоминания данного сокета (обратные кавычки позволяют работать не с самим сокетом,
а с его «строковым представлением»); при втором
же этот словарь уже будет содержать имя отправителя, ассоциированное с сокетом. На втором этапе
выполняется запись строки в лог-файл (строка 54),
удаление сокета из массива rsocks (строка 55), что-бы select() уже не занимался его обслуживанием, и
удаление записи из словаря (строка 56).

Обратите внимание, что мы не можем просто
взять и последовательно вызвать два метода recv()
для получения всех данных, поскольку второй вызов
окажется уже блокирующим – ведь на первый recv()
мы попадаем, только когда select() обнаружит готовые для обработки данные; во втором же случае
готовности придётся ждать самостоятельно.

По большому счёту, вызовы send() в нашем
примере получились блокирующие – если клиент
не сможет сразу принять переданное ему подтверждение, то сервер будет простаивать. Решается это
аналогичным путём, но уже с помощью массива
wsocks, однако из боязни сделать код чрезмерно
сложным и нечитаемым, в данном примере мы проигнорируем эту проблему, оставив её решение вам в
качестве упражнения.
===Сигналы===
Остались ещё две проблемы. Во-первых, хотелось
бы, чтобы сервер перед завершением своей работы (поскольку используется бесконечный цикл, то
это придётся делать «грубыми» методами вроде
команды kill или Ctrl+C) успевал выполнить некоторые полезные действия (например, закрыть файл
журнала, удалить файл сокета). Во-вторых, если в
процессе работы сервера удалить или переименовать лог-файл и создать новый с таким же именем
(например, это может происходить при ротации журнала утилитами типа logrotate), то дескриптор открытого файла (self.log в нашем примере) не изменится, продолжая указывать на прежнее расположение
файла в файловой системе. Так что запись будет
вестись по этому дескриптору, в уже переименованный или удалённый файл (поскольку на файл будет
оставаться ссылка, «привязанная» к дескриптору, то
при удалении из каталога он физически будет оставаться на месте, пока не будет удалён этот дескриптор) То есть нужно предусмотреть переинициализацию файла журнала.

Как команда kill, так и комбинация [Ctrl+C] реализуют метод межпроцессорного взаимодействия,
именуемый сигналами. Например, kill 3942 отправит
процессу номер 3942 сигнал 15 (SIGTERM), дающий
указание завершить работу. Ctrl+C отправляет сигнал 2 (SIGINT). Большинство сигналов процесс может
перехватить и обработать по собственному желанию,
чем мы и воспользуемся.

В Python для этого предназначен модуль signal.
Собственно, его мы и используем в строках 19–21,
назначая на некоторые сигналы в качестве обработчика метод stop(). Для сигнала 1 (SIGHUP) в качестве обработчика
назначается метод reinit(), который решает задачу переинициализации
открытого файла журнала.
===Тестирование===
Чтобы проверить работу нашего сервера, нам нужен клиент. Его код
представлен во врезке logclient.py. Никаких сложностей здесь нет.
Поясню лишь, что конструкции time.sleep(5) (стр. 15 и 21) искусственно создают задержку между первым и вторым этапами диалога.

Чтобы убедиться в том, что все клиенты обслуживаются сервером
параллельно, нужно запустить их в нескольких экземплярах (например, с разных консолей). В результате в файле журнала появятся такие
записи:
<pre>
Sun Jun 4 15:30:17 2006: ===> LogServer started
Sun Jun 4 15:30:55 2006: [test2] Test message
Sun Jun 4 15:30:56 2006: [test3] Test message
Sun Jun 4 15:31:00 2006: ===> LogServer stopped [signal 2]
</pre>

Как видите, между записью сообщений от test2 и test3 прошла
одна секунда, хотя каждый клиент требует для своей обработки как
минимум 10. Значит, ожидание ответа от обоих клиентов выполняется
одновременно, чего мы и добивались.
===Ветвления===
Впрочем, select – это не единственный способ организовать параллельную работу в Python. Модуль os предоставляет функцию fork(),
которая использует одноимённый системный вызов, порождающий
копию текущего процесса. Чтобы посмотреть, как это работает на практике, напишем небольшой сценарий, который будет автоматически
запускать скрипты-клиенты для тестирования нашего сервера (действительно, негоже делать вручную то, что можно поручить программе). Код
представлен на врезке logclient2.py.

Здесь всё до безобразия просто – функция fork() (строка 6) порождает копию текущего процесса. В каждой копии выполнение кода будет
продолжено как ни в чём не бывало со следующей команды. Чтобы код
мог понять, где он выполняется – в родительском процессе или в дочернем, используется значение, возвращаемое функцией fork(). Дочерний
процесс получает значение 0, родительский – идентификатор порождённого дочернего процесса (PID).

Кстати, функция os._exit(0) в строке 10 позволяет завершить
дочерний процесс. Если этого не сделать, то он пойдёт на выполнение
цикла for (строка 5), уже сам выступая в качестве родительского и
порождая, таким образом, настоящую лавину новых процессов.

Естественно, таким образом можно было бы реализовать и наш
сервер – после метода accept() ответвлять дочерний процесс, который
занимался бы обслуживанием конкретного клиента, в то время как родительский продолжал бы «висеть» на методе accept(), ожидая входящие
соединения. Именно так и работают многие серверы, например, Apache
(версия 1.х – только так и никак иначе, а в 2.х появились потоки).

----

=== БЛОКИРОВАТЬ НЕОБЯЗАТЕЛЬНО ===
Модуль '''socket''' также предоставляет возможность работы с неблокирующими вызовами ''accept()'', ''send()'' и ''recv()''. Для
этого следует предварительно установить значение соответствующего атрибута объекта-сокета с помощью следующего
метода:
<source lang="python">
socket.setblocking(0)
</source>

Значение '''0''' переключает сокет в неблокирующий режим работы (по умолчанию используется блокирующий –
значение '''1'''). При этом методы ''accept()'', ''send()'' и ''recv()'' при отсутствии данных для обработки не останавливают
выполнение программы до их появления, а генерируют исключение ''socket.error''. Что с ним делать дальше – решать
вам. Например, можно просто игнорировать:
<source lang="python">
while(1):
try:
data = sock.recv()
except socket.error, errcode:
if errcode[0] == 35:
pass
else:
raise(socket.error)
</source>

Второй параметр оператора ''except'' – переменная, в которую будет занесён код ошибки. Этот код представляет собой
кортеж вида ('''35''', ‘Resource temporarily unavailable’), где первый элемент – числовой код ошибки, а второй –
текстовая строка-пояснение. При отсутствии данных генерируется ошибка '''35''', которую мы и игнорируем (''pass''). Здесь
мы получаем то же ожидание данных, но уже реализованное самим кодом Python. Но преимущество здесь в том, что
вместо оператора ''pass'' можно реализовать любую обработку. Например, переходить к опросу другого сокета.

===logserver.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-

import os, socket, time, signal, select

class LogServer:
def __init__(self, sockfile='./lserv.sock',
logfile='./lserv.log',
maxqueue=5):
self.logfilename = logfile
self.openlog()
self.sockfilename = sockfile
try:
if os.path.exists(sockfile):
os.unlink(sockfile)
except:
raise 'error'

self.socket = socket.socket(socket.AF_UNIX)
self.socket.bind(sockfile)
self.socket.listen(maxqueue)

signal.signal(signal.SIGHUP, self.reinit)
signal.signal(signal.SIGINT, self.stop)
signal.signal(signal.SIGTERM, self.stop)

self.writelog('===> LogServer started')

def openlog(self):
self.log = open(self.logfilename, 'a+')

def writelog(self, message):
self.log.write('%s: %s\n' % (time.asctime(), message))

def reinit(self, signum, frame):
self.log.close()
self.openlog()
self.start()

def start(self):
rsocks = []
wsocks = []
rsocks.append(self.socket)
senders = {}
while 1:
try:
reads, writes, errs = select.select(rsocks, wsocks, [])
except:
return

for sock in reads:
if sock == self.socket:
client, name = sock.accept()
rsocks.append(client)
elif not `sock` in senders.keys():
sender = sock.recv(1024)
sock.send('Sender OK')
senders[`sock`] = sender
else:
message = sock.recv(1024)
sock.send('Message OK')
self.writelog('[%s] %s' % (senders[`sock`], message))
rsocks.remove(sock)
del senders[`sock`]

def stop(self, signum, frame):
self.writelog('===> LogServer stopped [signal %s]' % (signum))
self.log.close()
os.unlink(self.sockfilename)

if __name__ == '__main__':
serv = LogServer(maxqueue=3)
serv.start()
</source>

===logclient.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import sys, socket, time
class LogClient:
def __init__(self, sender='generic client',
sockfile='./lserv.sock',
buffersize=1024,
testmode=0):
self.sender = sender
self.sockfile = sockfile
self.buffersize = buffersize
self.testmode = testmode
def writelog(self, message):
if self.testmode:
time.sleep(5)
self.socket = socket.socket(socket.AF_UNIX)
self.socket.connect(self.sockfile)
self.socket.send(self.sender)
if self.socket.recv(self.buffersize) == 'Sender OK':
if self.testmode:
time.sleep(5)
self.socket.send(message)
if not self.socket.recv(self.buffersize) == 'Message OK':
print 'Ошибка: нет подтверждения Message'
else:
print 'Ошибка: нет подтверждения Sender'
self.socket.close()
if __name__ == '__main__':
sendername = sys.argv[1]
client = LogClient(sender=sendername, testmode=1)
client.writelog('Test message')
</source>

===logclient2.py===
<source lang="python" line="GESHI_NORMAL_LINE_NUMBERS">
#!/usr/bin/python
# -*- coding: utf-8 -*-
import os
from logclient import LogClient
for i in xrange(25):
pid = os.fork()
if pid == 0:
client = LogClient(sender='client%d' % i, testmode=1)
client.writelog('Test from client%d' % i)
os._exit(0)
else:
print 'Start child[%d]' % pid
</source>