015 MSMS-банк Дополнение CLINT  (c) 2002

Шаг 1. Исследуются сервисные хосты на предмет содержания регистрационных форм. Создается единая регистрационная маска, включающая в себя все возможные строки. Перечень этих строй и их возможных обозначений берется по совокупности всех найденных форм, плюс в  анализатор проги закладываются возможные сокращения и омонимы из словаря.
Во время работы CLINTа он отсылает оператору те формы, на которых ему не удалось зарегистрироваться. Оператор путем анализа устанавливает причину неудачи и если причина – новая строка или новое обозначение известной ранее строки – дополнения вносятся в анализатор CLINTа.
Итог: создана единая обобщенная регистрационная форма – маска («Емаск»)

Шаг 2. Делается программа работы с единой рег. маской. Принцип ее состоит в том, что полученная CLINTом рег. форма сервиса сравнивается с единой маской, отмечаются совпавшие поля формы. По совпавшим полям формируется ТСР-пакет/регистратор с введенными из БД CLINT рег. данными и отправляется на хост-матку.
Если в ходе сравнения CLINT обнаруживает какое-то новое поле, отсутствующее в единой маске, он прекращает регистрацию и сигнализирует об этом оператору. Таким способом происходит «обучение» CLINTа.
Итог: создание блока работы с Емаск.

Шаг 3. Блок ответа/реакции на принятую рег. форму.
После того, как нужная для данного сервиса рег. форма была успешно создана и отправлена на уделенный сервис, возможна одна из нескольких реакций сервиса на эту форму:
- возврат подтверждения о регистрации;
- сообщение о том, что рег. данные будут высланы на e-mail;
- другое*.
* В «другое» здесь входят все возможные реакции, список которых и реакция CLINT на каждую будет постоянно пополняться в ходе обучения CLINT.
Сколь много реакций удаленного хоста бы не было, их все можно разделить на два типа: реакция, требующая продолжения работы данного блока CLINT*; и реакция, прекращающая работу CLINT с этим хостом в данном сеансе связи**.
*Это может быть возврат подтверждения о регистрации (тогда CLINT прописывает сразу клон на зарегистрированное место); это может быть предложение о какой-то подписке, доп. услугах (CLINT посылает отказ, либо иную реакцию). В общем, это может быть что-то, что требует еще какой-то работы с данным хостом от блока ответа/реакции на этом шаге.
**Например, если хост прислал ответ, что рег. данные будут высланы по почте.
В соответствии с заложенными в него процедурами, блок в зависимости от типа реакции сервера запускает одну из них. На каждую реакцию, либо на группу схожих реакций в CLINTе имеется свой блок ответа.
Таким образом, на этом шаге мы получаем проанализированную задачу, которая передается для решения другим блокам CLINT.
Итог: Имеем первичный блок реакции на ответ сервера-матки по отосланной рег. форме.

Шаг 4. Вторичные блоки реакции.
Вторичные блоки реакции служат для ответа серверу-матке на различные дополнительные запросы в процессе регистрации.
По сути, это просто куски дополнительного кода в первичном блоке реакции, которые дописываются по мере необходимости. Упрощенно это выглядит так:
If [событие 1] GO 1
If [событие 2] GO 2
1: [первичный блок реакции]
2: [вторичные блоки реакции]

Первичным блоком реакции (БР1 далее) обрабатываются стандартные (наиболее часто встречающиеся) процедуры. Если БР1 встречает нестандарт, то он передает процесс регистрации на данном хосте вторичным блокам (блоку) для дальнейшего разбирательства с этим «неправильным» хостом-маткой. Сам же начинает новую регистрацию на следующем хосте из своего списка заданий, чтобы не тормозить общий процесс работы CLINT.
Поэтому вторичный блок должен уметь все то же, что и БР1 и кроме этого – сообщать оператору о незнакомом событии, делать паузу и после того, как оператор «объяснит» ему порядок дальнейшей (и будущей) работы с таким событием (пропишет новую инструкцию) – БР2 продолжает прерванную регистрацию.
После того как БР2 завершил с помощью новой инструкции нестандартный процесс успешно, запись о новом способе передается БР1 для включения ее в «стандартные» процедуры реакции.
Т.о., БР2 – это как бы «консультант» БР1 по нестандартным вариантам поведения хоста-матки.
Итог: создан БР2, помощник БР1 по нестандартным процедурам регистрации.

Нестандартный итог:
- создана единая обобщенная регистрационная форма EMask;
- создан логический блок работы с EMask;
- создан первичный блок реакции на ответ сервера-матки по отосланной рег. форме;
- создан вторичный блок реакции, помощник БР1 по нестандартным процедурам регистрации.
 CLINT самостоятельно регистрируется на сайтах-матках.

