Главная страница
Навигация по странице:

  • 17.5. Postal Code Server - реализация OnExecute OnExecute Implementation Demo Threads 17.6. Postal Code Server – командные обработчики

  • 17.7. Управление потоками

  • 17.7.1. Класс TIdThreadMgrDefault

  • 17.7.2. Пул потоков (Thread Pooling)

  • 18. SSL – безопасные сокеты

  • 18.1. Безопасные протоколы HTTP и HTTPS

  • 18.4. Преобразование сертификатов в формат PEM

  • 18.4.1. Экспортирование сертификата

  • 18.4.2. Преобразование файла .pfx в .pem

  • 18.4.3. Разделение файла .pem

  • 19.1. Изменения в Indy 10 19.1.1. Разделение пакетов

  • Глубины Indy. 2. Техническая поддержка


    Скачать 1.03 Mb.
    Название2. Техническая поддержка
    Дата02.05.2018
    Размер1.03 Mb.
    Формат файлаpdf
    Имя файлаГлубины Indy.pdf
    ТипДокументы
    #42664
    страница12 из 16
    1   ...   8   9   10   11   12   13   14   15   16
    17.4.8. Реализация DATETIME
    Команда DATETIME – это последняя команда данного протокола. Оно отличатся и от
    QUIT и от HELP, в том, что требует особой функциональности, которая не может быть создана только с помощью свойств. Для реализации команды DATETIME будет использован обработчик события.

    90
    Для начала построим базовый обработчик команды, используя шаги с которым вы уже знакомы:
    1. Создадим новый командный обработчик.
    2. Command = DateTime
    3. Name = cmdhDateTime
    4. ReplyNormal.NumericCode = 200
    В данный момент свойство ReplyNormal.Text не определяется, обработчик события будет его определять для каждого ответа. Для определения обработчика, используйте инспектор объектов, выбрав командный обработчик для DATETIME. Переключитесь на закладку events и создайте событие OnCommand. Delphi создаст обработчик следующим образом:
    procedure
    TForm1.IdTCPServer1TIdCommandHandler2Command(ASender: TIdCommand);
    begin
    end
    ;
    В обработчик OnCommand передается аргумент of ASender типа TIdCommand. Это не командный обработчик, а сама команда. Командные обработчики глобальны для всех соединений, тогда как, команды специфичны для соединения connection и обрабатываются в рамках экземпляра события OnCommand. Это гарантирует, что обработчик выполнит корректную обработку для каждого клиентского соединения.
    Перед вызовом обработчика события, Indy создает экземпляр команды и инициализирует его свойства на основе данных обработчика команд. Вы можете использовать команды для смены свойства со значений по умолчанию, вызывать методы для выполнения задач или для доступа к свойству Connection для общения с соединением напрямую.
    Данный протокол определяет команду DATETIME, как имеющую дополнительный параметр, указывающий формат даты и времени. Команда (TIdCommand) реализует это с помощью свойства Params, которое является списком строк. Когда команда принимается от клиента и свойство ParseParams установлено в true (по умолчанию) Indy использует свойство CmdDelimeter (по умолчанию равное #32 или пробел) для разделения команды и параметров.
    Например, в данном протоколе, клиент может послать следующее:
    DATETIME hhnnss
    В этом случае, свойство ASender.Params будет содержать строку "hhnnss" в свойстве
    ASender.Params[0]. Количество параметров может быть определено с помощью свойства
    ASender.Params.Count.
    Используя данные свойства обработчик OnCommand может быть реализован следующим образом:
    procedure
    TForm1.IdTCPServer1TIdCommandHandler2Command(ASender: TIdCommand);
    var
    LFormat:
    string
    ;
    begin
    if
    ASender.Params.Count =
    0
    then
    begin
    LFormat :=
    'yyyy-mm-dd hh:nn:ss'
    ;

    91
    end
    else
    begin
    LFormat := ASender.Params[
    0
    ];
    end
    ;
    ASender.Reply.Text.Text := FormatDateTime(LFormat, Now);
    end
    ; данная реализация просто читает параметры и использует ASender.Reply.Text для посылки ответа обратно клиенту. Не требуется устанавливать ASender.Reply.NumericCode, так как
    Indy инициализирует его значением 200, из командного обработчика
    ReplyNormal.NumericCode.
    Примечание: используйте свойство ASender.Reply.Text.Text. Указание слова Text дважды требуется потому что свойство Text команды это список строк и мы имеем также
    TStrings.Text в дополнение к этому. Поскольку это список строк, другие методы или свойства, такие как Add, Delete и другие также могут использоваться. Свойство Text используется как ASender.Reply.Text, в некоторых случаях может быть предварительно проинициализировано и запись в него вызовет перекрытия текста.
    Если снова протестировать пример с помощью telnet, то теперь ответ будет таким:
    200 Hello
    datetime
    200 2002-08-26 18:48:06
    В некоторых случаях свойство Params не может быть использовано. Свойство DATETIME одно из них. Представим себе следующую команду:
    DATETIME mm dd yy
    В данном случае значение свойства Params.Count будет равно 3 и событие будет неверно обработано, возвратит только значение месяца (mm). Для данных случаев, когда значение параметра включает разделители, можно использовать свойство UnparsedParams.
    Дополнительно, свойство ParseParams можно установить в False.
    Свойство UnparsedParams содержит данные независимо от свойства ParseParams, но установка ParseParams в false увеличивает эффективность, сообщая Indy, что не требуется разбирать параметры в свойство Params.
    Обработчик события, модифицированный для использования с UnparsedParams:
    procedure
    TForm1.IdTCPServer1TIdCommandHandler2Command(ASender: TIdCommand);
    var
    LFormat:
    string
    ;
    begin
    if
    ASender.Params.Count =
    0
    then
    begin
    LFormat :=
    'yyyy-mm-dd hh:nn:ss'
    ;
    end
    else
    begin
    LFormat := ASender.UnparsedParams;
    end
    ;
    ASender.Reply.Text.Text := FormatDateTime(LFormat, Now);

    92
    end
    ;
    17.4.9. Заключение
    Обработчики команд очень гибки и содержат большее количество свойств и методов, чем приведено. Это только введение в обработчики команд и их возможности. Надеюсь, что этого достаточно, что вызвать у вас интерес и начать работать.
    Имеется также особые планы для будущих версий – сделать командные обработчики еще более наглядными и удобными на стадии разработки.
    17.5. Postal Code Server - реализация OnExecute
    OnExecute Implementation
    Demo
    Threads
    17.6. Postal Code Server – командные обработчики
    Command Handlers
    Greeting
    CommandHandlers
    ReplyException
    ReplyTexts
    ReplyUnknownCommand
    Demo
    17.7. Управление потоками
    Управление потоками абстрагировано в Indy в менеджеры потоков. Менеджеры потоков позволяют иметь различные (даже пользовательские) реализации стратегий управления потоками.
    Управление потоками - это необязательная дополнительная возможность. Если вы не определяете менеджер потоков в свойстве ThreadManager в компоненте, который поддерживает управление потоками (таком как TIdTCPServer) Indy неявно создает и уничтожает экземпляр менеджера потоков.
    17.7.1. Класс TIdThreadMgrDefault
    Стратегия управления потоками по умодчанию в Indy очень простая. Каждый раз, когда требуется поток, он создается. Когда поток не нужен, он уничтожается. Для большинства серверов – это приемлемо и пока вам не понадобится пул потоков, вы должны использовать стратегию управления потоками по умолчанию. В большинстве серверов различие в производительности ничтожное или полностью отсутствует.
    Стратегия по умолчанию также дает дополнительное преимущество, так как, каждый поток гарантировано «чистый». Потоки часто распределяют память или другие объекты.
    Эти объекты обычно освобождаются автоматически, когда поток разрушается.
    Использование управления потоками по умолчанию дает вам уверенность, что вся память освобождена и все очищено. Когда используется пуле потоков, то вы должны быть

    93 уверены, что все очищено перед повторным использованием потока. Несоблюдение этого правила, может привести к тому что, пользователь будет иметь доступ к информации предыдущего пользователя. Такие предосторожности не требуются при использовании менеджера потоков по умолчанию, поскольку все ассоциированные данные уничтожаются вместе с потоком.
    17.7.2. Пул потоков (Thread Pooling)
    Обычно диспетчеризация потоков по умолчанию вполне приемлема. Тем не менее, для серверов, которые обслуживают коротко живущие соединения, создание и уничтожение потоков, сравнимо со временем обслуживания запроса. В данной ситуации, лучше использовать пул потоков.
    В пуле потоки создаются предварительно и используются повторно. Они создаются до использования и хранятся неактивными в пуле. Когда требуется поток, то он берется из пула и активируется. Если требуется больше потоков, чем есть в пуле, то создаются дополнительные потоки. Когда поток больше не требуется, то вместо его разрушения он деактивируется и возвращается в пул.
    Создание и разрушение потоков может быть очень интенсивным. Это особо относится к серверам, которые обслуживают коротко живущие соединения. Такие сервера создают поток, который используется только короткое время и затем уничтожается. Это приводит к очень высокой частоте создания и уничтожения потоков. Примером таких серверов могуь служить сервера времени или даже web сервера. Посылается простой запрос и отсылается простой ответ. При использование браузера для просмотра некоторых сайтов могут создаваться сотни соединений к серверу.
    Пул потоков может смягчить данную ситуацию. Вместо создания и уничтожения потоков по требованию, потоки выдаются из списка неактивных потоков, которые уже созданы.
    Когда поток больше не нужен, он возвращается обратно в пул. Пока потоки находятся в пуле – они отмечены как неиспользуемые и поэтому не требуют ресурсов процессора. Как дальнейшее усовершенствование - размер пула можно настраивать динамически, в зависимости от потребностей системы. Indy имеет поддержку пула потоков. Пул потоков в Indy доступен через использование компонента TIdThreadMgrPool.
    18. SSL – безопасные сокеты
    SSL – это сокращение от Secure Socket Layer и является проверенным методом шифрования данных передаваемых через Интернет. SSL обычно используется для HTTP
    (Web) трафика и называется защищенный (secured) HTTPS. Конечно, SSL не ограничен
    HTTP и может быть использован с любым TCP/IP протоколом.
    Для использования SSL в Indy, вы во-первых должны установить поддержку SSL. Indy реализует поддержку SSL в открытом для расширения стиле, но единственная поддерживаемая сейчас реализация библиотеки SSL - это OpenSSL. Библиотека OpenSSL доступна, как набор DLL и доступна для загрузки отдельно от дистрибутива Indy.
    Экспорт некоторых методов шифрования, таких как SSL, запрещен благодаря неописуемой мудрости и понимания технологий правительством США и других стран. По этому SSL технология не может быть размещена на web сайте, без принятия определенных мер по точному определению местонахождения каждого клиента,

    94 желающего загрузить технологии. Это не только трудно для практической реализации, но и накладывает на влядельцев сайтов дополнительную ответственность.
    Ограничение касается только на распространение в электронном виде, но не на предоставление исходного кода в печатном виде. Даное ограничение касается только экспорта и не является важным.
    Поэтому программисты просто распечатали исходный код на футболках, пересекли границу, а затем ввели и скомпилировали его. После того как это произошло, страны, которые не подписали соглашение с США смогли свободно распространять технологию шифрования в любой форме и снять импорные ограничения для любого, кто пожелает загрузить технологию шифрования в форме пригодной для использования.
    Многие проблемы были разрешены с тех пор, и некоторые правительства даже поумнели.
    Тем не менее, многие экспортные ограничения продолжают иметь место и различаются от страны к стране. Поэтому, все работы по Indy SSL были сделаны в Словении и технологии шифрования, относящие к Indy были также распространены через Словению. Словения не имеет ограничений на экспорт технологий шифрования.
    В дополнение к экспорту технологий шифрования, некоторые страны имеют ограничения на использование и даже на владение технологиями шифрования. Вы должны проверить законодательство в вашей стране прежде чем делать реализацию с использованием SSL.
    Такие страны как Китай, Ирак и другие имеют суровые наказания и даже за владение такими технологиями.
    18.1. Безопасные протоколы HTTP и HTTPS
    Реализация протокола HTTPS в Indy очень проста. Просто укажите безопасный URL вместо стандартного URL и Indy клиент HTTP (TIdHTTP) все остальное сделает автоматически. Чтобы сделать URL безопасным, просто измените http:// на https://.
    Примечание: чтобы HTTPS сессия была установлена, web сервер, который отвечает должен поддерживать SSL и иметь установленный сертификат шифрования. Также HTTP клиенты Indy не проверяют сертификат сервера – это ваша обязанность.
    18.2. Другие клиенты
    SSL может легко реализована в любом TCP клиенте Indy с помощью использования SSL
    IOHandler. Обычно шифрование должно быть реализовано с помощью Intercept вместо
    IOHandler. SSL реализация в Indy использует IOHandler вместо Intercept, поскольку SSL библиотека выполняют весь обмен самостоятельно. Данные возвращаются в расшифрованной форме напрямую из SSL библиотеки.
    Чтобы сделать Indy TCP клиента с использованием SSL просто добавьте
    TIdSSLIOHandlerSocket на вашу форму с закладки Indy Misc. затем установите свойство
    IOHandler вашего TCP клиента в TIdSSLIOHandlerSocket. Это все, что требуется для базовой поддержки SSL. Класс TIdSSLIOHandlerSocket имеет дополнительные свойства для указания сертификатов клиентской стороны и другие расширенные SSL параметры.
    18.3. Сервер SSL

    95
    Реализация SSL сервера немного более сложная, чем реализация SSL клиента. С клиентами, все что требуется это сделать хук TIdTCPClient или его наследникам к экземпляру TIdSSLIOHandlerSocket. Это происходит потому что, поскольку сервер выполняет больше работы для поддержки SSL.
    Для реализации SSL сервера используется TIdServerIOHandlerSSL. TIdTCPServer's имеет свойства для установки хука на TIdServerIOHandlerSSL. Но в отличие от
    TIdSSLIOHandlerSocket (Client), класс TIdServerIOHandlerSSL требует несколько дополнительных шагов. Более конкретно - должен быть установлены сертификаты.
    Данные сертификаты должны быть представлены как файлы на диске и указаны в CertFile,
    KeyFile и RootCertFile, в соответствующих свойствах SSLOptions.
    Сертификаты обычно получают из уполномоченных источников. Вы можете иметь свой собственный сертификат и своего собственно источника, но ни один из браузеров не будет доверять вашим сертификатам и браузер будет выдавать диалог с предупреждением при соединении с вашим сервером. Если вы желаете распространять через Интернет, то вы должны получить сертификат из корневого хранилища, которому стандартный браузер будет доверять. Единственный сертификат, которому доверяют все браузеры – это сертификат от Verisign. Можно также использовать сертификат от Thawte, но не все браузеры доверяют ему по умолчанию. Примечание от переводчика: самое смешное, что
    Thawte принадлежит Verisign
    Если ваши клиенты под вашим контролем, такие как Интранет или Экстранет, то вы можете пользоваться своим собственным сертификатом. Для подавления выдачи диалога с предупреждением, вы должны установить ваш сертификат на каждый браузер, который подключается к вашему серверу. Это позволит браузеру считать ваш сертификат доверенным.
    Примечание: это относится только к HTTP серверам, но SSL не ограничен использованием только в HTTP. Вы можете реализовать SSL и получить полный контроль над правилами получения и принятия сертификатов.
    18.4. Преобразование сертификатов в формат PEM
    Существует шанс, что вы получите ваши сертификаты формате отличном от .pem. Если это так, то вы должны преобразовать их с помощью Indy.
    Данная процедура предполагает, что вы уже получили ключ и сертификатную пару от поставщика (Certificate Authority), например от Verisign или Thawte и уже установили их в персональное хранилище сертификатов (Personal Certificates Store) Microsoft Internet
    Explorer.
    18.4.1. Экспортирование сертификата
    Выберите сертификат и экспортируйте его в .pfx файл (Personal Exchange Format).
    Дополнительно вы можете его защитить с помощью пароля.
    18.4.2. Преобразование файла .pfx в .pem
    Как часть загрузки дистрибутива SSL, в него включена программа openssl.exe. данная программ преобразует ваш .pfx файл.

    96
    Для использование openssl.exe, используйте следующий синтаксис:
    openssl.exe pkcs12 –in .pfx –out .pem
    Openssl.exe запросит пароль. Введите его если он был задан или оставьте его пустым в противном случае. Также будет запрошен новый пароль для .pem файла. Это не обязательное условие, но если вы его защитите паролем, то вы должны будете создать обработчик события OnGetPassword в SSL перехватчике.
    18.4.3. Разделение файла .pem
    Если вы посмотрите созданный .pem файл с помощью блокнота, то вы увидите, что он разделен на две части. Эти две части содержат приватный и публичный ключи. Также приведено некоторое количество информации. Indy требует, что бы данная информация была помещена в отдельные файлы.
    18.4.4. Файл Key.pem
    С помощью блокнота создайте файл key.pem и скопируйте все между двумя, ниже указанными строками:
    -----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY-----
    18.4.5. Файл Cert.pem
    С помощью блокнота создайте файл cert.pem и скопируйте все между двумя, ниже указанными строками:
    -----BEGIN CERTIFICATE----- -----END CERTIFICATE-----
    18.4.6. Файл Root.pem
    Последний файл, который требуется для Indy – это Certificate Authority certificate файл. Вы можете получить его из Internet Explorer в диалоге Trusted Root Certificate Authority.
    Выберите поставщика (Authority), чей сертификат вы желаете экспортировать и экспортируйте его в Base64 (cer) формате. Данный формат, аналогичен PEM и после экспорта просто переименуйте его в root.pem
    19. Indy 10 обзор
    Indy 10 пока находится в стадии разработки. В ближайшие несколько недель он должен устояться. Поэтому любая приведенная здесь информация является предметом для изменения до выпуска Indy 10. Информация приведеная здесь, основывается на текущем коде, целях и направлении разработки.
    Indy 10 содержит много новых возможностей, особенно относящихся к ядру. Ядро Indy 10 сделано еще более абстрактным. Ядро Indy 10 содержит много новых возможностей и улучшений в производительности.
    19.1. Изменения в Indy 10
    19.1.1. Разделение пакетов

    97
    Indy 10 разделена на два пакета: ядро и протоколы.
    Пакет ядра содержит все части ядра, компоненты базовых клиентов и серверов. Ядро не реализует протоколы верхнего уровня.
    Пакет протоколов использует ядро и реализует протоколы верхнего уровня, такие как
    POP3, SMTP и HTTP.
    Это позволило команде Indy Pit Crew лучше сфокусироваться на специфических частях.
    Это также может быть полезно для пользователей, которые реализуют пользовательские протоколы и не нуждаюься в пакете протоколов.
    1   ...   8   9   10   11   12   13   14   15   16


    написать администратору сайта