Ruby/Сети: различия между версиями

На руках у него уже была серверная часть программы, которая позволяла манипулировать удалённой файловой системой:

 

server = TCPServer.new('localhost', 3000)

while (srv = server.accept)

end

srv.close

 

Программка, конечно, хорошая, но сдаётся мне, что она не работает. Первое, на что следует обратить внимание, — это закрытие соединения после выполнения каждой команды. При работе с этим сервером через [[w:Telnet|telnet]] будут возникать определённые проблемы. Давайте предельно упростим специализированный код этой программы и посмотрим на структуру клиент-серверного приложения.

 

TCPServer.open('localhost', 3000){ |server|

if (session = server.accept)

}

end

 

Для того, чтобы соединиться с этим сервером, необходимо выполнить команду <code>telnet</code> и набрать <code>o localhost 3000</code>. После успешного соединения можете набирать команды <code>ls</code>, <code>cd</code> или <code>shutdown</code>.

Несмотря на то, что данный сервер вполне рабочий, у него есть один существенный недостаток — он не работает для нескольких клиентов. Для того, чтобы это реализовать необходимо обрабатывать каждое соединение с клиентом в отдельном потоке. Кто изучал мультипроцессорное программирование, тот понимает о чём речь. Но не стоит сразу кидаться в книжный магазин за необходимой литературой. В составе дистрибутива Ruby уже есть замечательная библиотека <code>gserver</code>, которая как раз и занимается тем, что реализует обработку запросов клиентов в отдельных потоках. Для демонстрации её работы перепишем предыдущую программу под <code>gserver</code>.

 

class Troyan < GServer

def serve(session)

troyan.audit = true

troyan.start

 

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

Итак, давайте наберём клиентский код, который будет соединяться с нашей серверной частью:

 

