Компоненты Indy, применяемые в Delphi 6.
Помимо базовых служб и протоколов Интернет существует широкий набор дополнительных сервисов, возможности которых часто используются Интернет-разработчиками. К тому же далеко не всегда возможность отображения информации с помощью браузера является приемлемым решением для Интернет-приложений. В этом случае разумно использовать Интернет-инфраструктуру для обмена данными, а отображение информации обеспечить за счет более сложных клиентских приложений, разработанных, предположим, на Delphi.
Допустим, требуется реализовать специализированную серверную логику, которая не заложена в стандартные Web-серверы. Для решения такого класса задач в состав Delphi включена библиотека Internet Direct (Indy) компании Nevrona Designs (http://www.nevrona.com/Indy/). Данная библиотека, разработанная специально для Borland Delphi, насчитывает уже восемь версий, последняя из которых вошла в состав новой версии Delphi. Набор компонентов разделен на три группы: клиентские (Indy Client), серверные (Indy Servers) и вспомогательные (Indy Misc).
Indy Clients и Indy Servers
Большинство компонентов Indy Client и Indy Servers представляют собой пары,
соответствующие клиентским и серверным частям протоколов и служб (за исключением
отдельных, в основном серверных, компонентов типа TunnelMaster и TunnelSlave), и
позволяют использовать такие протоколы, как TCP/IP, UDP, NNTP, SMTP, FTP, HTTP,
а также службы ECHO, FINGER, WHOIS и т.д.
Клиентские компоненты Indy написаны с использованием сокетов. Сокет со
стороны клиента требует соединения с сервером. Если связь установлена, клиент и
сервер могут начинать обмен сообщениями. Эти сообщения носят различный характер,
но обычно обмен происходит по определенному протоколу (например, НТТР)
TIdTCPClient и TIdTCPServer
Эти компоненты используются для поддержки одного из основных сетевых протоколов - ТСР (Transmission Control Protocol), а также являются базовыми классами для компонентов TIdSMTP и TIdFTP. Класс TIdTCPServer обладает свойством ThreadMgr, по умолчанию равным nil. Если ThreadMgr равно nil, когда TIdTCPServer активизирован, класс TIdThreadMgrDeafault будет создан неявно. В противном случае используется установленный менеджер процессов.
TIdUDPClient и TIdUDPServer
Эти компоненты используются для поддержки сетевого протокола UDP (User Datagram Protocol), а также являются базовыми классами для ряда других компонентов Indy.
TIdChargenServer
Компонент используется для генерации случайных символов, обычно в испытательных целях.
TIdDayTime и TIdDayTimeServer
Компоненты используются для обеспечения службы времени. Клиент запрашивает, а сервер сообщает текущие дату и время.
TIdDNSResolver
Это клиентский компонент, обслуживающий запросы от сервера DNS (Domain Name Service). Запросы DNS-сервера предназначены для замены имени компьютера на его IP-адрес. TIdDNSResolver является наследником класса TIdUDPClient.
TIdDICTServer
Серверный компонент, поддерживающий протокол Dictionary Server Protocol (DICT) - серверный словарь на базе TCP-протокола, который позволяет клиенту получать доступ к словарю естественного языка.
TIdDISCARDServer
Серверный компонент, поддерживающий сервер записей. Записи могут быть использованы как инструмент отладки и проведения измерений. Служба записей просто передает любые данные тому, кто их готов принимать.
TI dEcho и TI dECHOServer
Компоненты предназначены для обеспечения службы отклика, используемой, как правило, для проверки работоспособности сети. Клиент посылает текстовое сообщение серверу, сервер возвращает сообщение клиенту. Если сообщение искажено, сеть работает с ошибками.
TIdFinger и TIdFingerServer
Компоненты предназначены для обеспечения протокола, дающего пользователю возможность запрашивать данные относительно присутствия в системе других пользователей. Некоторые серверы обрабатывают такие клиентские запросы. Использование этой пары компонентов позволит выполнить обслуживание клиентских запросов, выясняющих наличие в системе других пользователей.
Компонент включает полную поддержку протокола передачи файлов - FTP (File Transfer Protocol). Поддерживается пассивная и активная передача данных, а также такие операции, как GET и PUT, удаление директорий, получение квот, размеров файлов и каталогов. В своей работе TI dFTP использует класс TIdSimpleServer. Когда выполняется передача файла по протоколу FTP, вторичное соединение по протоколу TCP открыто для передачи данных и закрывается, когда данные были переданы. Такое соединение называется "канал передачи данных", уникальный для каждого передаваемого файла.
TIdGopher и TIdGopherServer
Эти компоненты предназначены для обеспечения сетевого протокола, вытесненного в последнее время из WWW (World Wide Web) протоколом HTTP. Сервер, реализующий этот протокол, обеспечивает иерархическую распределенную систему поддержки документооборота. Пример использования этой пары компонентов, находящийся в директории demosindyGopherClient и demosindy GopherServer, демонстрирует, как при помощи этого протокола можно предоставлять в локальной сети информацию о файлах, находящихся на вашем компьютере, в том числе и о закрытых.
TIdHostNameServer
Серверный компонент, предназначенный для передачи клиентам локального имени сервера.
TIdHTTP и TIdHTTPServer
Компоненты используются для обеспечения сетевого протокола HTTP (поддерживаются версии 1.0 и 1.1, включая операции GET, POST и HEAD). Кроме того, обеспечивается поддержка аутентификации и применения proxy-серверов. Серверный компонент используется для предоставления услуг другому Web-серверу, поддерживающему данный протокол. TIdHTTPServer облегчает реализацию таких функций, как cookies, управление состояниями и др.
TIdIcmpClient
Клиентский компонент, предназначенный для обеспечения протокола ICMP (Internet Control Message Protocol), с помощью которого осуществляется выполнение операции ping и трассировка сети.
Клиентский компонент, предназначенный для обеспечения протокола POP (Post Office Protocol), включая поддержку MIME-кодирования и декодирования, а также передачу многобайтных символов.
TIdIMAP4Server
Серверный компонент, предназначенный для поддержки операций по протоколу IMAP (Internet Message Access Protocol) на сервере. Протокол позволяет производить поиск сообщений электронной почты на сервере. Различие протоколов IMAP и РОР заключается в том, что протоколу РОР требуется дополнительная память для хранения данных, а протокол IMAP обращается к серверу вместо клиентской машины. IMAP4 создавался для замены POP3, однако до сих пор протокол POP3 остается широко используемым стандартом.
TIdIRCServer
Серверный компонент, предназначенный для поддержки наиболее часто используемых в Интернете сервисных операций, обычно называемых chat (для дружеских бесед). Компонент обеспечивает базовые конструктивные блоки для IRC (Internet Relay Chat) сервера.
TIdMappedPortTCP
Серверный компонент, предназначенный для создания отображаемых портов, которые часто используются в proxy-серверах. Методы этого компонента позволяют отобразить один порт на другой. Например, порт 80 может быть отображен к порту 3000, и все запросы к первому порту (порт 80) будут переадресованы на второй порт (порт 3000).
TIdNNTP и TIdNNTPServer
Эти компоненты необходимы для обеспечения сетевого протокола NNTP (Network News Transfer Protocol), используемого в службах новостей. Клиентский компонент включает поддержку MIME-кодирования и декодирования, а также поддержку многобайтных символов и альтернативных кодировок. Серверный компонент позволяет создавать серверы новостей. Важно отметить, что TIdNNTPServer является не полнофункциональным сервером новостей, а компонентом, обеспечивающим базовые возможности для такого сервера.
TIdQOTD и TIdQOTDServer
Компоненты используются для обеспечения службы "цитат дня" (Quote of the Day). С помощью клиентского компонента осуществляется соединение с экземпляром серверного компонента для получения ежедневной цитаты. Каждый экземпляр сервера содержит уникальную базу данных цитат.
Клиентский компонент, предназначенный для применения в приложениях протокола SMTP (Simple Mail Transfer Protocol), обеспечения поддержки аутентификации, MIME-кодирования и декодирования, а также для поддержки многобайтных символов.
Клиентский компонент, предназначенный для обеспечения протокола SNTP (Simple Network Time Protocol) - службы времени. Может использоваться для соединения с любой службой времени с целью определения текущих даты и времени.
TIdSimpleServer
Серверный компонент, обеспечивающий облегченный ТСР-сервер. Позволяет организовывать соединение "точка-точка". Используется для создания серверов с единственным пользователем, то есть может единовременно обслуживать только одно подключение. В отличие от компонента TIdTCPServer не порождает вторичные процессы при ожидании запросов от клиентов и при обработке этих запросов. Другими словами, если сервер обслуживает запрос от какого-то клиента, а в это время к нему обращается для подключения другой клиент, то он будет блокирован до конца обработки первого запроса.
TIdTelnet и TIdTelnetServer
Клиентский компонент используется для организации удаленных сеансов на другом компьютере, включая консольные переговоры и аутентификацию. Протокол связи предполагает наличие человека, осуществляющего интерактивное взаимодействие с сервером. Клиентский компонент не обладает поддержкой дисплея и эмуляцией терминала, а просто обеспечивает соединение с серверной частью. Обычно серверный протокол TIdTelnetServer используется для организации удаленных баз данных с текстовым интерфейсом для интерактивного взаимодействия с клиентами.
TIdTime и TIdTimeServer
Клиентский компонент является альтернативой компонента TIdSNTP для определения времени. Важно отметить, что форматы этих двух протоколов различны. TIdTime основан на формате RFC 868 (возвращает время во внутреннем стандарте ОС UNIX, выполняя все необходимые преобразования). Серверный компонент подобен по функционированию DayTime-серверу. Может использоваться для реализации службы времени на локальном компьютере. Дополнительного кода не требуется, достаточно создать экземпляр TIdTimeServer, который будет возвращать время внутренних часов серверного компьютера.
TIdTrivialFTP и TIdTrivialFTPServer
Эти компоненты необходимы для организации простейшего протокола передачи файлов. Клиентский компонент этого протокола используется для соединения с экземпляром соответствующего серверного компонента. Протокол предназначен для частных, облегченных, локальных случаев передачи файлов, например в локальных вычислительных сетях или для загрузки (выгрузки) таблиц маршрутизации в маршрутизаторы. Ввиду ослабленных характеристик этого протокола его использование не рекомендуется в случае применения алгоритмов аутентификации или любых других механизмов защиты. Основное назначение данного протокола - передача файлов аппаратному устройству с целью его модификации.
TIdTunnelMaster и TIdTunnelSlave
Серверные туннельные компоненты используются в proxy-серверах для организации множественных логических соединений поверх одного физического (туннеля). Эти классы можно применять для различных целей, например для организации секретного соединения по несекретным каналам.
TIdWhois и TIdWhoIsServer
Этот клиентский компонент осуществляет соединение с любым стандартным Whois-сервером, позволяющим получить информацию о доменах. Серверный компонент обеспечивает базовую функциональность NIC сервера.
Indy Misc
Страница палитры компонентов Indy Misc (Indy Miscellaneous Components)
включает кодеки BASE64, UUE, Quoted Printable и другие распространенные форматы
обмена данными через e-mail, кодеры (MD2, MD4 и MD5) для стандартов
криптографии, используемые для хранения паролей и электронных подписей в
необратимом (трудно поддающемся дешифрованию) виде, а также многие другие
полезные компоненты и утилиты, часто применяемые при разработке
Интернет-приложений.
TIdAntiFreeze
Вследствие блочной организации алгоритмов компонентов Indy зачастую создается впечатление, что приложение "зависло", в то время как соединение работает. Чтобы исключить использование вторичных процессов (threads) при организации коммуникаций для предотвращения замораживания (freeze) приложения, достаточно поместить на форму указанный компонент.
Компонент работает, анализируя запросы из стека протокола TCP/IP и посылая сообщения приложению во время задержки при возникновении блокировки внешних соединений, что создает иллюзию работающего кода. Поскольку воздействие компонента осуществляется на блокированные соединения только для главного процесса, использование TIdAntiFreeze во вторичных процессах приложения не требуется. Необходимо помнить, что компонент TIdAntiFreeze замедляет работу соединений, поскольку работа главного процесса периодически прерывается для обработки сообщений. Отсюда следует, что надо заботиться о том, чтобы разрабатываемое приложение не тратило слишком много времени на обработку сообщений, включая OnClick, OnPaint, OnResize и др. В какой-то степени этим можно управлять через свойства класса TIdAntiFreeze. Использование данного компонента не является обязательным, но позволяет решить проблему синхронизации соединений с визуальным интерфейсом приложения.
TIdDateTimeStamp
Класс для выполнения математических действий с датой и временем, связанных с тем, что Интернет-протоколы используют различные форматы даты и времени; кроме того, клиенты и серверы могут находиться в различных часовых поясах.
TIdIPWatch
Это компонент, основанный на таймере, который постоянно контролирует изменения в IP-адресе компьютера. События компонента возникают, когда выявлено изменение. Указанный компонент обычно используют для обнаружения факта появления связи компьютера с Интернетом или любой другой сетью. Изменение в IP-адресе в этой ситуации может произойти из-за назначения IP-адреса DHCP-сервером (Dynamic Host Configuration Protocol) при соединении с новой сетью.
TIdLogDebug
Назначение данного компонента - перехватывать события любого клиентского или серверного компонента и помещать запись о событии в указанный файл. Этот компонент очень полезен для отладки компонентов Indy.
TIdMessage
Компонент используется в комбинации с другими компонентами, чтобы должным образом расшифровать или кодировать сообщения. Это могут быть POP-, SMTP- и NNTP-компоненты. Класс поддерживает MIME-шифрование и расшифровку, многобайтные символы и кодировку ISO.
TIdNetworkCalculator
Один из немногих компонентов Indy, который можно использовать при конструировании приложений. Сетевой калькулятор может служить для вычислений, производимых над IP-адресами, включая сетевые маски, подсеть, классы сети и т.д.
TIdThreadMgrDefault
Компонент обеспечивает управление вторичными процессами по умолчанию. Создается в случае, если для какого-либо компонента Indy, поддерживающего управление процессами, не определен экземпляр класса TIdThreadManager. Компонент обеспечивает только основные возможности управления вторичными процессами: создает и уничтожает их по требованию.
TIdThreadMgrPool
Более продвинутый компонент управления процессами, чем TIdThreadMgrDefault, потому что он объединяет процессы, а не создает или уничтожает их по требованию.
TIdVCard
VСard - электронный эквивалент визитной карточки, может содержать персональную информацию владельца, графические данные.
TIdIMFDecoder
Предназначен для декодирования Интернет-сообщений. Является наследником класса TIdCoder, так же как и все остальные компоненты-кодировщики. Класс TIdCoder осуществляет декодирование в соответствии со стандартом формата текстовых Интернет-сообщений ARPA RFS-822, предложенным в августе 1982 года, и стандартом для обмена USENET-сообщениями RFC 1036, предложенным в декабре 1987 года.
Компонент расширяет возможности класса TIdCoder, позволяя обнаруживать формат RFS-822 по контексту заголовков, обеспечивая режим расшифровки при приеме и MIME-шифрование и расшифровку. Компонент TIdIMFDecoder используется в классе TIdMessageClient для декодирования получаемых и передаваемых сообщений.
TIdQuotedPrintableEncoder
QuotedPrintableEncoder позволяет производить расшифровку текста в указанном формате. Может служить в качестве автономного компонента с указанным типом кодировки, что позволяет передавать сообщения, содержащие кодировку нового типа.
TIdBase64Encoder
Реализует еще один алгоритм шифрования, который дает возможность передавать непечатаемые символы.
TIdUUEncoder
Реализует один из первых шифроалгоритмов, UU-кодирование. Иногда используется при почтовых пересылках статей в службе новостей.
TIdXXEncoder
Этот метод шифрования едва ли когда-либо будет использоваться. По сути, это то же самое UU-кодирование, но с другой таблицей шифрования.
TIdCoderMD2
Компоненты с различными разновидностями алгоритма шифрования MD (Message Digest). Все они основаны на перемешивании, являются односторонними и не имеют алгоритмов расшифровывания.
Компоненты протокольных клиентов и серверов могут быть использованы для разработки серверных и клиентских Интернет-приложений, совместно или взамен базовых (ClientSocket, ServerSocket) и других компонентов из состава палитры Internet и Fastnet. Компоненты Indy не используют архитектуру WebBroker, реализуя поддержку Интернет-протоколов и служб на нижнем уровне непосредственно в своем исходном коде (исходные коды прилагаются).
TIdConnectionInterceptOpenSSL и TIdServerInterceptOpenSSL
Протокол SSL - Secure Sockets Layer (Секретный Уровень Сокетов), обеспечивающий секретность и надежность связи между двумя приложениями, имеет два уровня. На низком уровне многоуровневого транспортного протокола (например, TCP) SSL является протоколом записи и используется для инкапсуляции различных протоколов более высокого уровня. Преимущество SSL состоит в том, что он является независимым протоколом прикладной программы, при этом протокол более высокого уровня может быть использован поверх SSL.
SSL осуществляет защиту связи, которая имеет три основные функции: обеспечение конфиденциального соединения; шифрование с открытым ключом (используется для подтверждения подлинности адресата); поддержка надежности передачи данных.
В сочетании с протоколом HTTP и аутентификацией сервера протокол SSL обеспечивает необходимые функции шифрования и в дальнейшем поддерживает установленное соединение, перепроверяя подлинность Web-сервера и т.п. Важно понять, что SSL только защищает связь в процессе передачи данных, а не заменяет другие защитные механизмы.
Компоненты TIdConnectionInterceptOpenSSL и TIdServerInterceptOpenSSL обеспечивают соединение как со стороны клиента, так и со стороны сервера в соответствии с протоколом SSL. Необходимо отметить, что компоненты TIdConnectionInterceptOpenSSL и TIdServerInterceptOpenSSL есть только в Delphi 6, а в Kylix отсутствуют. Это связано со сложностью протокола, который в случае реализации Windows основан на функциях операционной системы.
Примеры использования компонентов Indy можно найти в каталогах /Delphi6/Demos/Indy. Всего библиотека Indy в версии 8.0 содержит 69 компонентов. Заявлено, что в версии 9.0 указанная библиотека будет содержать 86 компонентов. Все компоненты унифицированы и включены как в Delphi 6, так и в Kylix, что позволяет использовать их для разработки кросс-платформенных приложений. Все компоненты Indy поддерживают многопоточность.
В компонентах Indy реализована почти вся функциональность, имеющаяся в компонентах Internet и Fastnet, что наглядно показано в таблице.
Компоненты Fastn et | Компоненты Indy | Назначение компонентов | |
---|---|---|---|
1 | TserverSocket, TClientSocket | TIdTCPserverSocket, TIdTCPClientSocket | Взаимодействие двух компьютеров (клиента и сервера) с помощью протокола TCP/IP |
2 | TNMDayTime | TIdDayTime, TIdDayTimeServer | Запрос сервера о текущем времени |
3 | TNMEcho | TIdEcho, TIdEchoServer | Используются для связи с сервером отклика |
4 | TNMFinger | TIdFinger, TIdFingerServer | Используются для получения информации о пользователе с поискового Интернет-сервера |
5 | TNMFTP | TIdFTP, TIdTrivialFTP, TIdTrivialFTPServer | Обеспечивают передачу файлов с помощью протокола FTP |
6 | TNMHTTP | TIdHTTP, TIdHTTPServer | Используют протокол HTTP для обмена данными |
7 | TNMMsgServ, TNMMsg | Используются для передачи простых текстовых сообщений от клиента к серверу | |
8 | TNMNNTP | TIdNNTP, TIdNNTPServer | Поддерживают обмен данными с сервером новостей |
9 | TNMPOP3 | TIdPOP3 | Используются для получения электронной почты с почтового сервера с помощью протокола POP3 |
10 | TNMSMTP | TIdSMTP | Используются для отправки электронной почты через почтовый сервер Интернет |
11 | TNMStrm, TNMStrmServ | Передают двоичные данные, записанные в поток, с помощью протокола TCP/IP | |
12 | TNMUDP | TIdUDP, TIdUDPServer | Осуществляют пересылку данных с использованием протокола UDP |
13 | TpowerSock, TNMGeneralServer | Инкапсулированные в виде компонентов классы, которые являются базовыми для написания собственных клиентов (Powersock) и серверов (NMGeneralServer) | |
14 | TNMUUProcessor | TIdUUEncoder, TIdUUDecoder | Осуществляют перекодировку двоичных файлов в формат MIME или UUENCODE |
15 | TNMURL | Перекодирует строки в формат HTML и осуществляет обратную перекодировку |
Исключение составляют такие классы, как TNMMsgServ, TNMMsg, TNMStrm, TNMStrmServ, TpowerSock, TNMGeneralServer, TNMURL, которые либо реализуют морально устаревшие протоколы, либо обладают функциональностью, реализованной в большой группе альтернативных классов.
Однако в отличие от своих предшественников - компонентов Internet и Fastnet, в Indy богаче представлены серверные компоненты и компоненты перекодирования и шифрования данных, а также поддержка аутентификации (палитра Indy Misc). Как видно из приведенной выше таблицы, основные протоколы и службы обеспечиваются не только клиентскими, но и серверными компонентами. Это службы времени, отклика, получения информации о пользователе, а также протоколы HTTP, NNTP, UDP и даже простейший вариант FTP.
Некоторые примеры применения компонентов Indy
В компонентах Indy, которые содержатся в Delphi, IP-адрес определяется в свойстве Host, как правило, только в клиентских приложениях. Компоненты, размещаемые на сервере, имеют методы, позволяющие начать или прекратить опрос соответствующего порта, - например изменение свойства Active компонента IdTCPServer начинает или прекращает опрос соответствующего порта. После установки связи между клиентом и сервером можно начинать передачу данных.
В компонентах Indy большое внимание уделяется безопасности и надежности при работе с данными. Например, в компоненте IdTCPClient есть методы Connect и Disconnect. Применяя технику программирования, как в приведенном ниже коде со стороны клиента:
With TCPClient do begin Connect; try lstMain.Items.Add(ReadLn); finally Disconnect; end; end;
и используя свойство Connection, передаваемое в качестве параметра экземпляра AThread класса TIdPeerThread, со стороны сервера:
With AThread.Connection do begin WriteLn("Hello from Basic Indy Server server."); Disconnect; end;
можно рассчитывать либо на штатное выполнение соединения, либо на правильную обработку ошибки.
Обратите внимание на методы ReadLn и WriteLn соответствующих классов - они напоминают стандартные операторы ввода-вывода Pascal. Это дань технике программирования в UNIX, где большинство системных операций выполняются благодаря чтению и записи в соответствующие файлы.
Так же как у компонентов Fastnet, у классов компонентов Indy имеются события, при помощи которых можно организовывать событийное управление. Например, можно организовать вывод сообщения на форму при соединении с клиентом:
Procedure TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); begin lblStatus.caption:= "[ Serving client ]"; end;
В Indy представлены компоненты, реализующие протоколы с клиентскими и серверными частями, присущие только этой библиотеке. Компоненты TIdGopherServer и TIdGopher, благодаря методам GetExtendedMenu, GetFile, GetMenu, GetTextFile на клиентской стороне и ReturnGopherItem, SendDirectoryEntry - на стороне сервера, помогают осуществить просмотр файлов различного типа, в том числе помеченных как скрытые, а также директорий на удаленном компьютере (подобно тому, как это делает команда dir *.* в операционной системе MS-DOS).
При помощи компонентов IdSMTP и IdMessage можно легко создать свое
Web-приложение, способное отправлять почту по протоколу SMTP.
При этом класс IdMessage (один из 23 компонентов со страницы Indy Misc) отвечает за формирование сообщения, что вытекает из его названия, а IdSMTP - за организацию соединения с почтовым сервером.
Технология, применяемая в Indy, использует операции чтения и записи с блокировкой. Любая операция Connect, используемая в Indy, ожидает завершения соединения. При работе с клиентскими компонентами Indy, как правило, требуется выполнение следующих операций:
Компоненты Indy разрабатывались так, чтобы обеспечить сверхвысокий уровень абстракции. Запутанность и подробности стека TCP/IP скрыты от программиста, с тем чтобы он мог сосредоточиться на текущих задачах.
Следующий небольшой пример показывает типичную сессию клиентского компонента:
With IndyClient do begin Host:= "zip.pbe.com"; // Host to call Port:= 6000; // Port to call the server on Connect; try // Your code goes here finally Disconnect; end; end;
В примере, даже если соединение с сервером не будет установлено, связь корректно разорвется благодаря использованию оператора try-finally.
Серверные компоненты Indy описывают разнообразные модели серверов, которые можно использовать в зависимости от потребностей и применяемого протокола.
TIdTCPServer - наиболее часто используемый серверный компонент, который создает вторичный процесс, независимый от основного процесса приложения. Созданный процесс ожидает входящие запросы от потенциальных клиентов. Для каждого клиента, на запрос которого он отвечает, создается индивидуальный вторичный процесс. События, возникающие в процессе обслуживания, соотносятся с контекстом соответствующих процессов.
Иными словами, для каждого клиентского подключения класс TIdTCPServer использует уникальный вторичный поток, вызывая обработчик события OnExecute этого потока. Формальным параметром метода OnExecute является ссылка на экземпляр класса Athread, соответствующего созданному потоку. Свойство Connection этого класса - ссылка на класс TIdTCPConnection, экземпляр которого создается для обработки клиентского запроса. TIdTCPConnection поддерживает чтение и запись через соединение, а также установление и завершение сеанса связи.
Протокол UDP работает без предварительной установки соединения с сервером (каждый посланный пакет является самостоятельным набором данных, а не частью большой сессии или соединения). В то время как TIdTCPServer порождает отдельные потоки для каждого соединения, TIdUDPServer использует или главный поток, или единственный вторичный поток, который обрабатывает все запросы протокола UDP. Когда TIdUDPServer активен, создается поток для прослушивания входящих UDP-пакетов. Для каждого полученного пакета возникает событие OnUDPRead или в основном потоке, или в контексте прослушивающего потока - в зависимости от значения свойства ThreadedEvent. Когда ThreadedEvent принимает значение False, событие возникает в основном потоке, в противном случае - в прослушивающем потоке. Пока происходит обработка события, другие операции сервера блокируются. Поэтому важно следить, чтобы процедуры OnUDPRead выполнялись как можно быстрее.
Если нужно создать клиентское приложение нового клиента для существующего сервера с использованием существующего протокола, ваша задача состоит исключительно в разработке и отладке клиентского приложения. Однако, когда приходится разрабатывать и клиентское, и серверное приложения с применением существующего или нового протокола, мы сталкиваемся с классической проблемой "яйца и курицы". С чего начинать программирование - с клиента или с сервера?
Очевидно, в итоге должны быть созданы и клиент, и сервер. Для многих приложений, особенно использующих текстовый протокол (например, HTTP), проще начать создание приложения с проектирования сервера. А для его отладки имеется удобный клиент, который уже существует. Это - консольное приложение Telnet, которое имеется и на Windows, и на UNIX.
Если набрать консольную команду telnet 127.0.0.1 80 с IP-адресом локального
компьютера и номером порта 80, используемым по умолчанию Web-серверами, то
приложение откликнется текстом, представленным на рис. 6, в случае ОС Windows
2000 и IIS 5.0.
Для создания самого простого сервера с использованием компонентов Indy необходимо:
Если необходимо спроектировать сервер, который будет не только корректно информировать своих клиентов о разрыве соединения, но и выдавать для них информацию о возникших ошибочных ситуациях, применяйте оператор try-except вместо try-finally - например, как показано в следующем примере:
Procedure TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: String; begin with AThread.Connection do try try s:= ReadLn; // Perform the task of the server here // if no exception is raised, // write out the server"s response WriteLn(s); except on e: Exception do begin WriteLn(e.Message); end; //on end; //try except finally Disconnect; end; end;
Этот небольшой пример демонстрирует этапы создания простого текстового сервера, а также способы его отладки.
Вышеописанный сервер является типичным примером организации современного распределенного вычисления.
Особенности создания многозвенных приложений
В последнее время для удовлетворения клиентских запросов все чаще используются множественные серверы. Сервер такого типа, получив запрос клиента и частично подготовив его для дальнейшей обработки, связывается с другим сервером и передает ему трансформированный запрос или запросы. Сервер второго звена может, в свою очередь, связываться с другими серверами. Таким образом, можно говорить о многозвенной серверной архитектуре.
Далее мы займемся созданием сервера доступа к данным, назначение которого состоит в том, чтобы возвращать данные из базы данных. Этот сервер, однако, не осуществляет чтения и записи в файлы базы данных непосредственно. Вместо этого он связывается с сервером базы данных в поисках данных, требуемых клиентом.
Итак, мы приступаем к разработке приложения с трехзвенной архитектурой. Для создания сервера базы данных с использованием компонентов Indy необходимо:
Помимо базовых служб и протоколов Интернет существует широкий набор дополнительных сервисов, возможности которых часто используются Интернет-разработчиками. К тому же далеко не всегда возможность отображения информации с помощью браузера является приемлемым решением для Интернет-приложений. В этом случае разумно использовать Интернет-инфраструктуру для обмена данными, а отображение информации обеспечить за счет более сложных клиентских приложений, разработанных, предположим, на Delphi.
Допустим, требуется реализовать специализированную серверную логику, которая не заложена в стандартные Web-серверы. Для решения такого класса задач в состав Delphi включена библиотека Internet Direct (Indy) компании Nevrona Designs (http://www.nevrona.com/Indy/). Данная библиотека, разработанная специально для Borland Delphi, насчитывает уже восемь версий, последняя из которых вошла в состав новой версии Delphi. Набор компонентов разделен на три группы: клиентские (Indy Client), серверные (Indy Servers) и вспомогательные (Indy Misc).
Большинство компонентов Indy Client и Indy Servers представляют собой пары, соответствующие клиентским и серверным частям протоколов и служб (за исключением отдельных, в основном серверных, компонентов типа TunnelMaster и TunnelSlave), и позволяют использовать такие протоколы, как TCP/IP, UDP, NNTP, SMTP, FTP, HTTP, а также службы ECHO, FINGER, WHOIS и т.д. (рис. 1).
Клиентские компоненты Indy написаны с использованием сокетов. Сокет со стороны клиента требует соединения с сервером. Если связь установлена, клиент и сервер могут начинать обмен сообщениями. Эти сообщения носят различный характер, но обычно обмен происходит по определенному протоколу (например, НТТР) (рис. 2).
Эти компоненты используются для поддержки одного из основных сетевых протоколов - ТСР (Transmission Control Protocol), а также являются базовыми классами для компонентов TIdSMTP и TIdFTP. Класс TIdTCPServer обладает свойством ThreadMgr, по умолчанию равным nil. Если ThreadMgr равно nil, когда TIdTCPServer активизирован, класс TIdThreadMgrDeafault будет создан неявно. В противном случае используется установленный менеджер процессов.
Эти компоненты используются для поддержки сетевого протокола UDP (User Datagram Protocol), а также являются базовыми классами для ряда других компонентов Indy.
Серверный компонент, поддерживающий протокол Dictionary Server Protocol (DICT) - серверный словарь на базе TCP-протокола, который позволяет клиенту получать доступ к словарю естественного языка.
Серверный компонент, поддерживающий сервер записей. Записи могут быть использованы как инструмент отладки и проведения измерений. Служба записей просто передает любые данные тому, кто их готов принимать.
Компоненты предназначены для обеспечения службы отклика, используемой, как правило, для проверки работоспособности сети. Клиент посылает текстовое сообщение серверу, сервер возвращает сообщение клиенту. Если сообщение искажено, сеть работает с ошибками.
Компоненты предназначены для обеспечения протокола, дающего пользователю возможность запрашивать данные относительно присутствия в системе других пользователей. Некоторые серверы обрабатывают такие клиентские запросы. Использование этой пары компонентов позволит выполнить обслуживание клиентских запросов, выясняющих наличие в системе других пользователей.
Компонент включает полную поддержку протокола передачи файлов - FTP (File Transfer Protocol). Поддерживается пассивная и активная передача данных, а также такие операции, как GET и PUT, удаление директорий, получение квот, размеров файлов и каталогов. В своей работе TI dFTP использует класс TIdSimpleServer. Когда выполняется передача файла по протоколу FTP, вторичное соединение по протоколу TCP открыто для передачи данных и закрывается, когда данные были переданы. Такое соединение называется «канал передачи данных», уникальный для каждого передаваемого файла.
Эти компоненты предназначены для обеспечения сетевого протокола, вытесненного в последнее время из WWW (World Wide Web) протоколом HTTP. Сервер, реализующий этот протокол, обеспечивает иерархическую распределенную систему поддержки документооборота. Пример использования этой пары компонентов, находящийся в директории \demos\indy\GopherClient и \demos\indy \GopherServer, демонстрирует, как при помощи этого протокола можно предоставлять в локальной сети информацию о файлах, находящихся на вашем компьютере, в том числе и о закрытых.
Серверный компонент, предназначенный для передачи клиентам локального имени сервера.
Компоненты используются для обеспечения сетевого протокола HTTP (поддерживаются версии 1.0 и 1.1, включая операции GET, POST и HEAD). Кроме того, обеспечивается поддержка аутентификации и применения proxy-серверов. Серверный компонент используется для предоставления услуг другому Web-серверу, поддерживающему данный протокол. TIdHTTPServer облегчает реализацию таких функций, как cookies, управление состояниями и др.
Клиентский компонент, предназначенный для обеспечения протокола ICMP (Internet Control Message Protocol), с помощью которого осуществляется выполнение операции ping и трассировка сети.
Клиентский компонент, предназначенный для обеспечения протокола POP (Post Office Protocol), включая поддержку MIME-кодирования и декодирования, а также передачу многобайтных символов.
Серверный компонент, предназначенный для поддержки операций по протоколу IMAP (Internet Message Access Protocol) на сервере. Протокол позволяет производить поиск сообщений электронной почты на сервере. Различие протоколов IMAP и РОР заключается в том, что протоколу РОР требуется дополнительная память для хранения данных, а протокол IMAP обращается к серверу вместо клиентской машины. IMAP4 создавался для замены POP3, однако до сих пор протокол POP3 остается широко используемым стандартом.
Серверный компонент, предназначенный для поддержки наиболее часто используемых в Интернете сервисных операций, обычно называемых chat (для дружеских бесед). Компонент обеспечивает базовые конструктивные блоки для IRC (Internet Relay Chat) сервера.
Серверный компонент, предназначенный для создания отображаемых портов, которые часто используются в proxy-серверах. Методы этого компонента позволяют отобразить один порт на другой. Например, порт 80 может быть отображен к порту 3000, и все запросы к первому порту (порт 80) будут переадресованы на второй порт (порт 3000).
Эти компоненты необходимы для обеспечения сетевого протокола NNTP (Network News Transfer Protocol), используемого в службах новостей. Клиентский компонент включает поддержку MIME-кодирования и декодирования, а также поддержку многобайтных символов и альтернативных кодировок. Серверный компонент позволяет создавать серверы новостей. Важно отметить, что TIdNNTPServer является не полнофункциональным сервером новостей, а компонентом, обеспечивающим базовые возможности для такого сервера.
Компоненты используются для обеспечения службы «цитат дня» (Quote of the Day). С помощью клиентского компонента осуществляется соединение с экземпляром серверного компонента для получения ежедневной цитаты. Каждый экземпляр сервера содержит уникальную базу данных цитат.
Клиентский компонент, предназначенный для применения в приложениях протокола SMTP (Simple Mail Transfer Protocol), обеспечения поддержки аутентификации, MIME-кодирования и декодирования, а также для поддержки многобайтных символов.
Клиентский компонент, предназначенный для обеспечения протокола SNTP (Simple Network Time Protocol) - службы времени. Может использоваться для соединения с любой службой времени с целью определения текущих даты и времени.
Серверный компонент, обеспечивающий облегченный ТСР-сервер. Позволяет организовывать соединение «точка-точка». Используется для создания серверов с единственным пользователем, то есть может единовременно обслуживать только одно подключение. В отличие от компонента TIdTCPServer не порождает вторичные процессы при ожидании запросов от клиентов и при обработке этих запросов. Другими словами, если сервер обслуживает запрос от какого-то клиента, а в это время к нему обращается для подключения другой клиент, то он будет блокирован до конца обработки первого запроса.
Клиентский компонент используется для организации удаленных сеансов на другом компьютере, включая консольные переговоры и аутентификацию. Протокол связи предполагает наличие человека, осуществляющего интерактивное взаимодействие с сервером. Клиентский компонент не обладает поддержкой дисплея и эмуляцией терминала, а просто обеспечивает соединение с серверной частью. Обычно серверный протокол TIdTelnetServer используется для организации удаленных баз данных с текстовым интерфейсом для интерактивного взаимодействия с клиентами.
Клиентский компонент является альтернативой компонента TIdSNTP для определения времени. Важно отметить, что форматы этих двух протоколов различны. TIdTime основан на формате RFC 868 (возвращает время во внутреннем стандарте ОС UNIX, выполняя все необходимые преобразования). Серверный компонент подобен по функционированию DayTime-серверу. Может использоваться для реализации службы времени на локальном компьютере. Дополнительного кода не требуется, достаточно создать экземпляр TIdTimeServer, который будет возвращать время внутренних часов серверного компьютера.
Эти компоненты необходимы для организации простейшего протокола передачи файлов. Клиентский компонент этого протокола используется для соединения с экземпляром соответствующего серверного компонента. Протокол предназначен для частных, облегченных, локальных случаев передачи файлов, например в локальных вычислительных сетях или для загрузки (выгрузки) таблиц маршрутизации в маршрутизаторы. Ввиду ослабленных характеристик этого протокола его использование не рекомендуется в случае применения алгоритмов аутентификации или любых других механизмов защиты. Основное назначение данного протокола - передача файлов аппаратному устройству с целью его модификации.
Серверные туннельные компоненты используются в proxy-серверах для организации множественных логических соединений поверх одного физического (туннеля). Эти классы можно применять для различных целей, например для организации секретного соединения по несекретным каналам.
Этот клиентский компонент осуществляет соединение с любым стандартным Whois-сервером, позволяющим получить информацию о доменах. Серверный компонент обеспечивает базовую функциональность NIC сервера.
Страница палитры компонентов Indy Misc (Indy Miscellaneous Components) включает кодеки BASE64, UUE, Quoted Printable и другие распространенные форматы обмена данными через e-mail, кодеры (MD2, MD4 и MD5) для стандартов криптографии, используемые для хранения паролей и электронных подписей в необратимом (трудно поддающемся дешифрованию) виде, а также многие другие полезные компоненты и утилиты, часто применяемые при разработке Интернет-приложений (рис. 3).
Вследствие блочной организации алгоритмов компонентов Indy зачастую создается впечатление, что приложение «зависло», в то время как соединение работает. Чтобы исключить использование вторичных процессов (threads) при организации коммуникаций для предотвращения замораживания (freeze) приложения, достаточно поместить на форму указанный компонент.
Компонент работает, анализируя запросы из стека протокола TCP/IP и посылая сообщения приложению во время задержки при возникновении блокировки внешних соединений, что создает иллюзию работающего кода. Поскольку воздействие компонента осуществляется на блокированные соединения только для главного процесса, использование TIdAntiFreeze во вторичных процессах приложения не требуется. Необходимо помнить, что компонент TIdAntiFreeze замедляет работу соединений, поскольку работа главного процесса периодически прерывается для обработки сообщений. Отсюда следует, что надо заботиться о том, чтобы разрабатываемое приложение не тратило слишком много времени на обработку сообщений, включая OnClick, OnPaint, OnResize и др. В какой-то степени этим можно управлять через свойства класса TIdAntiFreeze. Использование данного компонента не является обязательным, но позволяет решить проблему синхронизации соединений с визуальным интерфейсом приложения.
Класс для выполнения математических действий с датой и временем, связанных с тем, что Интернет-протоколы используют различные форматы даты и времени; кроме того, клиенты и серверы могут находиться в различных часовых поясах.
Назначение данного компонента - перехватывать события любого клиентского или серверного компонента и помещать запись о событии в указанный файл. Этот компонент очень полезен для отладки компонентов Indy.
Компонент используется в комбинации с другими компонентами, чтобы должным образом расшифровать или кодировать сообщения. Это могут быть POP-, SMTP- и NNTP-компоненты. Класс поддерживает MIME-шифрование и расшифровку, многобайтные символы и кодировку ISO.
Один из немногих компонентов Indy, который можно использовать при конструировании приложений. Сетевой калькулятор может служить для вычислений, производимых над IP-адресами, включая сетевые маски, подсеть, классы сети и т.д.
Компонент обеспечивает управление вторичными процессами по умолчанию. Создается в случае, если для какого-либо компонента Indy, поддерживающего управление процессами, не определен экземпляр класса TIdThreadManager. Компонент обеспечивает только основные возможности управления вторичными процессами: создает и уничтожает их по требованию.
Более продвинутый компонент управления процессами, чем TIdThreadMgrDefault, потому что он объединяет процессы, а не создает или уничтожает их по требованию.
VСard - электронный эквивалент визитной карточки, может содержать персональную информацию владельца, графические данные.
Предназначен для декодирования Интернет-сообщений. Является наследником класса TIdCoder, так же как и все остальные компоненты-кодировщики. Класс TIdCoder осуществляет декодирование в соответствии со стандартом формата текстовых Интернет-сообщений ARPA RFS-822, предложенным в августе 1982 года, и стандартом для обмена USENET-сообщениями RFC 1036, предложенным в декабре 1987 года.
Компонент расширяет возможности класса TIdCoder, позволяя обнаруживать формат RFS-822 по контексту заголовков, обеспечивая режим расшифровки при приеме и MIME-шифрование и расшифровку. Компонент TIdIMFDecoder используется в классе TIdMessageClient для декодирования получаемых и передаваемых сообщений.
QuotedPrintableEncoder позволяет производить расшифровку текста в указанном формате. Может служить в качестве автономного компонента с указанным типом кодировки, что позволяет передавать сообщения, содержащие кодировку нового типа.
Реализует еще один алгоритм шифрования, который дает возможность передавать непечатаемые символы.
Реализует один из первых шифроалгоритмов, UU-кодирование. Иногда используется при почтовых пересылках статей в службе новостей.
Этот метод шифрования едва ли когда-либо будет использоваться. По сути, это то же самое UU-кодирование, но с другой таблицей шифрования.
Компоненты с различными разновидностями алгоритма шифрования MD (Message Digest). Все они основаны на перемешивании, являются односторонними и не имеют алгоритмов расшифровывания.
Компоненты протокольных клиентов и серверов могут быть использованы для разработки серверных и клиентских Интернет-приложений, совместно или взамен базовых (ClientSocket, ServerSocket) и других компонентов из состава палитры Internet и Fastnet. Компоненты Indy не используют архитектуру WebBroker, реализуя поддержку Интернет-протоколов и служб на нижнем уровне непосредственно в своем исходном коде (исходные коды прилагаются).
Протокол SSL - Secure Sockets Layer (Секретный Уровень Сокетов), обеспечивающий секретность и надежность связи между двумя приложениями, имеет два уровня. На низком уровне многоуровневого транспортного протокола (например, TCP) SSL является протоколом записи и используется для инкапсуляции различных протоколов более высокого уровня. Преимущество SSL состоит в том, что он является независимым протоколом прикладной программы, при этом протокол более высокого уровня может быть использован поверх SSL.
SSL осуществляет защиту связи, которая имеет три основные функции: обеспечение конфиденциального соединения; шифрование с открытым ключом (используется для подтверждения подлинности адресата); поддержка надежности передачи данных.
В сочетании с протоколом HTTP и аутентификацией сервера протокол SSL обеспечивает необходимые функции шифрования и в дальнейшем поддерживает установленное соединение, перепроверяя подлинность Web-сервера и т.п. Важно понять, что SSL только защищает связь в процессе передачи данных, а не заменяет другие защитные механизмы.
Компоненты TIdConnectionInterceptOpenSSL и TIdServerInterceptOpenSSL обеспечивают соединение как со стороны клиента, так и со стороны сервера в соответствии с протоколом SSL. Необходимо отметить, что компоненты TIdConnectionInterceptOpenSSL и TIdServerInterceptOpenSSL есть только в Delphi 6, а в Kylix отсутствуют. Это связано со сложностью протокола, который в случае реализации Windows основан на функциях операционной системы.
Примеры использования компонентов Indy можно найти в каталогах /Delphi6/Demos/Indy. Всего библиотека Indy в версии 8.0 содержит 69 компонентов. Заявлено, что в версии 9.0 указанная библиотека будет содержать 86 компонентов. Все компоненты унифицированы и включены как в Delphi 6, так и в Kylix, что позволяет использовать их для разработки кросс-платформенных приложений. Все компоненты Indy поддерживают многопоточность.
В компонентах Indy реализована почти вся функциональность, имеющаяся в компонентах Internet и Fastnet, что наглядно показано в таблице .
Исключение составляют такие классы, как TNMMsgServ, TNMMsg, TNMStrm, TNMStrmServ, TpowerSock, TNMGeneralServer, TNMURL, которые либо реализуют морально устаревшие протоколы, либо обладают функциональностью, реализованной в большой группе альтернативных классов.
Однако в отличие от своих предшественников - компонентов Internet и Fastnet, в Indy богаче представлены серверные компоненты и компоненты перекодирования и шифрования данных, а также поддержка аутентификации (палитра Indy Misc). Как видно из приведенной выше таблицы, основные протоколы и службы обеспечиваются не только клиентскими, но и серверными компонентами. Это службы времени, отклика, получения информации о пользователе, а также протоколы HTTP, NNTP, UDP и даже простейший вариант FTP.
Компонентах Indy, которые содержатся в Delphi, IP-адрес определяется в свойстве Host, как правило, только в клиентских приложениях. Компоненты, размещаемые на сервере, имеют методы, позволяющие начать или прекратить опрос соответствующего порта, - например изменение свойства Active компонента IdTCPServer начинает или прекращает опрос соответствующего порта. После установки связи между клиентом и сервером можно начинать передачу данных.
В компонентах Indy большое внимание уделяется безопасности и надежности при работе с данными. Например, в компоненте IdTCPClient есть методы Connect и Disconnect. Применяя технику программирования, как в приведенном ниже коде со стороны клиента:
With TCPClient do begin Connect; try lstMain.Items.Add(ReadLn); finally Disconnect; end; end;
и используя свойство Connection, передаваемое в качестве параметра экземпляра AThread класса TIdPeerThread, со стороны сервера:
With AThread.Connection do begin WriteLn("Hello from Basic Indy Server server."); Disconnect; end;
можно рассчитывать либо на штатное выполнение соединения, либо на правильную обработку ошибки.
Обратите внимание на методы ReadLn и WriteLn соответствующих классов - они напоминают стандартные операторы ввода-вывода Pascal. Это дань технике программирования в UNIX, где большинство системных операций выполняются благодаря чтению и записи в соответствующие файлы.
Так же как у компонентов Fastnet, у классов компонентов Indy имеются события, при помощи которых можно организовывать событийное управление. Например, можно организовать вывод сообщения на форму при соединении с клиентом:
Procedure TForm1.IdECHOServer1Connect(AThread: TIdPeerThread); begin lblStatus.caption:= "[ Serving client ]"; end;
В Indy представлены компоненты, реализующие протоколы с клиентскими и серверными частями, присущие только этой библиотеке. Компоненты TIdGopherServer и TIdGopher, благодаря методам GetExtendedMenu, GetFile, GetMenu, GetTextFile на клиентской стороне и ReturnGopherItem, SendDirectoryEntry - на стороне сервера, помогают осуществить просмотр файлов различного типа, в том числе помеченных как скрытые, а также директорий на удаленном компьютере (подобно тому, как это делает команда dir *.* в операционной системе MS-DOS).
При помощи компонентов IdSMTP и IdMessage можно легко создать свое Web-приложение, способное отправлять почту по протоколу SMTP (рис. 4).
При этом класс IdMessage (один из 23 компонентов со страницы Indy Misc) отвечает за формирование сообщения, что вытекает из его названия, а IdSMTP - за организацию соединения с почтовым сервером.
Технология, применяемая в Indy, использует операции чтения и записи с блокировкой. Любая операция Connect, используемая в Indy, ожидает завершения соединения. При работе с клиентскими компонентами Indy, как правило, требуется выполнение следующих операций:
Компоненты Indy разрабатывались так, чтобы обеспечить сверхвысокий уровень абстракции. Запутанность и подробности стека TCP/IP скрыты от программиста, с тем чтобы он мог сосредоточиться на текущих задачах.
Следующий небольшой пример показывает типичную сессию клиентского компонента:
With IndyClient do begin Host:= "zip.pbe.com"; // Host to call Port:= 6000; // Port to call the server on Connect; try // Your code goes here finally Disconnect; end; end;
В примере, даже если соединение с сервером не будет установлено, связь корректно разорвется благодаря использованию оператора try-finally.
Серверные компоненты Indy описывают разнообразные модели серверов, которые можно использовать в зависимости от потребностей и применяемого протокола.
TIdTCPServer - наиболее часто используемый серверный компонент, который создает вторичный процесс, независимый от основного процесса приложения. Созданный процесс ожидает входящие запросы от потенциальных клиентов. Для каждого клиента, на запрос которого он отвечает, создается индивидуальный вторичный процесс. События, возникающие в процессе обслуживания, соотносятся с контекстом соответствующих процессов (рис. 5).
Иными словами, для каждого клиентского подключения класс TIdTCPServer использует уникальный вторичный поток, вызывая обработчик события OnExecute этого потока. Формальным параметром метода OnExecute является ссылка на экземпляр класса Athread, соответствующего созданному потоку. Свойство Connection этого класса - ссылка на класс TIdTCPConnection, экземпляр которого создается для обработки клиентского запроса. TIdTCPConnection поддерживает чтение и запись через соединение, а также установление и завершение сеанса связи.
Протокол UDP работает без предварительной установки соединения с сервером (каждый посланный пакет является самостоятельным набором данных, а не частью большой сессии или соединения). В то время как TIdTCPServer порождает отдельные потоки для каждого соединения, TIdUDPServer использует или главный поток, или единственный вторичный поток, который обрабатывает все запросы протокола UDP. Когда TIdUDPServer активен, создается поток для прослушивания входящих UDP-пакетов. Для каждого полученного пакета возникает событие OnUDPRead или в основном потоке, или в контексте прослушивающего потока - в зависимости от значения свойства ThreadedEvent. Когда ThreadedEvent принимает значение False, событие возникает в основном потоке, в противном случае - в прослушивающем потоке. Пока происходит обработка события, другие операции сервера блокируются. Поэтому важно следить, чтобы процедуры OnUDPRead выполнялись как можно быстрее.
Если нужно создать клиентское приложение нового клиента для существующего сервера с использованием существующего протокола, ваша задача состоит исключительно в разработке и отладке клиентского приложения. Однако, когда приходится разрабатывать и клиентское, и серверное приложения с применением существующего или нового протокола, мы сталкиваемся с классической проблемой «яйца и курицы». С чего начинать программирование - с клиента или с сервера?
Очевидно, в итоге должны быть созданы и клиент, и сервер. Для многих приложений, особенно использующих текстовый протокол (например, HTTP), проще начать создание приложения с проектирования сервера. А для его отладки имеется удобный клиент, который уже существует. Это - консольное приложение Telnet, которое имеется и на Windows, и на UNIX.
Если набрать консольную команду telnet 127.0.0.1 80 с IP-адресом локального компьютера и номером порта 80, используемым по умолчанию Web-серверами, то приложение откликнется текстом, представленным на рис. 6 , в случае ОС Windows 2000 и IIS 5.0.
Для создания самого простого сервера с использованием компонентов Indy необходимо:
Методы, подобные вышеприведенному обработчику события, обязательно должны включать операторы try-finally, чтобы иметь возможность разорвать соединение с клиентом независимо от того, как происходила обработка операторов, выполняемых при соединении, а также c целью корректной обработки непредвиденных временных задержек при соединении.
В действительности для обеспечения синхронизации после нажатия клавиши Enter в контексте клиента на сервере происходит так называемый блокирующий вызов (временная задержка на несколько микросекунд), необходимый для обеспечения работы с другими возможными клиентами. При этом, поскольку каждый запрос от клиента обрабатывается независимо и одновременно, обслуживание со стороны сервера происходит в среднем за одно и то же время. Если бы вы программировали сервер без использования компонентов Indy, то операции такого типа пришлось бы поддерживать самостоятельно.
Если необходимо спроектировать сервер, который будет не только корректно информировать своих клиентов о разрыве соединения, но и выдавать для них информацию о возникших ошибочных ситуациях, применяйте оператор try-except вместо try-finally - например, как показано в следующем примере:
Procedure TDataModule1.IdTCPServer1Execute(AThread: IdPeerThread); var s: String; begin with AThread.Connection do try try s:= ReadLn; // Perform the task of the server here // if no exception is raised, // write out the server"s response WriteLn(s); except on e: Exception do begin WriteLn(e.Message); end; //on end; //try except finally Disconnect; end; end;
Этот небольшой пример демонстрирует этапы создания простого текстового сервера, а также способы его отладки.
Вышеописанный сервер является типичным примером организации современного распределенного вычисления.
Последнее время для удовлетворения клиентских запросов все чаще используются множественные серверы. Сервер такого типа, получив запрос клиента и частично подготовив его для дальнейшей обработки, связывается с другим сервером и передает ему трансформированный запрос или запросы. Сервер второго звена может, в свою очередь, связываться с другими серверами. Таким образом, можно говорить о многозвенной серверной архитектуре.
Далее мы займемся созданием сервера доступа к данным, назначение которого состоит в том, чтобы возвращать данные из базы данных. Этот сервер, однако, не осуществляет чтения и записи в файлы базы данных непосредственно. Вместо этого он связывается с сервером базы данных в поисках данных, требуемых клиентом.
Итак, мы приступаем к разработке приложения с трехзвенной архитектурой. Для создания сервера базы данных с использованием компонентов Indy необходимо:
+ при загрузке файлов по ФТП
- при создании новых сообщений форума
- при возвращении активности ранее деактивированным элементам
- при загрузке статических страниц через интерфейс системы
- при импорте элементов инфоблоков
+ при импорте учебных курсов
Вам нужно провести конференцию или аналогичное мероприятие? Аренда конференц залов в Киеве - вот, что Вам нужно. Доступные цены и высочайшее качество гарантировано!
2. Обновить поисковый индекс необходимо:
После импорта данных через файл CSV
- после активации ранее неактивных элементов
+ изменения параметров морфологического поиска
- после добавления элементов инфоблоков
+ после добавления файлов через ФТП
+ после изменения, добавления правил сортировки
+ создания списка «стоп»-слов
3. Ручная переиндексация:
Не требуется никогда
+ необходима при изменениях адресов форумов, блогов
+ требуется при добавлении информации не через интерфейс системы
+ требуется для модуля Социальная сеть, если выполнялась переиндексация сайта
- необходима только по требованию системы
+ необходима при изменении информации без изменения даты
- требуется при изменения адресов в настройках компонентов при использовании инфоблоков
+ необходима при изменениях в учебных курсах
4. Ограничение области поиска может быть задано с помощью настроек компонента:
- «Форма поиска»
+ «Страница поиска»
5. Чтобы динамическая страница могла участвовать в поиске по её свойствам необходимо:
Включить инфоблок в список индексируемых в настройках модуля «Поиск»
+ поставить соответствующие опции в настройках свойств инфоблока.
- включить инфоблок в список индексируемых в настройках модуля «Информационные блоки»
6. В индексе участвуют:
+ информационные блоки, для которых в настройках свойств указано соответствующее разрешение
+ статические страницы, для которых задан заголовок $APPLICATION -> SetTITLE<>
- статические страницы, в настройках свойств которых разрешено участие в поиске
- любые статические страницы
- информационные блоки, для которых в настройках свойств указано правильные адреса страниц
7. Результат поиска выдается в соответствии с
+ правами пользователя
+ заданными ограничениями на область поиска
- ограничениями модулей и компонентами системы
8. Ограничения на область поиска в настройках модуля «Поиск» можно наложить:
+ на тип файла по маске
- на вид информации (статическая или динамическая)
+ на размер файла
+ на конкретные папки и файлы
- на количество индексируемых документов
9. Использование Google Sitemap позволяет:
+ быстрее попасть в результаты поисковой выдачи
+ уменьшить нагрузку на сайт
- получить преимущества при ранжировании
+ более полно проиндексировать сайт
10. Для правильной работы поиска необходимо чтобы URL страниц, заданных в настройках инфоблока вели
+ на реальные страницы с компонентами или программным кодом, обрабатывающим передаваемые ему параметры
- на реальные страницы
- на реальные страницы с компонентами, в которых подключены именно эти инфоблоки
11. Для определения документов, не участвующих в поиске, на странице настроек модуля «Поиск» служит поле:
Маска включения
- Символы, по которым не производится разделение документа на слова
+ Маска исключения
12. Поисковая фраза: «немецкий автомобиль» не (опель или opel) (1938 или 1939) - для модуля «Поиск» означает найти
Немецкие автомобили производства ранее 1938 или позднее 1939 года не Опель.
+ немецкие автомобили производства всех компаний, кроме Опель, 1938 или 1939 года выпуска с точной фразой в тексте «немецкий автомобиль».
- немецкие автомобили производства всех компаний, кроме Опель, 1938 или 1939 года выпуска.
- немецкие автомобили производства 1938 или 1939 года не Опель.
13. Вес - это:
Инструмент, позволяющий отдать при выдаче результатов поиска предпочтение документам той или иной тематики
- значение, определяющее релевантность документа запросу
+ параметр правила сортировки в поисковой выдаче
14. Использование быстрого поиска
+ увеличивает скорость выдачи результатов
- ограничивает число найденых документов
+ ухудшает ранжирование
15. Правила сортировки используются для:
Исключения определенных документов из поиска
- снижения нагрузки на сервер при выполнении переиндексации сайта
+ управления порядком вывода информации в списке результатов поиска
16. Ограничения на область поиска по статической и динамической информации можно задать:
В настройках свойств инфоблока
- в настройках свойств страницы
- в настройках модуля Поиск
+ в настройках компонента Страница поиска
17. На странице «Переиндексация сайта» (Настройки > Поиск > Переиндексация) можно выполнить переиндексацию
+ блогов
+ форумов
- cоциальной сети
+ инфоблоков
+ статических страниц
+ учебных курсов
18. Чтобы статическая страница могла участвовать в поиске необходимо:
+ создать заголовок страницы
- сохранить страницу с именем index.php
- задать ключевые слова страницы
Индексирующий робот Яндекса регулярно обходит страницы сайтов и загружает их в поисковую базу. При этом робот может загрузить не все нужные вам страницы из-за их недоступности.
Яндекс.Вебмастер позволяет узнать, какие страницы вашего сайта обходит робот и выявить адреса страниц, которые робот не смог загрузить из-за недоступности сервера, на котором находится сайт, или из-за ошибок в содержимом самих страниц.
Данные о страницах доступны в Яндекс.Вебмастере на странице Индексирование → Статистика обхода . Информация обновляется ежедневно в течение шести часов с момента посещения страниц роботом.
По умолчанию сервис предоставляет данные по сайту в целом. Чтобы просмотреть информацию о конкретном разделе, выберите его из списка в поле с адресом сайта. Доступные разделы соответствуют структуре сайта, известной Яндексу (кроме разделов, добавленных вручную).
Если в списке не все страницы, которые должны участвовать в поиске, сообщите о них с помощью инструмента Переобход страниц .
Информацию о страницах можно выгрузить в формате XLS или CSV с учетом примененных фильтров .
Информация о страницах представлена следующим образом:
Новые и изменившиеся - количество страниц, которые робот обошел впервые, и страниц, статус которых изменился после очередного обращения к ним робота.
История обхода - количество страниц, которые робот обошел, с учетом кода ответа сервера.
Чтобы просмотреть изменения, установите переключатель в положение Последние изменения . В результате отобразится до 50 000 изменений.
Вебмастер показывает следующие сведения о страницах:
код ответа сервера, полученный роботом при посещении страницы.
Основываясь на этой информации, можно узнать, как часто робот обходит страницы сайта, а также понять, какие страницы только появились в базе робота, а к каким робот обращается повторно.
Появление страницы в поисковой базе
Для страницы, которую робот обошел впервые, в столбце Было отображается статус N/a, а в столбце Стало - ответ сервера (например, 200 OK).
После успешной загрузки в поисковую базу страница может появиться в результатах поиска с ближайшими обновлениями поисковой базы. Информация о ней становится доступна в разделе Страницы в поиске .
Повторное обращение робота к странице
Если робот ранее обошел страницу, то при повторном обращении к ней статус может измениться: в столбце Было отображается ответ сервера, полученный во время предыдущего посещения робота, в столбце Стало - ответ сервера, полученный при последнем обращении.
Например, участвующая в поиске страница стала недоступна для робота. В этом случае она исключается из поиска. Через некоторое время после этого ее можно увидеть в списке исключенных в разделе Страницы в поиске .
Удаленная из поиска страница еще может оставаться в поисковой базе для проверки ее доступности. Как правило, робот продолжает обращаться к такой странице, пока на нее ведут ссылки или она не закрыта в файле robots.txt .
Чтобы увидеть список страниц, установите переключатель в положение Все страницы . Список может содержать до 50 000 страниц сайта.
Вы можете просмотреть список страниц сайта, которые обошел робот, и следующую информацию о них:
дата последнего посещения страницы роботом (дата обхода);
адрес страницы относительно корневого каталога сайта;
код ответа сервера при последней загрузке страницы роботом.
Совет. Если в списке отображаются страницы, которые уже удалены с сайта или не существуют, вероятно, робот находит ссылки на них при посещении других ресурсов. Чтобы робот перестал обращаться к ненужным страницам, запретите их индексирование с помощью директивы Disallow в файле robots.txt .
Информацию о страницах и изменениях в поисковой базе робота можно фильтровать по всем представленным параметрам (дате обхода, URL страницы, коду ответа сервера) с помощью значка . Ниже описано несколько примеров:
По ответу сервера
Можно составить список страниц, которые робот обошел, но не смог загрузить из-за ответа сервера 404 Not Found.
При этом можно выявить новые страницы, недоступные роботу, установив переключатель в положение Последние изменения :
А также - получить общий список страниц, недоступных роботу, установив переключатель в положение Все страницы :
По URL с указанием определенного фрагмента адреса
Можно составить список страниц, адрес которых содержит определенный фрагмент. Для этого выберите из списка значение Содержит и в поле укажите нужное значение.
По URL с указанием специальных символов
Специальные символы позволяют задавать не строгое соответствие строки, а ее начало, подстроку и более сложные условия с применением регулярных выражений. Чтобы использовать их, выберите из списка значение Условия , а само условие введите в поле. Можно добавить несколько условий - каждое из них должно начинаться с новой строки.
Для условий доступны правила:
выполнять любое из условий (соответствует оператору «ИЛИ» );
выполнять все условия (соответствует оператору «И» ).
Символ | Описание | Пример |
---|---|---|
* | Использование символа * |
|
@ | ||
~ | регулярному выражению | |
! | Отрицание условия |
Символ | Описание | Пример |
---|---|---|
* | Соответствует любому количеству любых символов | Отобразить данные по всем страницам, которые начинаются с https://example.com/tariff/ , включая указанную страницу: /tariff/* Использование символа * Символ * может быть полезен при поиске URL, которые содержат два определенных элемента или более. Например, можно найти новости или анонсы за определенный год: /news/*/2017/ . |
@ | Выбранные данные содержат указанную строку (но не обязательно строго соответствуют) | Отобразить данные по всем страницам, URL которых содержит указанную строку: @tariff |
~ | Условие является регулярным выражением | Отобразить данные по страницам, URL которых удовлетворяет регулярному выражению . Например, можно выбрать все страницы, в адресе которых есть одно или несколько упоминаний: ~table|sofa|bed |
! | Отрицание условия | Исключить данные по страницам, URL которых начинается со строки https://example.com/tariff/ : !/tariff/* |
При использовании символов не учитывается регистр.добавьте сайт в Яндекс.Вебмастер и подтвердите права на него. Также проверьте, не было ли сбоев на сервере. Если сервер выдает ошибку, робот прекращает индексирование и сделает следующую попытку в порядке общего обхода.
Сотрудники Яндекса не могут ускорить добавление страниц в поисковую базу.
Мы не прогнозируем сроки индексирования сайтов и не даем гарантий, что тот или иной сайт будет проиндексирован. Как правило, от момента узнавания роботом о сайте до появления его страниц в результатах поиска проходит от нескольких дней до двух недель.
Робот берет ссылки с других страниц, а это значит, что на какой-то странице указаны ссылки на секретные разделы вашего сайта. Вы можете как закрыть их паролем, так и указать запрет для робота Яндекса в файле robots.txt . И в том, и в другом случае робот не будет скачивать секретную информацию.