Шаг 5. Обработка отложенной регистрации.
Общий принцип действия блока отложенной регистрации такой же, как и у БР1/БР2. Блок отложенной регистрации состоит из двух подблоков: БОР-1 (первичный) и БОР-2 (вторичный). БОР-1 обрабатывает стандартные, наиболее часто встречающиеся ситуации; БОР-2 помогает ему с нестандартными вариантами.
Наиболее часто встречающийся вариант отложенной регистрации – это отправка юзеру рег. данных на указанный при регистрации e-mail. Рассмотрим этот вариант.
При любой регистрации, будь то регистрация CLINTом клона на сервере Web-хостинга, либо это регистрация на каком-то полезном сервисе (где также можно использовать CLINT для увеличения предлагаемых единичному пользователю услуг) – практически везде требуется ввести адрес e-mail для обратной связи с пользователем. Значит, CLINT должен уметь самостоятельно регистрить нужное ему для работы количество почтовых учетных записей на самых разных б/п почтовых хостах.
Для этой цели вполне подходит БР-1. Т.к. при регистрации e-mail не требуется еще один e-mail, процесс регистрации такой же, как на хостах-матках. Не будем здесь останавливаться подробно на работе БР-1, будем считать, что e-mailов у нас – в неограниченном количестве.
При работе БР-1 на стадии регистрации клона, сервер-матка может прислать рег. данные на указанный при регистрации e-mail.
Этот e-mail переадресовывается на тот сервер, где стоит CLINT. Либо этот e-mail переадресовывается на сервер, где стоит только блок БОР-1;2 так, чтобы рег. данные попали на БОР. Т.к. на удаленных клонах, где будут копии/клоны CLINT, доступ к почтовому серверу этого хоста не всегда возможен (?), проще разнести рабочие блоки CLINTа на разные сервера, в зависимости от их, блоков, особенностей работы и соответствия этой работы функциональным возможностям сервера, где он (блок) находится.
Присланные рег. данные вырезаются из письма почтовым роботом ТМ и передаются БР-1 для продолжения регистрации клонов.
БОР для варианта с e-mail-регистрацией это, по сути, просто почтовый робот ТМ.
Итог: БОР-1;2, который позволяет рег. на хостах, присылающих рег. данные на e-mail (LOGIN/PASSWORD).

Регистрация за плату.

Описание 5 шагов позволяют CLINT работать с любым бесплатным сервером.
Для работы с платными серверами в системе CLINT включены специальные блоки: автокассир; автоменеджер счетов; банковский аватар-регистратор.
Аватар-регистратор: автоматически открывает цифровые счета в И-банках.
Автоменеджер счетов: следит за счетами, открытыми аватарами; передает автокассиру по запросу (либо при достижении на счете определенного минимума денег) данные счета-эмитента для оплаты услуги. Перераспределяет деньги со счета на счет (с помощью автокассира) по заданному алгоритму финансовой политики хозяина CLINTа.
Автокассир: выполняет операции со счетами, указанными автоменеджером. Не имеет собственной БД счетов.


Эти три блока обязательно располагаются на разных хостах (IP-адресах), причем Автоменеджер располагается на наиболее защищенном, т.к. в нем есть вся инфа по счетам и доступ к ним.
Аватар-регистратор (АР)
Те же шаги 1-5, но EMask настраивается на рег. форму Е-Банка. Банки выбираются вручную оператором для БР-1, т.к. в отличии от хостов Web-услуг хостинга, которые, по сути, все примерно равны по ценности для PR-клонов, банки все-таки лучше выбирать более разборчиво… J А так, по сути, - все то же самое, только формы немного другие будут.
Автокассир (АК)
Блок, автоматически заполняющий формы управления счетом в Е-Банке по указанию блока «Автоменеджер». Является отвлекающим маневром для «плохих дядей», т.к. контакт с банками идет только через его IP-адрес, и вероятность попытки взлома или иного нападения на него велика.
Именно поэтому он отделен от автоменеджера, хотя можно было бы сделать и вместе. Подставляя его под удар на отдельном удаленном IP-адресе, CLINT обезопасит таким образом БД «менеджера», где лежат все коды доступа к Е-счетам.
К тому же автокассиров можно наделать много и пользоваться ими в одноразовом режиме «Отработал – самоуничтожился». У автоменеджера просто есть список готовых к работе автокассиров (которые делаются так же, как и другие клоны шагами 1-5) и он использует их по очереди.
Автоменеджер (АМ)
Задачи, выполняемые АМ:
- заносить в БД данные по всем новым счетам, открываемым Аром;
- заносить в БД данные по счетам, вводимым вручную через инет или локальную сеть;
- заносить в БД условия подписки на обслуживаемые платные сервисы системы CLINT (платный хостинг; платные подписки и т.п.) и следить за своевременной оплатой этих услуг;
- следить за работоспособностью платных услуг и приостанавливать оплату, сигнализировать оператору о нерабочих услугах;
- передает автокассиру задания на оплату услуг вместе с необходимыми для этого реквизитами;
- сигнализирует оператору о достижении на счетах минимального лимита;
- выдает оператору по запросу справки по текущим счетам.

Принцип действия АМ
АМ – это по сути Аватар с зачатками ИИ, т.к. выполняет рутинную работу оператора-человека. Соответственно, суперскорость работы ему не нужна. В то же время надежность работы и ненадежность хранения его БД очень важна. Не менее важна и секретность находящейся у него информации.
Поэтому АМ работает с обязательным как min тройным дублированием основных файлов БД и по принципу «распределенного ПО» (показанного ниже на рисунке). Также в работе АМ используется 128-битное шифрование с открытым или закрытым ключом. Клоны для резервных копий делаются по уже известному принципу «инет – один большой диск пользователя».
Распределенное ПО


Шаг 6. Регистрация на платных сайтах, с оплатой через банковский счет.
После прохождения регистрации БР-1 передает процесс БОР-1. Который в свою очередь дает задание автоменеджеру оплатить выбранный сервис, указывая в задании реквизиты счета и сумму.
АМ вносит данный сервис в свою учетную БД и передает задание на исполнение автокассиру.
АК переводит требуемую сумму на счет платного сервиса. После подтверждения оплаты сервисом (тот высылает на зарегистрированный e-mail подтверждение, надо полагать) процесс передается БР-1 для закачки на сервис контента.
28.09.2002г.