TCPSocket.open('localhost', 31337){ |client|

2.times{ puts client.gets.chomp }

puts client.read

client.puts "shutdown"

 

Всё замечательно, но программа не работает. Не вся, конечно… Она выводит приглашение к диалогу и всё, дальше виснет. Это связано с тем, что используется метод <code>.read</code>, который считывает весь поток целиком, пока не встретит символ EOF. Его-то наш сервер как раз и не передаёт. Не будем пока спешить и править сервер, а применим один приём: будем использовать не метод <code>.read</code>, а метод <code>.sysread(n)</code>. Метод <code>.sysread(n)</code> считывает первых <code>n</code> символов из потока. Так как мы не знаем, сколько нам надо считать символов, то мы зададим в качестве <code>n</code> очень большое число. Например, <code>5000</code>. Если символов в потоке меньше, чем <code>5000</code>, то <code>.sysread(n)</code> считает столько, сколько есть. Эту особенность мы и используем.

 

TCPSocket.open('localhost', 31337){ |client|

2.times{ puts client.gets.chomp }

puts client.sysread(5000)

client.puts "shutdown"

 

Уже лучше. По крайней мере, программа работает. Но давайте поразмышляем над ситуацией, которая произошла с методом <code>.read</code>. Если немного подправить сервер и выдавать после каждой передачи этот символ, то программа с <code>.read</code> могла бы с успехом работать. Какова здесь мораль? А мораль в том, что для успешной работы необходимо с сервера передавать сигнал, который означал бы «последняя строка, которую я передаю клиенту». Чтобы клиент не пытался читать данные с сервера, а начинал их передачу. Вполне естественно, что добавление такого сигнала означает модификацию сервера. В качестве сигнала последней строки мы будем использовать строку <code>+ОК</code>. Почему именно такую? Просто видел её где-то, вот и решил использовать. Если хотите, то можете использовать свою строку. Только не забудьте об этом, когда будете писать программу-клиент. Вот модифицированный сервер:

 

class Troyan < GServer

def serve(session)

troyan.audit = true

troyan.start

 

Была добавлена лишь одна команда (хотя самые внимательные могут заметить, что ещё и метод <code>.print</code> был заменён на <code>.puts</code>) — <code>session.puts "+OK"</code>. Она будет выполнятся после каждой передачи данных от сервера к клиенту. Тем самым мы будем извещать клиента о том, что передача завершается. Теперь перепишем клиент. Необходимо исправить код там, где происходит чтение, чтобы он учитывал строки <code>+OK</code>.

 

TCPSocket.open('localhost', 31337){ |client|

2.times{ puts client.gets.chomp }

end

client.puts "shutdown"

 

Стоит отметить, что предложено три варианта обработки строки <code>+OK</code>. Правда, отличаются они лишь в деталях и функционально делают одно и то же. Давайте рассмотрим подробней решения, которые были реализованы в ходе исправления:

Из всех предложенных вариантов вы вольны выбирать любой. Но мне не нравится вообще весь клиент. Как-то он сильно разросся и теперь выглядит монстрозно. Конечно же, есть возможность загнать чтение в отдельный метод, но мы этого делать не будем. Хотя, где наша не пропадала?! Давайте вынесем код отсылки команды и получения ответа в отдельный код. Естественно, что это будет метод для класса <code>TCPSocket</code> (который мы будем расширять). Назовем мы его <code>.cmd</code>.

 

def cmd(command, regexp = /^\+OK/)

self.puts command

end

end

 

Итак, теперь все экземпляры класса <code>TCPSocket</code> приобрели метод <code>.cmd</code>, который отсылает команды и принимает результат. Непонятными могут быть следующие моменты:

Теперь остаётся исправить клиент и посмотреть на него в действии:

 

2.times{ puts client.gets.chomp }

client.cmd("ls"){ |str| puts str }

client.cmd("ls"){ |str| puts str }

client.cmd("shutdown"){ |str| puts str }

 

Обратите внимание на код:

 

 

Метод <code>.cmd</code> работает как итератор. Последовательно передавая пришедшие строки в замыкание для дальнейшей обработки.

Это всё потому, что передача команды <code>shutdown</code> не подразумевает ответа. А это неправильно. В очередной раз исправим сервер, чтобы избавится от этой ошибки:

 

class Troyan < GServer

def serve(session)

troyan.audit = true

troyan.start

 

На этом можно было бы и закончить, если бы не одно «но»: метод <code>.cmd</code> уже реализован в рамках класса <code>Net::Telnet</code>. И не переписать наш клиент под этот класс было бы неправильно. Переписываем:

 

client = Net::Telnet.new('Host'=>'localhost', 'Port'=>31337, "Prompt"=>/^\+OK/n)

client.cmd("ls"){ |str| puts str }

client.cmd("cd .."){ |str| puts str }

client.cmd("ls"){ |str| puts str }

 

Вот теперь уж точно всё!

Вскоре, после публикации данной главы в учебнике, Geka прислал клиентскую часть, которую он реализовал в две строчки:

 

 

Способ не совсем честный, но нет причин о нём не рассказать. Данный способ использует метод <code>system</code>, который вызывает внешнюю программу (в данном случае <code>telnet</code>). Далее все введенное с клавиатуры уходит в программу <code>telnet</code>, а выдаваемое на экран берётся из результата работы этой программы.

Теперь, собственно, сама программа:

 

server = WEBrick::HTTPServer.new(:Port=>8080)

server.mount_proc('/'){ |req, resp|

}

 

 

Рассмотрим код более подробно.

Давайте посмотрим, как может выглядеть наша программа в которой используется ERB-шаблон:

 

require 'erb'

server = WEBrick::HTTPServer.new(:Port=>8080)

resp.body = ERB.new(template).result

}

 

Что изменилось? Изменений немного, но они все же есть:

Файл с ERB-шаблоном (<code>index.html</code>) будет выглядеть следующим образом:

 

<body>

<center>

</center>

</body>

 

Переменную шаблон мы убираем, а вместо неё вставим считывание файла c ERB-шаблоном(<code>index.html</code>).

 

require 'erb'

server = WEBrick::HTTPServer.new(:Port=>8080)

resp.body = ERB.new(IO.read('index.html')).result

}

 

Вот, уже другое дело! Можно было бы этим и ограничиться, если бы в библиотеке WEBrick отсутствовал бы ERB-сервлет… Но он есть!

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

 

server = WEBrick::HTTPServer.new(:Port=>8080)

server.mount('/', WEBrick::HTTPServlet::ERBHandler, 'index.html')

 

Самые внимательные читатели заметили, что строка <code>require 'erb'</code> волшебным образом испарилась. Связано это с тем, что реализация ERB-сервлета уже подключает библиотеку ERB.

Но чтобы добиться столь существенного уменьшения кода программы, пришлось немного изменить файл <code>index.html</code> (с ERB-шаблоном):

 

<html><body><center><form method=post>

<textarea name="text" rows="4" cols="40"><%=IO.read('notepad.txt')%></textarea><br/>

<input type="submit" name="update" value="Сохранить" />

 

Как можно заметить, в самое начало шаблона был добавлен тег, который осуществляет сохранение содержимого переменной <code>text</code> в файл <code>notepad.txt</code>. Код тега был перенесён из программы практически один к одному. За одним только исключением: к переменной <code>text</code> мы теперь обращаемся через переменную <code>query</code>, а не через <code>req.query</code>.

Открываем новую серию статей, которые будут рассказывать про использование встроенных библиотек Ruby. Первая статья будет посвящена написанию утилиты <code>ping</code> (в очень упрощённой форме). Смотрим в стандартную библиотеку и обнаруживаем файлик <code>ping.rb</code>. Смотрим в него и обнаруживаем метод <code>pingecho</code>. Метод используется следующим образом:

 

host = ARGV[0] || "localhost"

 

Данный метод имеет один маленький недостаток. Он не отслеживает никаких ошибок кроме <code>Timeout::Error и Errno::ECONNREFUSED</code>. Меня это немного смутило и поэтому я убрал явное указание на <code>Timeout</code>. Получился примерно такой метод:

 

require 'timeout'

def ping(host, service = "echo", timeout = 5)

end

end

 

Итак, давайте разберём, что делает наш метод. Он создаёт соединение посредством класса <code>TCPSocket</code> и тут же закрывает его. Если соединение проходит слишком долго (хост не существует в сети) или произошла какая-то другая ошибка (не поддерживается протокол или ещё что-то), то метод возвращает <code>false</code>. Если удалённый хост явно отверг наш запрос или принял его, то мы возвращаем <code>true</code>.

Её я решил писать в логи следующим образом. Каждый день будет создаваться файл лога и каждый час в него будет писаться информация о работе службы. В качестве планировщика заданий использовался виндовый [http://www.nncron.ru/ Cron], который запускал мою программу в нужное время. Для начала я написал программу, которая соединяется со службой SMTP и получает от него баннер:

 

 

request = ""

File.open(Time.now.strftime('d:/logs/smtp/%Y_%m_%d.smtp'), File::APPEND | File::CREAT | File::WRONLY){ |f|

f.puts("#{sprintf('%02d', Time.now.hour)} | #{end_time-begin_time} | #{request}")

 

Как и следовало ожидать, программа не работала. Она подвисала и не хотела ничего писать в файл. Висела она на строчке:

 

 

Чтобы разобраться с проблемой, пришлось читать книжку. Слава богу, что под рукой оказалась книга [http://books.dore.ru/bs/f1bid1824.html TCP/IP. Учебный курс]. В ней на странице 345 чёрным по серому была начертана схема взаимодействия SMTP протокола. Как оказалось, чтобы получить баннер от службы, надо послать команду <code>NOOP</code>.

Переписываем наш фрагмент программы.

 

 

request = ""

File.open(Time.now.strftime('d:/logs/smtp/%Y_%m_%d.smtp'), File::APPEND | File::CREAT | File::WRONLY){ |f|

f.puts("#{sprintf('%02d', Time.now.hour)} | #{end_time-begin_time} | #{request}")

 

Великолепно! Программа работает… но иногда зависает. И тогда меня посетила ещё одна мысль: на соединение отводить всего одну секунду (не уложился — сам дурак). Если соединение зависало, то в файл записывалось <code>timeout</code>. Чтобы «отводить время на выполнение операции» нужно задействовать библиотеку <code>timeout</code>. Она у меня входила в состав дистрибутива. Итак, переписываем нашу программу:

 

require 'socket'

 

File.open(Time.now.strftime('d:/logs/smtp/%Y_%m_%d.smtp'), File::APPEND | File::CREAT | File::WRONLY){ |f|

f.puts("#{sprintf('%02d', Time.now.hour)} | #{beachmark} | #{request}")

 

Всё бы хорошо, но вот <code>beachmark</code> хотелось бы считать «по-взрослому», а именно при помощи пакета <code>benchmark</code>. И снова переписываем код:

 

require 'socket'

require 'benchmark'

File.open(PATH_LOG_SMTP + Time.now.strftime('d:/logs/smtp/%Y_%m_%d.smtp'), File::APPEND | File::CREAT | File::WRONLY){ |f|

f.puts("#{sprintf('%02d', Time.now.hour)} | #{beachmark} | #{request}")

 

И тут мы замечаем, что <code>Benchmark</code> очень многословен. Он выдаёт информацию в виде:

Нам нужен только <code>real</code>. Всё остальное — для более детального анализа. Поэтому немного доработаем результат замыкания <code>measure</code>:

 

timeout(1){

t = TCPSocket.open('mail.scli.ru', 'smtp')

t.close

}

 

Или можно просто вместо <code>Benchmark.measure</code> использовать <code>Benchmark.realtime</code>. Теперь надо разделить ошибки по таймауту и ошибки соединения. Для этого надо добавить ещё один блок <code>;rescue</code>. Кроме того, мне не понадобится всё сообщение от службы. Мне и кода сообщения достаточно. Смотрим, что получилось:

 

require 'benchmark'

require 'timeout'

File.open(Time.now.strftime('d:/logs/smtp/%Y_%m_%d.smtp'), File::APPEND | File::CREAT | File::WRONLY){ |f|

f.puts("#{sprintf('%02d', Time.now.hour)} | #{beachmark} | #{request}")

 

А теперь вопрос: как переписать программу так, чтобы она могла тестировать не только SMTP, но и [[w:HTTP|HTTP]], [[w:FTP|FTP]], [[w:POP3|POP3]] и так далее? Это уже для самостоятельного изучения.

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

 

 

h = Net::HTTP.new('www.minjust.ru', 80)

from_file = f.readlines.map{ |str| str.chomp }.compact

f.puts((from_inet - (from_file & from_inet)).sort)

 

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

Для скачивания HTML-страниц обычно используется протокол HTTP. Адрес страницы задаётся в виде URL. В Ruby существует несколько способов скачать страницу по протоколу HTTP. Начнём с самого древнего — класса <code>Net::HTTP</code> (древнее только Socket’ы, но про них мы умолчим). Для определённости мы будем скачивать этот учебник и сохранять его в виде файла <tt>RubyBook.html</tt>.

 

 

Net::HTTP.start('ru.wikibooks.org'){ |http|

file.write http.get('/wiki/Ruby').body

}

 

Недостатком использования класса <code>Net::HTTP</code> является то, что URL разбивается на две части: адрес сервера (<code>ru.wikibooks.org</code>) и адрес страницы (<code>/wiki/Ruby</code>). Такое разбиение удобно только в том случае, когда необходимо скачивать несколько HTML-страниц с одного сервера. А вот как раз такие ситуации возникают крайне редко. Чаще приходится запрашивать страницы с различных серверов. Для этих целей и был придуман метод <code>open</code> из библиотеки <code>open-uri</code>. Он самостоятельно разбирает URL и производит нужный запрос (не только HTTP).

 

 

File.open('RubyBook.html', 'w'){ |file|

file.write open('http://ru.wikibooks.org/wiki/Ruby').read

 

Обратите внимание, что необходимо указывать полный URL с указанием протокола (в данном случае <code>http://</code>).

Во время скачивания передаётся не только сама страница (''тело сообщения'' или на {{англ|body}}), но и техническая информация (''заголовок'' или на {{англ|head}}). Мы ещё не раз будем свидетелями такого поведения в протоколах сети Интернет. В заголовке содержится информация об успешности запроса (код возврата), типе передаваемых данных, кодировке, HTTP-сервере и так далее. Для примера, мы будем производить HTTP-запрос и получать ответ только в виде заголовка. Запись заголовка в файл производить не будем, так как в реальной практике этот приём практически не используется. Сначала «потренируемся на кошках», то есть на классе <code>Net::HTTP</code>:

 

 

Net::HTTP.start('ru.wikibooks.org'){ |http|

p http.head('/wiki/Ruby')

 

Как и обещалось ранее, вывод заголовка мы делаем на экран. А запрос заголовка, вместо тела сообщения, осуществляется простой заменой метода <code>.get</code> на метод <code>.head</code>. А как тогда получить заголовок и тело сообщения одновременно? Очень просто:

 

 

Net::HTTP.start('ru.wikibooks.org'){ |http|

head, body = http.get('/wiki/Ruby')

 

Для этого достаточно присвоить результат метода <code>.get</code> двум переменным. Произойдёт присвоение списков, и в первую переменную попадет заголовок, а во вторую — тело сообщения.

Теперь рассмотрим, как выглядит чтение заголовков в методе <code>open</code> библиотеки <code>open-uri</code>:

 

 

 

Замена метода <code>.read</code> на метод <code>.meta</code> позволяет нам дотянуться до заголовка. Заголовок имеет вид ассоциативного массива (объект класса <code>Hash</code>), где ключом является имя параметра (по стандарту [[w:MIME|MIME]]), а значением — значение параметра. Читать одновременно заголовок и тело сообщения можно вот так:

 

 

open('http://ru.wikibooks.org/wiki/Ruby/'){ |f|

p f.meta

p f.read

 

Мы использовали свойство метода <code>.open</code> прикреплять к себе замыкание.

Необходимость HTTP-запроса через прокси возникает, когда соединение с целевым сервером напрямую невозможно (например, администратор сети посчитал, что соединение посредством шлюза даёт ему слишком мало возможностей контроля за трафиком). Использование подобного запроса маловероятно, но необходимо знать о возможности посылки HTTP-запроса через прокси. Начнём с класса <code>Net::HTTP::Proxy</code>:

 

 

Net::HTTP::Proxy('you.proxy.host', 8808).start('ru.wikibooks.org'){ |http|

p http.get('/wiki/Ruby').body

 

Добавив всего лишь небольшой фрагмент кода, мы получили работу через прокси. В нашем случае использовался прокси-сервер с адресом <code>you.proxy.host</code>, который предоставляет прокси-доступ через порт <code>8808</code>.

Теперь посмотрим, как эта же самая функциональность можеть быть реализована с использованием метода <code>open</code> (из библиотеки <code>open-uri</code>).

 

 

 

Добавился второй параметр (ассоциативный массив с единственной парой) в вызове метода <code>open</code>. К слову сказать, во втором параметре можно указать множество параметров запроса (например, название браузера).

Для того, чтобы проверить работает ли библиотека <code>WEBrick</code> я выполнил следующий код:

 

 

 

После успешного запуска сервера, я запустил [[w:Mozilla Firefox|Firefox]] и набрал адрес: <code>http://localhost:8080/</code>. И тут я узнал, что директория <code>public_html</code> пуста. Горевал я по этому поводу не долго и быстро создал файл <code>public_html/index.html</code> примерно следующего содержания:

 

 

После обновления страницы на экране красовалась крупная надпись: «Сервер работает!» Всё! Мы с вами написали свой первый веб-сервер.

Настало время разобраться в том, как это всё работает:

 

 

Подключение библиотеки <code>WEBrick</code>. Ничего интересного и неожиданного здесь не произошло.

 

 

Библиотека <code>WEBrick</code> реализована в виде модуля с одноимённым названием, поэтому до любого класса приходится «дотягиваться» через префикс: <code>WEBrick::</code>.

Вернёмся к заказанной мне программе. Она будет состоять из двух частей: обычная html-страница (<code>index.html</code>) и [[w:Сервлет|сервлет]] (<code>/input</code>). Страница <tt>public_html/index.html</tt> будет содержать форму, в которую будут вводится исходные данные. Её задачей будет формирование запроса для сервлета. Сервлет <code>/input</code> будет получать номера подразделений, а выдавать их названия и ФИО действующих начальников. Вот код <code>public_html/index.html</code>:

 

<table border=0 bgcolor=#000000 width=350><tr><td><table border=0 bgcolor=#CCCCFF width=100%>

<tr><td align=right>Лит-1 - 01</td><td><input type="checkbox" name="check_01"></td>

<tr><td align=right>Поленов</td><td><input type="checkbox" name="check_011"></td>

<td><input type="checkbox" name="check_012"></td><td>Копылов</td></tr>

 

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

Теперь рассмотрим серверную часть программы (сервлет <code>/input</code>), которая будет обрабатывать запросы (сформированные файлом <code>public/index.html</code>). Сервлет является частью сервера. Поэтому листинг сервера будет одновременно и листингом сервлета.

 

'check_01'=>"\tНачальнику Лит-1\tБокову Ю.В.",

'check_02'=>"\tНачальнику ГЛЦЧ\tНазарову А.В.",

</textarea><br/><input type='submit' value='Повторим?'></form></div></body></html>!

}

 

Начинаем разбираться с кодом веб-сервера:

Реализует взаимосвязь запроса с CGI-приложением, то есть считывается первая строка и вытаскивается оттуда путь к интерпретатору. Далее производится запуск интерпретатора, которому параметром передаётся вызванный файл. Строка для CGI-приложений на Ruby будет выглядеть приемерно так:

 

 

для операционных систем семейства Unix

Кстати, я столкнулся с тем, что под Windows CGI-сервлеты отказывались работать. Это связано с тем, что <code>WEBrick</code> считает, что для того, чтобы запустить скрипт достаточно просто его вызывать (<code>./sctipt_name</code>) и он сам запустится. Понятное дело, что в Windows такое работать не будет. Поэтому мне пришлось немножко переписать часть библиотеки WEBrick, которая отвечает за запуск CGI-программ. Для того, чтобы мои изменение стали доступны и вам, я написал небольшую программку, которая устанавливает себя куда надо:

 

file.puts IO.read($0).split('#'*10).last

}

else

exec(ENV["SCRIPT_FILENAME"])

 

Немного поясню. Первая строчка — это программа, которая записывает нижеследующий код в папку с библиотеками.

Для того, чтобы было проще пользоваться всеми видами сервлетов WEBrick я написал небольшую программку, которая создаёт метод <code>mount_file</code> (для файлового сервлета), <code>mount_erb</code> (для ERB-сервлета) и <code>mount_cgi</code> (для CGI-сервлета). Как вы могли заметить, <code>mount_proc</code> уже существует (собственно, его название и послужило прототипом для остальных). Вот эта программа:

 

module WEBrick

class HTTPServer

}

end

 

Теперь можно использовать эти сервлеты следующим образом:

 

module WEBrick

class HTTPServer

server.mount_cgi('/hello', 'cgi-bin/hello.exe')

server.mount_cgi('/hello.cgi', 'cgi-bin/hello.rb')

 

Ну вот и всё, что можно сказать по сервлетам.