Глубины Indy. 2. Техническая поддержка
 Скачать 1.03 Mb.
|
|
10.2.1.1. Примеры Здесь пример некоторых кодов состояния, полученные от HTTP протокола. Как вы видите они относятся к разным категориям по первой цифре. 200 Ok 302 Redirect 404 Page not found 500 Internal Error 10.2.2. RFC – ответ (reply) RFC ответ, возвращает код состояния. 10.2.3. RFC – отклик (response) RFC отклик это текстовый ответ, ограниченный строкой с одной точкой в начале. Если данные содержат строку, которая содержит точку, то она перекодируется в две точки перед передачей, и обратно преобразовываться в одну при приеме. RFC отклики очень применимы, когда заранее неизвестно количество возвращаемых данных. Это используется в HTTP, Mail, News и других протоколах. Методы Indy, которые поддерживают RFC отклики – это Capture (для приема) и WriteStrings (для передачи). 10.2.4. RFC - транзакции Транзакция RFC это общение, которое состоит из команды, ответа и дополнительного отклика, все в формате RFC. Обработчики команд и другие части Indy построены на транзакциях RFC. Примет транзакции: 50 GET File.txt 201 File follows Hello, Thank you for your request, however we cannot grant your request for funds for researching as you put it in your application "A better mouse trap". Thank you, and please do not give up. . 10.3. Класс TIdRFCReply TIdRFCReply обладает возможностью посылки и приема RFC ответов. TIdRFCReply имеет три основных свойства: NumericCode, Text и TextCode. NumericCode и TextCode взаимно исключающие. TextCode – свойство, которое управляет такими протоколами, как POP3 и IMAP4. Для генерации ответа, установите свойство NumericCode (или TextCode) и дополнительно введите текст в свойство Text. Свойство Text типа TStrings позволяет многострочные ответы. TIdRFCReply имеет методы для записи форматированных ответов, и также для разбора текста в TIdRFCReply. TIdRFCReply используется для посылки ответов на команды, и также для свойств ReplyException, ReplyUnknown и Greeting properties класса TIdTCPServer. 10.4. Класс ReplyTexts Цифровой код в ответе обычно уникален для каждой ошибки. Например, протокол HTTP использует код 404 для "Resource not found". Многим командам разрешено возвращать код 404 как ошибку, но код 404 всегда должен означать одну и туже ошибку. Для преодоления дублирования текстов для ошибки 404 класс TIdTCPServer имеет свойство ReplyTexts. Свойство ReplyTexts – это коллекция экземпляров TIdRFCReply, которые могут быть обработаны, как в ран-тайм, так и в дизайн-тайм. Свойство ReplyTexts используется для обработки списка текстов, которые связаны с цифровым кодом. Когда свойство TIdRFCReply используется в TCPServer, который имеет цифровой код, но не имеет текстовой части, Indy просматривает в ReplyTexts и использует строку от туда. Вместо включения текста, в каждый ответ 404 посмотрите ниже: ASender.Reply.SetReply(404, 'Resource Not Found' ); Затем может использоваться следующий код: ASender.Reply.NumericCode := 4 04; Перед тем, как Indy посылает ответ, она сначала устанавливает свойство Text из найденного в ReplyTexts. Это позволяет хранить все тексты ответов в одном месте, позволяя легко управлять ими. 10.5. Курица или яйцо? 51 При построении системы, в которой вы должны построить, и сервер, и клиента, возникает следующий вопрос - "что делать сначала, клиента или сервера?". Оба нужны одновременно для отладки. Ответ прост, проще построить сервер первым. Для тестирования клиента, вы должны иметь сервер. Для тестирования сервера вам нужен клиент. Но поскольку, протоколы как правило текстовые, то клиент легко эмулировать с помощью телнета. Для тестирования, подсоединитесь к серверу на его порт. В командной строке введите: Telnet newsgroups.borland.com 119 Теперь нажмите клавишу enter. После соединения вы должны увидеть экран, подобный нижнему рисунку. На Windows 95/98/ME и NT это может выглядеть немного иначе, чем на Windows 2000 или на Windows XP, но результат должен быть таким же. Другие версии Windows загружают телнет, как новое приложение в свом окне. Выше показанный рисунок относится к Windows XP, в котором телнет является консольным приложением. Команда "Telnet newsgroups.borland.com 119" указывает клиенту телнета, подсоединиться к newsgroups.borland.com на порт 119. Порт 119 используется для протокола NNTP (News). Подобно подсоединения к серверу новостей Borland, телнет может использоваться для соединения с любым сервером, использующим текстовый протокол. Для отсоединения от сервера новостей введите команду "Quit" и нажмите enter. 10.6. Определение пользовательского протокола Задача сетевого разработчика состоит не только во взаимодействии с существующими системами, но часто и в создании собственных. В таком случае требуется создание своего протокола. Первым шагом построения клиента или сервера – это разработка протокола. Для стандартных протоколов, это решается изучением соответствующего RFC. Если же протокол не стандартный, или уже определен, то должен быть определен. При определении протокола, должны быть сделаны следующие решения: 52 Текстовые или двоичные команды? Пока нет особых требований, используйте текстовые команды. Текстовые команды проще для понимания и для отладки. TCP или UDP? Это определяется от требований к протоколу. Изучите все характеристики и решите с осторожностью. В большинстве случаев TCP правильный выбор. Порт – каждому серверному приложению требуется выделенный порт для прослушивания. Порты ниже 1024 резервированы и никогда не должны использоваться, кроме реализации протокола, которому уже назначен порт ниже 1024. После определения команд, также должны быть определены ответы и отклики. 10.7. Симуляция другой стороны (Peer Simulation) Традиционно естественный путь построения клиента и сервера – это сначала построение сервера, а затем клиента или построения их параллельно. Но Indy имеет возможность построить клиент или сервер, отдельно друг от друга. В некоторых случаях, один может быть построен без необходимости доступа к другому. В таких случаях может использоваться эмуляция (видимо симуляция, судя по названию главы) другой стороны. Эмуляция другой стороны будет обсуждена позже в главе 14. Отладка. 10.8. Протокол получения почтового кода В данной главе более подробно обсуждается Протокол получения почтового кода, который был представлен ранее в его клиенте. Сам сервер будет обсужден позже. Проект был разработан так, чтобы быть как можно более простым. Сервер получения почтового кода (Zip код в Америке) позволяет клиенту запросить город и штат, к которому относится почтовый код. Примерные данные, которые использует сервер, относятся к американским почтовым кодам, которые у них называются zip коды. Протокол может обрабатывать и другие коды, но американские коды уже заложены в демо программу. Для тех, кто находится за пределами Соединенных Штатов Америки и не знаком с их системой, zip это почтовый код в США, который указывает регион доставки. Zip коды цифровые и состоят из 5 цифр. Zip коды могут также содержать дополнительные четыре цифры в формате 16412-0312. Данный тип кодов получил название Zip+4. Четыре дополнительные цифры уточняют локальную зону доставки и не требуются для определения города. При создании протокола были приняты следующие решения: Все команды текстовые Транспорт TCP Порты: 6000. Порт 6000 это наиболее часто используемый номер в тестовых примерах Indy. Это не имеет значения. Протокол поддерживает следующие команды Help – получение справки Lookup <почтовый код 1> <почтовый код 2> ... – запрос информации 53 Quit – отсоединение от сервера При разработке протокола, полезно знать ключевые протоколы, такие как - NNTP, SMTP и HTTP и использовать их как модель. Исключая POP3 и IMAP4. Поскольку это плохой пример построения протоколов. Поскольку NNTP поддерживает передачу и прием сообщений в рамках одно протокола, Протокол NNTP будет упоминаться в данной книге несколько раз. 10.8.1. Команда Help Команда Help очень часто используемая команда и редко применяемая в автоматических клиентах. Данная команда наиболее пригодна для использования человеком, который или тестирует, или напрямую работает с сервером. Почти все серверы реализуют данную команду. Команда Help полезна для вывода справки о командах сервера и их возможном применении. Вот пример ответа Борландовского сервера новостей сервера, на команду HELP: help 100 Legal commands authinfo user Name|pass Password article [MessageID|Number] body [MessageID|Number] check MessageID date group newsgroup head [MessageID|Number] help ihave last list [active|active.times|newsgroups|subscriptions] listgroup newsgroup mode stream mode reader newgroups yymmdd hhmmss [GMT] [ newnews newsgroups yymmdd hhmmss [GMT] [ next post slave stat [MessageID|Number] takethis MessageID xgtitle [group_pattern] xhdr header [range|MessageID] xover [range] xpat header range|MessageID pat [morepat...] . Для нашего протокола, сервер отвечает кодом 100, плюс сопроводительный текст. 54 10.8.2. Команда Lookup Команда lookup принимает один или несколько почтовых кодов для поиска и возвращает название города и штат. Данные возвращаются в формате RFC откликов. Если код не найден, то отклик не возвращается (но если судить по примеру это не так, возвращает пустой отклик – строка с точкой). Код ответа "200 Ok". Пример: lookup 37642 16412 200 Ok 37642: CHURCH HILL, TN 16412: EDINBORO, PA . Даже если код не найден, то возвращается ответ "200 Ok". lookup 99999 200 Ok . Мы приняли такое решение. Если бы сервер мог воспринимать только один параметр, то можно бы было отвечать кодом 200, и если не найден, то кодом 4XX. Но протокол может возвращать часть для правильных данных, поэтому было решено всегда возвращать код 200. При частично правильных данных и ответ: lookup 37642 99999 200 Ok 37642: CHURCH HILL, TN . Если бы протокол возвращал код ошибки, то частичные данные были бы проигнорированы. Данное решение позволило серверу отвечать и на частично правильные запросы, без генерации ошибки. 10.8.3. Команда Quit Команда quit является прямым приказом серверу прекратить сессию и отсоединиться. Посмотрим снова на сервер новостей Борланда. Его ответ следующий: quit 205 closing connection - goodbye! The postal code protocol responds similarly: quit 201-Paka! (Russians are everywhere) 201 2 requests processed. 55 Почтовый протокол выдает многострочные ответы. Это не определено самим протоколом. Любые RFC ответы могут быть как однострочными, так и многострочными. Indy обрабатывает оба типа ответов автоматически. 11. Прокси Один из частых вопросов "Как я могу использовать Indy с прокси?". Когда задают этот вопрос, то ответить непросто. Не всегда возможно ответить, поскольку существует множество, самых различных прокси. Некоторые протоколы, также имеют свои собственные методы общения с прокси. Рассмотрим наиболее распространенные виды прокси. Прокси и файрволы выполняют похожие задачи, но имеют разные цели. Поскольку у них похожие задачи, они могут использоваться для выполнения функций друг друга и могут быть объединены в комбинацию прокси-файрвол. Прокси могут быть разделены на две категории: Прозрачные Непрозрачные 11.1. Прозрачные прокси Прозрачные прокси – это прокси, которые не требуют вмешательства в протокол обмена. О наличии прозрачного прокси часто не догадываются разработчики или пользователи (на то они и прозрачные и их нельзя обойти). Хотя прозрачные прокси не оказывают влияния на клиента, они оказывают влияние на сервера. В большинстве случаев, серверы позади таких прокси скрыты от остального мира. Это позволяет иметь доступ к серверу с другой стороны прокси через его порты и эти порты туннелируются снаружи внутрь. 11.1.1. Туннелирование IP / Трансляция сетевого адреса (NAT) IP маскирование ли трансляция сетевого адреса (NAT) в прокси позволяет всем исходящис соединеним быть прозрачными и не оказывать влияния на клиентов. Клиенты продолжают работать как обычно и не требуется их конфигурирование. Microsoft Internet Connection Sharing работает по данному методу. 11.1.2. Маппирование портов / Туннели Маппированый порт или туннелированный прокси работает путем создания туннелей через блокированный маршрут. Маршрут может быть заблокирован в сетевой конфигурации, или может быть мостом между двумя сетями, или может быть умышленно защищен файрволом внутренней сети. Внутренняя сеть определятся как одна сторона сети в локальной сети и другой сети или внешней сети, к которой подключена внутренняя сеть. (Бр – фраза, не подлежащая к переводу, очень трудная к пониманию, принимайте как получилось. Если сказать своими словами – это часть сети отделенная от других сетей, как локальных, так и глобальных Почему бы так и не сказать?) 56 Поскольку маршрут блокирован, весь доступ возможен только через туннелирование порта. Порты назначаются на локальном сервере, который доступен извне. Этот сервер затем пересылает данные из и во внутреннею сеть. Недостатком маппированых портов является то, что маппированый порт маппируется на фиксированный удаленный узел и порт. Для таких протоколов, как почтовые и сервера новостей они определены заранее и работают нормально. Но для протоколов подобных HTTP данный способ не работает, поскольку удаленное место неизвестно до общения (речь про доступ изнутри). Маппированные порты могут быть использованы также для маппирования портов снаружи во внутреннею сеть. Маппированые порты часто используются совместно с NAT прокси, для представления серверов во внешней сети. 11.1.3. FTP User@Site прокси Для реализации FTP прокси имеются несколько методов. Основной тип FTP прокси называется User@site. При использования метода User@Site, все FTP сессии подсоединяются к локальному прокси серверу. Прокси притворяется что он FTP сервер. Прокси сервер перехватывает и интерпретирует FTP запросы. Когда прокси запрашивает имя пользователя, то имя пользователя и нужный FTP посылаются в виде username@ftpsite. Прокси соединяется нужным FTP и перехватывает команды передачи. Для каждой команды передачи, прокси динамически маппирует локальный порт для передачи данных и модифицирует информацию передачи, возвращаемую клиенту. FTP клиент контактирует с прокси вместо доступа к реальному FTP серверу. Из-за трансляции, FTP клиент не знает, что прокси является ненастоящим сервером. Например, пусть дан FTP сайт - ftp.atozedsoftware.com и имя пользователя joe, а его пароль smith, то нормальная сессия выглядит так: Host: ftp.atozedsoftware.com User: joe Password: smith Если User@Site прокси существует и его имя corpproxy, то FTP сессия выглядит так: Host: corpproxy User: joe@ftp.atozedsoftware.com Password: smith 11.2. Непрозрачные прокси Непрозрачные прокси требуют вмешательства в используемые протоколы. Многие протоколы имеют встроенную поддержку для непрозрачных прокси. 11.2.1. SOCKS прокси SOCKS – это прокси, которые не требуют изменений в протоколе высокого уровня, но работают на уровне TCP. Для протоколов, которые используют SOCKS прокси, программная часть должна быть реализована на уровне TCP. 57 Если программное обеспечение не поддерживает явно SOCKS прокси, то оно не может быть использовано для работы с SOCKS файрволом. Большинство популярного обеспечения, такое как – браузеры и ICQ поддерживают SOCKS, но прочее программное обеспечение как правило нет. Поэтому, SOCKS часто должен развертываться с внутренними серверами, маппироваными портами, другими прокси или их комбинациями. Для программного обеспечения, которое поддерживает SOCKS, вместо соединения с сервером назначения, сначала происходит соединение с SOCKS прокси. При этом передается запись с данными, содержащими сервер назначения и дополнительно данные аутентификации. SOCKS сервер затем динамически строит туннель к серверу. Поскольку SOCKS протокол работает динамически на основе переданных данных, он очень настраиваемый и гибкий. 11.2.2. HTTP (CERN) прокси HTTP прокси, иногда называемый CERN прокси, это специализированный прокси, который обслуживает только трафик браузеров. В дополнение HTTP, также может обслуживать и FTP трафик, если FTP делается поверх HTTP. HTTP прокси могут также кэшировать данные и часто используется только по этой причине. Многие корпоративные сети часто закрывают свои внутренние сети файрволом и разрешают выход наружу только через HTTP и почту. Почта предоставляется с помощью внутреннего почтового сервера, а HTTP предоставляется с помощью HTTP прокси. Данный тип HTTP является дружественным файрволу, поэтому многие новые протоколы используют HTTP как транспорт. SOAP и другие web службы являются замечательным примером. 12. Обработчики ввода/вывода (IOHandlers) Создано: 04.04.2009 17:42:47 · Исправлено: 24.05.2010 23:27:36 · Прочтений: 249944 Indy может настраиваться и расширяться многими путями, без необходимости напрямую модифицировать исходный код. Примером такой расширяемости являются обработчики ввода/вывода (IOHandlers). Обработчики ввода/вывода позволяют вам использовать любой источник ввода/вывода I/O в Indy. Обработчики ввода/вывода должны использоваться, когда вы желаете использовать альтернативный механизм ввода/вывода или создание нового транспортного механизма. Обработчики ввода/вывода выполняют весь ввод/вывод (Input/Output) для Indy. Indy не выполняет ни какого своего ввода/вывода, за пределами обработчика ввода/вывода. Обработчик ввода/вывода используется для посылки сырых TCP данных для компонент Indy. Обработчики ввода/вывода позволяют классам обрабатывать весь ввод/вывод в Indy. Обычно, весь ввод/вывод делается через сокет и обслуживается обработчиком по умолчанию - TIdIOHandlerSocket. Каждый TCP клиент имеет свойство IOHandler, которое может быть назначено обработчику IOHandler, как это делает каждое серверное соединение. Если обработчик IOHandler не указан, то неявно используется TIdIOHandlerSocket, который создается автоматически и используется TCP клиентом. TIdIOHandlerSocket реализует ввод/вывод 58 используя TCP сокет. Indy также включает дополнительные обработчики ввода/вывода: TIdIOHandlerStream и TIdSSLIOHandlerSocket. Другие обработчики ввода/вывода могут быть созданы, позволяя Indy использовать любые источники ввода/вывода, которые вы только можете вообразить. В данный момент Indy поддерживает только сокеты, потоки и SSL как источники ввода/вывода, но источники ввода/вывода позволяют и другие возможности. Пока нет других планов, но обработчики ввода/вывода могут быть созданы для поддержки туннелей, IPX/SPX, RS- 232, USB или Firewire. Indy не ограничивает вас в выборе вашего источника ввода/вывода и использование обработчиков ввода/вывода позволяет это сделать. |