Асинхронный вызов

Можно вызывать удаленные методы асинхронно - клиентский скрипт продолжает работать пока серверный метод исполняется и следовательно страница остается доступной для пользователя.

Вызов серверного метода асинхронно схож с синхронным вызовом, за исключением появления дополнительных параметров при вызове:

Ссылка на callback функцию в клиентском скрипте, которая вызывается при успешном завершении работы серверного метода. Ссылка на error callback функцию, которая вызывается при возникновении ошибки Необязательные контекстные параметры. Эти данные просто вернутся обратно по окончании работы серверного метода.

Как и при синхронном вызове, асинхронный вызов создает объект call, содержащий результат работы серверного метода и дополнительную статусную информацию.

При асинхронном вызове объект call передается в callback функцию в качестве параметра. Следовательно, вы можете проверить статус вызова и получить результат работы метода.

Так как при асинхронном вызове необходимо передать ссылку на callback функцию, то используется только JavaScript.

Для вызова серверного метода асинхронно:

Если вы создали page объект, то используется следующая форма вызова.

callObject = ASPObject.methodName(p1, p2[,...], callbackFunction, errorCallbackFunction, context);

В противном случае используется RSExecute() функция:

callobject = RSExecute(url, methodName, p1, p2[,...], callbackFunction, errorCallbackFunction, context)

Где:

callobject - имя call объекта; ASPObject - объект ссылающийся на ASP страницу; url - URL ASP страницы содержащей описание серверных методов. Эта страница должна находится на том же сервере, что и страница осуществляющая вызов; methodName - имя метода, который вы хотите исполнить; p1, p2 - параметры необходимые для вызова methodName метода. Параметра передаются по значению. В качестве параметров могут быть переданы значения простых типов. callbackFunction - ссылка на JavaScript функцию в клиентском скрипте, которая будет вызвана, когда удаленный метод окончит работу.
Т. к. вы передаете ссылку, не включайте имя функции в кавычки. errorCallbackFunction - ссылка на необязательную JavaScript функцию в клиентском скрипте, которая будет вызвана, если при работе удаленного метода произойдет ошибка. Т. к. вы передаете ссылку, не включайте имя функции в кавычки. context - необязательные параметры вызова, эти данные вернутся обратно.

Например, в следующем скрипте асинхронно вызывается серверный метод square. После работы метода вызывается функция showResults(). Имя операции передается как context-параметр.

<script language = "JavaScript" for = "btnSquare" event = "onclick"> rsMath = RSGetASPObject("../myPages/RSMath.asp"); number1 = txt1.value; context = "squaring"; co = rsMath.square(number1,showResults,context); </script>

Аналогичный пример с использованием RSExecute метода:

<script language = "JavaScript" for = "btnSquare" event = "onclick"> number1 = txt1.value; context = "squaring"; co = RSExecute("RSmath.asp","square",number1,showResults,context); </script>

Функция showResults, которая является callback функций в предыдущем примере, может выглядеть следующим образом:

Безопасность

Скриплет также безопасен, как HTML и скрипт. К тому же, в скриплете есть возможность распознать в каком контейнере он находится и если это контейнер с повышенными требованиями безопасности (IE), то скриплет работает согласно политике безопасности этого контейнера.

В общем случае для корректного функционирования необходимо чтобы скриплет был загружен с того же Web сервера, что и использующая его HTML страница (как и JAVA апплеты).

BitNet

Адрес похож на Internet'овский: пользователь@хост.

Преобразуется добавлением ".bitnet" в конце: пользователь@хост.bitnet.

Не все майл-серверы понимают домен .bitnet, им надо указывать шлюз,

например, пользователь%хост.bitnet@cunyvm.cuny.edu.

Что такое RS?

Remote Scripting (RS) - это механизм, обеспечивающий вызов серверных процедур из клиентского скрипта. С помощью RS, процедуры и функции, описанные на сервере, могут вызываться из скрипта HTML страницы, исполняющегося в браузере пользователя. Вызываемые процедуры и функции будем также называть серверными методами, далее вы поймете почему. Серверные методы описываются в ASP странице и для их реализации подходит любой язык сценариев (JavaScript, VBScript). При удаленном вызове процедуры и функции исполняются на сервере с полным доступом к системным ресурсам, а результат работы возвращается в клиентский скрипт.

Теперь разработчики могут создавать интерактивные Web приложения, в которых появляется возможность исполнять серверный скрипт без обновления страницы.

C использованием RS Web приложении может проверить корректность вводимых пользователем данных в процессе заполнения формы, избегая перезагрузки.

С появлением RS, Web приложение может использовать как клиентский, так и серверный скрипт. Клиентский скрипт часто используется для управления пользовательским интерфейсом, например, динамическое изменение содержимого Web страницы или обработка действий пользователя. Клиентский скрипт выполняется локально в браузере и обеспечивает интерактивный интерфейс.

Возможности применения серверного скрипта ограничиваются только вашей фантазией. Серверный скрипт может использоваться для доступа к базе данных или выполнения звена бизнес логики в многослойных приложения. При этом серверный скрипт исполняется на сервере с полным доступом к ресурсам сервера, а из клиентского скрипта его вызов почти ничем не отличается от вызова локальных процедур и методов.

Так как при вызове серверного скрипта текущая страница не покидается, то ее состояния сохраняется, а вместе с ней и состояние переключателей и глобальных переменных.

Что такое скриплет?

Скриплет является COM компонентой реализованной на XML (eXtensible Markup Language) и языке сценариев. XML используется для построения структуры скриплета (определения типа COM компоненты, ее методов, свойств, инициируемых событий, и т. д.), а код на языке сценариев обеспечивает функциональность.

Что касается скриплетов, то это полноценные COM компоненты и могут использоваться для решения широкого класса задач, как то:

доступ к базам данных; реализация бизнес-логики в многослойных архитектурах; транзакционные процессы; интерактивные эффекты в Web страницах, с использованием DHTML behavior.

CompuServe

Адрес в CompuServe - два числа, разделенные запятыми,

например, 1234,56789. В нотации Internet это выглядит

1234.56789@compuserve.com (точка вместо запятой).

Обратно письмо можно отправить по адресу

>INTERNET:пользователь@хост.домен

Дополнительные возможности

Рассмотрим пример, когда у скриплета есть свойство "цвет" и при изменении значения этого свойства хотелось бы, чтобы цвет компоненты тоже менялся. Безусловно, логичнее было бы реализовать метод при вызове которого цвет изменялся, но в общем случае предположим что компоненте необходимо реагировать немедленно при изменении каких-либо свойств.

В скриплете есть возможность описать некоторые функции, так что они выдают себя за свойства, и при изменении свойства выполняется код реализованный в этих функциях. Таких функций всего две: put и get. При изменении значения свойства вызывается функция put, а при получении значения - get.

В этом примере в переменных property1GetCount и property1PutCount хранят количество обращений к свойству property1 и его изменений. В функции public_put_property1 после того как новое значение установлено, компонента обновляет значения. В контейнере вы можете ссылаться на property1, как если бы это было обычное свойство.

Scriplet1.property1 = 'Another'; a = Scriplet1.property1;

С помощью put_ и get_ функций можно реализовать read-only и write-only свойства. Для создания read-only свойства описывается только функция get_, т. к. функции put_ нет, то значение изменено быть не может, аналогично с write-only.

Если вы пишите на JavaScript, то имеется альтернативная возможность описания интерфейса DHTML скриплета. При определении объекта public_description в скриплете, свойства и методы этого объекта являются свойствами и методами скриплета. При таком описании интерфейса префикс public_ не используется. Удобнее описать весь интерфейс скриплета в одном месте, как это предлагается с использованием объекта public_desription, чем рассеивать описание по всему коду скрипта. В дальнейшем предполагается реализовать подобный механизм и на VBScript.

В качетстве демонстрации можно присовокупить стандартные Microsoft примеры DHTML скриплетов. Я кинул пару самых простых и наглядных, можно также посмотреть у Microsoft на www.microsoft.com/scripting/.

Другие подтипы типа Application

Ожидается, что многие подтипы типа 'Application' будут введены в будущем. MIME-совместимые почтовые программы должны интерпретировать любой незнакомый им подтип как эквивалент 'application/octet-stream'.

Формальный синтаксис дла поля 'content-type' для данных типа 'application' дается следующим образом.

application_тип := "application" "/" application_подтип application_подтип := ("octet-stream" *stream_параметр) / "postscript" / расширение (непредопределенный под- тип) stream_параметр := (";" "type" "=" значение) / (";" "padding" "=" число_дополняющих_битов) число_дополняющих_битов := "0" / "1" / "2" / "3" / "4" / "5" / "6" / / "7"

Другие подтипы типа "multipart"

В будущем ожидается введение новых подтипов. Программистам рекомендуется интерпретировать незнакомые подтипы типа 'multipart' аналогично "multipart/mixed".

Формальный синтаксис поля Content-Type для данных типа "multipart":

multipart-тип := "multipart" "/" multipart-подтип ";" "boundary" "=" метка_границы multipart-подтип := "mixed" / "parallel" / "digest" / "alternative" / подтип-расширение

Файл active

Этот файл содержит список групп новостей, которые принимает локальный сервер. Содержимое файла считывается демоном innd при запуске, либо при получении этим демоном соответствующего указания от программы ctlinnd. Все статьи, опубликованные в группы новостей, которые не указаны в файле active отвергаются локальным сервером новостей. Строки в этом файле имеют следующий формат:

name himark lomark flags

Ниже описывается значение параметров:

name - имя группы новостей;

himark - номер самой новой статьи в данной группе новостей на локальном сервере. Это число увеличивается при получении новых статей;

lomark - номер самой старой статьи в данной группе новостей на локальном сервере. Это число изменяется в результате удаления старых статей на диске;

flags - это поле определяет один из шести возможных флагов:

y - для данной группы новостей разрешена локальная публикация;

n - для данной группы новостей не разрешена локальная публикация;

m - данная группа с ведущим (модератором) и все публикации должны быть одобрены ведущим;

j - статьи из данной группы новостей не храняться на локальном сервере (на самом деле они помещаются в группу junk, которая обязательно должна быть указана в файле active), а только передаются через него;

x - статьи не могут посылаться в данную группу новостей;

=news.group - статьи для данной группы новостей помещаются локально в группу news.group.

Основные операции, которые должен время от времени выполнять администратор включают в себя добавление новых групп, удаление ненужных групп, изменение флагов текущих групп новостей. Все эти операции должны отображать свои действия в файле active. Существует два основных подхода к выполнению указанных выше операций с группами новостей:

Первый подход - использование соответствующих подкоманд команды ctlinnd: "newgroup", "rmgroup" и "changegroup". Например, команда

ctlinnd newgroup relcom.humor y

добавляет группу новостей "relcom.humor" с флагом "y" (см.
выше), помещая соответствующие строки в файлах active и active.times. Файл active.times

содержит информацию о времени создания новой группы новостей (и о том, кто ее создал), которая используется некоторыми программами чтения новостей (Trumpet одна из них) для оповещения своих пользователей о наличии новых групп новостей.

Второй подход - непосредственное редактирование файла active, удобен для операций с большим количеством групп новостей (попробуйте удалить несколько десятков групп с помощью первого способа :-)), но имеет один недостаток: он не вносит автоматических изменений в файл active.times. Общая последовательность действий такова:

Приостановить работу демона innd (входящие соединения при этом не принимаются):

ctlinnd pause "edit active"

Отредактировать файл active. Например, при добавлении группы "relcom.humor", Вы должны добавить следующую строку в этот файл (флаг может быть и другим):

relcom.humor 0000000000 0000000001 y

Проверить корректность изменений в файле active, дав команду:

inncheck active

Считать в память новую копию файла active:

ctlinnd reload active "edit active"

Восстановить работу сервера innd:

ctlinnd go "edit active"

Файл expire.ctl

Этот файл считывается программой expire при запуске и определяет правила очистки дерева статей на локальном сервере (сроки хранения тел статей и их идентификаторов). В начале этого файла обязательно должна находится строка (причем, только одна), определяющая как долго хранить записи об идентификаторах статей в файле history, после того, как тело статьи удалено. Это позволяет отклонить эту статью, если поставщик новостей вновь предложит ее в определенный промежуток времени. Эта строка имеет следующий формат:

/remember/:время

где время - срок хранения в днях (можно указывать и дробную часть дня, наприме, /remember/:7.5

- семь с половиной дней), по истечении которого из системы удаляются идентификаторы старых статей. Последующие командные строки определяют когда нужно удалять из системы тела статей. Они имеют следующий формат:

pattern:modflag:keep:default:purge

Ниже описывается значение параметров:

pattern - образец для групп новостей в wildmat-формате, для которых применяется остаток данной строки;

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

М - то применять остаток данной строки только для групп с ведущим (moderated groups) из тех, которые соответствуют образцу pattern первого поля;

U - то применять остаток данной строки только для групп без ведущего (unmoderated groups) из тех, которые соответствуют образцу pattern первого поля;

A - то применять остаток данной строки для всех групп новостей, соответствущих образцу pattern

первого поля.

Следующие 3 поля определяют какое количество дней хранить тела статей на локальном сервере новостей:

keep - определяет минимальное число дней хранения тел статей на системе для определяемых групп новостей. Любая статья из этих групп не может хранится меньше указанного этим полем срока (если Expires-заголовок статьи имеет меньший срок, то будет использовано значение keep).

default - определяет число дней хранения для тех статей из определяемых групп, у которых отсутствует заголовок Expires.

purge - определяет максимальное число дней хранения тел статей на системе для определяемых групп новостей. Любая статья из этих групп не может хранится больше указанного этим полем срока (если Expires-заголовок статьи имеет больший срок, то будет использовано значение purge).

Помимо строки /remember/ Вы должны указать строку с pattern

'*' и modflag 'A'. Эта строка является строкой по умолчанию для срока хранения всех статей на системе. При этом она обязательно должна стоять раньше, чем строки с образцами для конкретных групп, поскольку этот файл проверяется программой expire до конца и последняя соответствующая группе новостей строка будет использована.

Например, мы хотим после удаления тела статьи хранить ее идентификатор в базе данных в течение 5-ти дней. Тела статей будут храниться на системе от 3-ех до 5-ти дней, за исключением локальных конференций, которые мы хотим хранить подольше (в течение 10-ти дней). Тогда наш файл будет выглядеть так:

/remember/:5 *:A:3:4:5 local*:A:10:10:10

Файл inn.conf

Файл inn.conf содержит различные глобальные параметры сервера новостей (имя сервера, имя домена) и параметры, используемые при формировании заголовков статей (начавших свой путешествие по Usenet с этого сервера). Все изменения, сделанные в этом файле считываются демоном innd только после перезагрузки сервера новостей. Строки в этом файле имеют следующий формат:

имя: [возможны пробелы] значение

Здесь имя - имя параметра, значение

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

fromhost - этот параметр используется при формировании заголовка From:, если того нет. Переменная окружения FROMHOST затирает это значение. По умолчанию, это полное доменное имя локальной машины.

moderatormailer - имя машины, содержащей псевдонимы для всех управляемых (moderated) групп. Этот параметр используется только если нужную информацию нельзя почерпнуть из файла moderators.

organization - определяет содержимое заголовка Organization:, если он пуст. Если определена переменная окружения ORGANIZATION, то она изменяет это значение.

pathhost - определяет, какое имя локального узла помещается в заголовок Path:. По умолчанию, это полное доменное имя

FidoNet

Адрес в FidoNet бывает двух типов: "поинт" и "нода".

Адрес "поинт" выглядит примерно так: 2:5020/12.345, где

2 - зона (в данном случае - Россия);

5020 - сеть (в Москве);

12 - машина;

345 - поинт;

Адрес "нода" имеет на один пункт меньше: 1:350/12

(Северная Америка).

Послать письмо можно по адресу

Imya_Familia@p345.f12.n5020.z2.gate.phantom.msk.su

(через московский шлюз) или соответственно

Fname_Lname@f12.n350.z1.fidonet.org (через шлюз в США).

Общение

Аналогично, но через другой шлюз:

Mirza_Kurbanov@p45.f123.n5020.z314.goldnet.squeen.msk.su.

Инсталляция пакета INN

Процесс инсталляции пакета INN идентичен для Unix-основанных систем, но каждая платформа имеет свои особенности инсталляции. Описанная ниже последовательность действий ориентирована на FreeBSD (пакет inn-1.7.2 ставился на FreeBSD-2.2.5).

Во-первых, Вам необходимо заполучить свеженький дистрибутив INN. Обратитесь на сервер ftp.isc.org и перейдите в каталог isc/inn. Выберите необходимый архив (например, ), перекачайте, декомпрессируйте и разархивируйте его, поместив результат в выбранный Вами каталог (в дальнейшем он упоминается как $inn).

Сменив текущий каталог на $inn, Вы обнаружите два файла формата nroff, использующие макрос -ms: Install.ms.1

и Install.ms.2. Это две части оффициального руководства по инсталляции InterNetNews.

Дайте команду

make Install.ms

При этом два файла объединяются в один - Install.ms

с правами доступа 444. Приведите этот файл в более читабельный вид (в частности, для просмотра с помощью more) командой:

nroff -ms Install.ms > Install

При возникновении проблем в инсталляции пакета необходимо обращаться за помощью к этому файлу.

Следующий этап процедуры инсталляции - редактирование главного файла конфигурации сonfig.data.

В каталоге $inn/sample-configs содержатся шаблоны файла config.data для различных платформ. Вам необходимо выбрать наиболее подходящий для Вас файл и скопировать его в $inn/config/config.data, например, для FreeBSD выполните следующие команды:

cd $inn cp sample-configs/config.data-FreeBSD-2.0 config/config.data

Теперь настала пора отредактировать сам файл config.data. INN получает из этого файла информацию о своей среде (т.е. где лежат компоненты, используемые INN).; Для пользователей FreeBSD надо подкорректировать опции для LIBS:

LIBS -lutil -lcrypt

Пакет поставляется с некоторыми perl-сценариями, требующими пакет языка perl версии не ниже, чем 5.001, так что Вам, возможно, придется установить новый пакет языка perl и прописать корректный путь к команде perl:

_PATH_PERL /usr/local/bin/perl

Подробное описание содержимого файла config.data

смотрите в файле Install.

Скомпилируйте все исходники:

cd $inn make all

Перед инсталляцией компонентов пакета необходимо создать каталоги, куда они будут помещены:

mkdir /usr/news /var/news /var/news/spool

Теперь можно инсталлировать компоненты пакета INN. Если Вы ставите пакет в первый раз на эту систему, то просто дайте команду:

make install

Если же Вы заменяете уже существующую систему INN, то рекомендуется инсталлировать отдельно программы и отдельно конфигурационные файлы и сценарии. Это позволит не затирать конфигурационные файлы текущей INN системы. Итак, сначала запустите сценарий:

makedirs.sh

Он создаст все остальные каталоги (ниже созданных командой mkdir на предыдущем этапе). Заметим, что команда make install вызывает этот сценарий сама. Теперь инсталлируйте программы и руководства (man'ы):

make update

При этом сценарии и конфигурационные файлы будут скопированы из каталога $inn/samples в каталог $inn/site. Если Вы хотите сохранить настройки предыдущей версии INN, затрите файлы из каталога $inn/site такими же файлами из старого программного обеспечения, после чего:

cd $inn/site make install

Запуск сценария:

$inn/BUILD

позволит создать файлы и history. После запуска сценария, он спросит, использовать ли с-версию subst (если она существует):

-- do you want to use it [y or n]? y

Далее он спросит построили ли Вы бинарники:

Have you already built the executables [y or n]? y

Затем он спросит существуют ли каталоги spool, etc

и т.д.:

Do the spool, etc., directories exist [y or n]? y

Следующим вопросом будет: желаете ли Вы продолжить инсталляцию:

Do you want to continue with the installation [y or n]? y

И, наконец, последний ворос: запускать ли subshell для редактирования конфигурационных файлов:

Start a subshell to edit the config files [y or n]? n

После завершения работы сценария проверьте, что владельцем файла active является пользователь news, группа news, права доступа на него 644, а если это не так (а практика показывает что в сценарии действительно что-то не так :-)), то исправьте это, дав команды

chmod 644 active chown news:news active

Сделайте почтовый псевдоним для пользователя news

в файле /etc/mail/aliases:

usenet: news

Дайте знать об этом sendmail, перестроив после редактирования файла базу псевдонимов:

/usr/bin/newaliases

INN оповещает о своей работе, используя систему syslog. Проверьте конфигурационный файл демона syslogd /etc/syslog.conf. Раскомментируйте в этом файле строки, содержащие news.crit, news.err, news.notice. После этого не забудьте создать соответствующие файлы в каталоге /var/log/news

(владелец - news, группа -news, права доступа - 664).

Заметим, что, если Ваш файл newsfeeds

не содержит строк с указанием "питающихся" у Вас сторон, кроме строки ME, то демон innd при запуске выдаст ошибку: "SERVER bad_newsfeeds no feeding sites". Для того, чтобы успокоить сервер, на начальной стадии Вы можете прописать холостой поток:

dummy-feed:!*::

Добавьте в .profileпользователя root пути поиска в новых каталогах:

PATH=$PATH:/usr/news/bin:/var/news

Для чтения руководств с помощью команды man, добавьте строку в файле /etc/manpath.config:

MANDATORY_MANPATH /usr/news/man

Поместите запуск демона innd в сценарий rc.local:

/usr/news/bin/rc.news > /dev/console

Проверьте наличие строки

DOINNWATCH=true

в файле rc.news. Это позволит использовать утилиту innwatch.ctl, которая "гасит" сервер новостей, когда Ваш диск переполнился и предотвращает крушение системы.

Перезагрузите машину и проверьте, работает ли демон innd. Во-первых, должен быть соответствующий процесс, запущенный пользователем news:

ps -U news | grep inn

Во-вторых, дав команду

telnet localhost nntp

Вы должны увидеть примерно следующее:

Trying 127.0.0.1 Connected to localhost.your.domain. Escape character is '^]'. 200 news.your.domain InterNetNews server INN 1.7.2 ready

Чтобы увидеть, какие команды понимает этот news-сервер, дайте команду help. Для возврата из сеанса telnet обратно в shell, дайте команду quit.

InterNet

Вы думаете, что если у Вас Internet-почта, то послать письмо

на другую машину с Internet-почтой всегда будет просто? Ну-ну!

Прямая нотация: юзер@хост.домен.

Обратная (bang'овая) нотация:

хост1.домен1!хост2.домен2!...!хостN.доменN!юзер.

Письмо сначала зайдет на хост1, потом на хост2 и так далее,

пока не попадет юзеру на последнем хосте. Если хост указывается

без домена, то это, как правило, означает передачу по UUCP.

Аналогично юзер%хост1.домен1%хост2.домен2%...@хостN.доменN

заставит письмо придти на хостN,... и наконец попадет юзеру

на хосте1.

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

не доходят; а в обратной нотации ведентся запись пути следования письма.

Не советую смешивать прямую и обратную нотацию - протоколы не определяют

приоритет операций.

Еще в адресе используют знаки "^", ":" и некоторые другие; когда я точно выясню, что они значат, сообщу "городу и миру". :-)

Использование скриплета

Для использования скриплета в HTML странице применяется таг <OBJECT>:

ID - имя компоненты, через которое можно доступаться до свойств и методов скриплета. В описанном выше примере это Scriplet1.

DATA - имя HTML файла содержащего описание скриплета, если файл расположен в другой директории, то указывается относительный путь.

TYPE - MIME тип объекта, в данном случае скриплет.

Обратите внимание, что в таге <OBJECT> не указан CLSID - Internet Explorer сам регистрирует компоненту, когда встречает скриплет, хотя при желании скриплет можно зарегистрировать в системе и указать его CLSID явным образом. Internet Explorer распознает скриплет по MIME типу "text/x-scriplet".

Функциональность скриплета может быть реализована на любых языках сценариев поддерживающих Microsoft ActiveX Scripting интерфейс. При описании скриплета могут использоваться несколько языков сценариев, в этом случае создается несколько блоков <script language= ...>.

Экспериментальные значения поля 'Content-Type'

Значение типа, начинающееся с "X-", считается частным, предназначенным для использования по договоренности между двумя или более почтовыми системами. Публично определенные (регестрированные) значения никогда не должны начинаться с префикса "X-".

В общем, использование X-типов верхнего уровня не рекомендуется. Производители почтового ПО должны по возможности обходиться использованием X-подтипов для предопределенных типов. Во многих случаях использование экспериментального подтипа более приемлимо, нежели типа верхнего уровня.

Как RS работает

RS реализован как библиотека функций, которые вызываются из клиентского скрипта при необходимости вызова серверного метода. При вызове серверного метода, запрос выделяется в прокси процесс, который запускается асинхронно в браузере (на данный момент прокси реализован как Java апплеты). Прокси процесс посылает запрос в ASP страницу, содержащую вызываемый метод. По клиентскому запросу сервер загружает ASP страницу, и специальная процедура посылает запрос необходимому методу. Если метод возвращает значение, то оно отсылается обратно в прокси процесс, который упаковывает его как объект - call объект - содержащий результат работы метода и другую полезную информацию.

Существует два варианте вызова серверных методов:

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

Как скриплет работает?

Скриплет технология состоит из:

Скриплет run-time (Scrobj.dll), в COM терминологии являющийся in - proc сервером для скриплетов. Interface handler, являющийся pre-compiled компонентой, реализующей различные COM интерфейсы. Разные interface handler ориентированы на работу с разными типами COM компонент.

Самые часто используемые interface handler включая COM Automation, Event и, DHTML Behavior interface handler уже встроены в скриплет run-time.

Вся сложность создания COM компонент, включая реализацию таких стандартных COM интерфейсов как IUnknown, встроена в interface handler. Скриплет содержит только код, обеспечивающий функциональность COM компоненты, и в сочетании с тем, что этот код реализуется на простом в изучении языке сценариев, скриплет - технология является самым простым и прозрачным способом создания COM компонент. Вы знаете, что компонента должна делать - вы создаете соответствующий скрипт, остальное забота run-time окружения. После создания скриплета вы можете использовать его как полноценную COM компоненту.

Как создавать скриплеты

Скриплет описывается в обычном HTML файле (*.htm, *.html). Как компонента, скриплет может иметь свойства и методы. Свойствами скриплета являются глобальные перемнные, методами функции и процедуры определненным образом описанные. Для создания общедоступного свойства к имени глобальной переменной прибавляется префикс public_. Для создания общедоступного метода префикс public_ прибавлятся к имени функции или процедуры. Любая глобальная переменная с этим префиксом становится public свойством скриплета, любая функция или процедура с этим префиксом становится его public методом. Рассмотрим простой пример, в котором описывается одно свойство property1 и один метод method1:

При вызове свойств и методов префикс public_ не включается. И обращение из контейнера будет выглядеть следующим образом:

Scriplet1.property1 = 'Another'; Scriplet1.method1(param);

Компоненты необходимые для Remote Scripting

Для использования RS необходимы следующие файлы в дополнении к вашим клиентским (*.htm) и серверным (*.asp) файлам:

RS.htm - Содержит методы которые вызываются из клиентского скрипта для инициализации RS, исполнения удаленных процедур, проверки состояние вызова и получение результатов работы. RS.asp - Содержит методы инициализации RS на сервере и вызова необходимых функций. Rsproxy.class - Содержит Java класс для апплета, который обеспечивает взаимодействие клиентской и серверной страницы.

Эти файлы работают как библиотеки, вы просто включаете необходимые файлы (Rs.htm или Rs.asp) в вашу клиентскую или серверную страницу, и вызываете необходимые серверные методы.

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

RS и безопасность

RS обеспечивает такой же уровень безопасности как Java апплеты и IFrames. По требованиям безопасности, серверные методы не могут принимать в качестве параметров структурированные данные (объекты или массивы). К тому же, удаленные процедуры должны выполняться на том же сервере, откуда была загружена страница.

Обеспечение RS с клиентской стороны

Для обеспечения RS с клиентской стороны необходимо:

включать файла Rs.htm в вашу клиентскую страницу; вызвать метод, который запускает Rsproxy апплет.

Необходимо создать пустой JavaScript блок, который ссылается на файл Rs.htm, как показано ниже:

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

Также из клиентской страницы необходимо выполнить вызов метода RSEnableRemoteScripting(). По умолчанию этот метод предполагает, что апплет Rsproxy.class находится в папке _ScriptLibrary, если это не так необходимо указать правильный путь в качестве параметра. Этот скрипт-блок должен располагаться в пределах тела документа, но после скрипт-блока ссылающегося на Rs.htm.

<body> <script language = "JavaScript"> RSEnableRemoteScripting("../_ScriptLibrary"); </script>

После создания функций и процедур необходимо объявить их серверными методами. Для этого создается объект public_description содержащий описание нужных функций и процедур. В следующем примере в качестве конструктора объекта public_description вызывается функция MyServerMethod():

<script languge = "JavaScript"> var public_description = new MyServerMethods();

В конструкторе сопоставляются имена вызываемых функций и имена серверных методов.

function constructor() { //for JavaScript methods this.methodName = functionName; //for VBScript methods this.methodName = Function('p1','p2','return functionName(p1,p2)') }

Где:

functionName - имя вызываемой процедуры или функции; methodName - внешнее имя серверного метода, непосредственно использующееся при вызове;

Note: Механизм объявления интерфейса посредством объекта public_description реализован только в JavaScript.

Следующий пример демонстрирует ASP страницу, в которой объявляется два серверных метода square и add:

<% RSDispatch %>  <script runat = server language = "JavaScript"> var public_description = new MyServerMethods();

function MyServerMethods() { this.square = squareNumber; this.add = Function( 'n1','n2','return addNumbers(n1,n2)' ); }

function squareNumber(numberToSquare){ return numberToSquare * numberToSquare; } </script> < script runat = server language ="VBScript"> Function addNumbers(num1, num2) addNumbers = CInt(num1) + CInt(num2) End Function </script>

Краткое описание работы системы INN

Во время загрузки системы в качестве пользователя root запускается сценарий rc.news

(хорошее место для запуска - файл /etc/rc.local). В результате чего выполняется демон innd

(посмотрите процесс командой ps -U news | grep inn). Эта программа прослушивает порт NNTP (TCP-port 119) на наличие входящих соединений. Если соединяются локальные клиенты для чтения новостей, то innd

передает дальнейшее управление демону nnrpd, вызывая его. Этот демон просматривает файл nnrp.access для определения прав доступа к локальной базе статей. Если соединяются поставщики новостей (они должны быть прописаны в файле hosts.nntp), то innd принимает статьи (просматривая файлы hosts.nntp и ) и размещает их на Вашем диске (по умолчанию в каталоге /var/news/spool/articles).

В функции innd не входит отсылка новостей с локальной машины, для этого предназначены другие программы. Как только статья получена от поставщиков, она распространяется на все NNTP-машины, которые подписаны на конкретную телеконференцию у данной машины. Конкретно, куда и каким образом статьи будут отправляться с локального сервера определяется в файле newsfeeds. Программа, отвечающая за отправку статей (например, nntpsend, nntplink, send-nntp

- программы транспортировки по NNTP, или sendbatch - программа транспортировки по UUCP) читает файл newsfeeds

и передает статьи в заданном направлении.

Если Вы используете nntpsend, то Вы должны отредактировать файл nntpsend.ctl (хотя все можно прописать в файле newsfeeds). Список статей на отправку записывается в файл, который обычно хранится в каталоге /var/news/spool/out.going. Имя этого файла, как правило, совпадает с именем NNTP-соседа, указанного в файле newsfeeds. Для того, чтобы в один "прекрасный" момент диск не переполнился, старые статьи надо удалять. Это делается с помощью сценария news.daily. Он вызывает программу expire, которая просматривает файл (в нем указывается срок хранения статей) для обнаружения и удаления статей с устекшим сроком хранения. Этот же сценарий предназначен для каждодневного отчета о работе INN.

Logging системы INN.

Итак, конфигурационные файлы отредактированы, система INN не обнаружила в них синтаксических ошибок, из cron'а вызываются периодические процессы системы INN, демон innd запущен. Естественное желание - убедиться, что все работает корректно. К счастью, система INN достаточно дружественная и извещает нас о своей работе (либо об ошибках, в результате которых она работать не может), используя стандартную в Unix-систему регистрации syslog. Кроме того, система INN поставляется с рядом сценариев, обобщающих информацию в log-файлах (и не только в них) и выводящих их в приятном для чтения виде. Наконец, обобщенная статистика может ежедневно отправляться по e-mail администратору сервера новостей. Об этом здесь и пойдет речь.

Посмотрев конфигурациооный файл /etc/syslog.confдемона syslogd, мы увидим куда идут данные регистрации ситемы INN. Напомню, что во время инсталляции INN мы раскомментировали в этом файле строки:

news.crit /var/log/news/news.crit news.err /var/log/news/news.err news.notice /var/log/news/news.notice

Затем создали соответствующие файлы (их владелец - news, группа - news) и перезапустили демон syslogd.

Наиболее разрастающийся из них - news.notice. Cюда пишет innd о соединении с ним удаленных NNTP-хостов, демон nnrpd записывает сюда информацию об активности клиентов, в этом же файле информируют о своей работе программы ctlinnd, innxmit, rnews и др.

Файл news.crit содержит сообщения о критических ошибках, требующих внимания от администратора сервера новостей. (Например, сервер INN не может открыть файл из-за неверных прав доступа; или здесь появится сообщение о гашении сервера с помощью ctlinnd и т.д.).

Файл news.err содержит сообщения о фатальных ошибках сервера. Вообще говоря трудно провести четкую границу между информацией об ошибках, записываемых в news.crit и news.err. (Syslogd зачастую записывает одинаковую информацию в оба файла).

Система INN имеет помимо log-файлов, поддерживаемых системой syslog, встроенные log-файлы - errlog и news (по-умолчанию они расположены в каталоге /var/log/news).

Файл errlog содержит стандартный вывод и стандартные ошибки любых программ, порождаемых демоном innd. В частности, при перезагрузке операционной системы в этом файле появится следующая строка:

INND exiting because of signal

Файл newsрегистрирует все статьи, поступающие к innd для обработки. Строки в этом файле имеют следующий формат:

mon dd hh:mm:ss.mmm flag feed Message-ID [reason] size site ...

Первые три поля определяют дату поступления (с точностью до миллисекунд) статьи к демону innd. Следующее поле - флаг, определяющий действие, выполненное innd с данной статьей. Возможны 4 флага:

"+" - статья успешно принята.

"-" - статья отвергнута по причине [reason]

(поле reason фигурирует только если статья отклонена).

"j" - статья успешно принята, но поскольку она из групп новостей, имеющих в файле active

флаг "j", она будет помещена в группу junk.

"c" - в этом случае прежде чем поступит сама статья будет принято cancel-сообщение.

Поле feed определяет от кого статья была получена демоном innd для дальнейшей обработки. Если это поле представляет IP-адресс 0.0.0.0, то статья получена локально (nnrpd принял ее от клиента).

Поле Message-ID определяет идентификатор данной статьи.

Если статья была отвергнута, то поле [reason]

определяет причину, по которой это было сделано. Причем, это поле будет последним в данной строке (поля size site ... отсутствуют).

Поле size определяет размер статьи в байтах.

Последнее поле site ... определяет список сторон, которым данная статья будет распространена (основываясь на файле newsfeeds).

Рассмотрим для примера фрагмент файла news:

Mar 28 06:06:20.340 + ace.domain.ru <6fgqr8$qun$1@simtel.ru> 27127 netlab Mar 28 06:06:21.278 - ace.domain.ru 437 Unwanted newsgroup "relcom.rec.puzzles" ...... Mar 31 11:31:43.818 + 0.0.0.0 <35209BDE.D94E6A66@kari.ru> 2140 ace netlab Mar 31 14:07:57.876 + 0.0.0.0 <01bd5c8c$e11b9520$8832e9c1@bsd.kari.ru> 479 ace

первая строка говорит, что от ace.domain.ru была принята статья (опубликованная на машине домена simtel.ru) размером 27127 байт и копия статьи поставлена в очередь на отправку стороне netlab. Вторая строка говорит, что машина ace.domain.ru послала нам статью из группы новостей relcom.rec.puzzles, на которую мы не подписывались, поэтому innd отверг ее с указанием причины: 437 Unwanted newsgroup "relcom.rec.puzzles". В последних двух строках статьи размером 2140 и 479 байт были опубликованы клиентами нашего сервера с локальной машины и с хоста bsd.kari.ru, используя nnrpd, и распространены на стороны ace, netlab и ace соответственно.

Помимо перечисленных выше файлов регистрации, ряд программ системы INN ведут собственные файлы регистрации (expire.log, send-uucp.log, nntpsend.log и др.).

Програама expire оповещает о проделанной ею работе через файл expire.log. Ниже приведен пример этого файла:

expire begin Sat Mar 28 04:06:34 MSK 1998: (-v1) Article lines processed 14581 Articles retained 12437 Entries expired 2144 Files unlinked 2854 Old entries dropped 408 Old entries retained 2967 expire end Sat Mar 28 04:09:21 MSK 1998

Первая и последняя строки обозначает временные границы работы программы expire -v1. Следующие строки означают, что программа expire прочитала в history-файле 14581 строк, из них оставлено 12437 строк (читай статей), т.е. удалено 2144 строки (на самом деле строка не удаляется, а "сокращается" до трех полей - message-id, дата прибытия статьи и значение заголовка Expire (либо ~, если заголовок отсутствует), поэтому в действительности - 2144 есть число удаленных тел статей). Значение Files unlinked (2854) определяет число удаленных файлов на диске; дело в том, что одна статья (одно тело) может быть опубликована в несколько групп (при этом для каждой группы создается свой файл), поэтому это значение может быть больше, нежели Entries expired. Последние два цифровых значения относятся к неполным строкам (из 3 полей), т.е. к message-id статей, тела которых уже удалены из системы.

Old enties dropped (408) - число удаленных строк для статей, тела которых уже были удалены. Old entries retained (2967) - число оставленных строк для статей, тела которых уже удалены (неполных строк).

Если Вы пользуетесь программой nntpsend для отправки статей к NNTP-соседям, то Вы обнаружите файл nntpsend.log, в который эта программа записывает информацию о своей работе. Например при сеансе отправки потока новостей к NNTP-соседу netlab при помощи nntpsend , файл nntpsend.log

пополнится примерно следующим:

nntpsend: [3560] start nntpsend: [3560] stop nntpsend: [3560:3611] begin netlab Wed Apr 1 11:43:37 MSD 1998 nntpsend: [3560:3611] innxmit -a netlab ... nntpsend: [3560:3611] end netlab Wed Apr 1 11:43:39 MSD 1998

Безусловно, регулярно просматривать кипу регистрационных файлов, да еще и в не совсем удобочитаемом формате - дело не из приятных и отнимает много времени. К счастью, необходимости в этом нет. Пакет INN включает ряд сценариев, обрабатывающих log-файлы и выдающих суммарную информацию в удобном виде.

Сценарий innstat выдает "фотоснимок" системы INN. Он показывает режим работы сервера, использование дискового пространства, статус всех log- и lock- файлов.

Perl-сценарий innlog.pl выдает статистику активности демонов innd и nnrpd , обобщая информацию в регистрационных файлах системы syslog. Обычно этот сценарий вызывается другим сценарием - scanlogs.

Сценарий scanlogs обобщает информацию, записываемую в log-файлы INN. По умолчанию, он также производит ротацию и очистку ряда регистрационных файлов. В каталоге /var/log/news/OLD содержатся компрессованные файлы, полученные в результате ротации (цикл ротации - 3). Обычно scanlogs

вызывается сценарием news.daily(который запускают обычно раз в сутки), поэтому в результате ротации файлов, у Вас на системе будет хранится регистрационная информация за последние трое суток плюс текущая информация.

По большому счету, Вам нет необходимости запускать перечисленные выше сценарии по отдельности. Запуская из cron'а ежедневно сценарий news.daily, администратор сервера новостей news (псевдоним usenet) будет ежедневно по почте получать полную статистику работы INN сервера, как суммарный итог работы этих сценариев.

Прежде чем разбираться, что же нам послал в письме news.daily, разберемся по шагам, что в действительности делает этот сценарий:

Сначала он формирует Subject для будущего письма по адресу usenet@this.news.server в следующем виде: this.news.server daily usenet report for [current data]

Вызывает сценарий innstat, который показывает статус innd (вывод команды ctlinnd mode), использование дискового пространства, размеры batch-, log- и lock-файлов в блоках по 512 байт (округление идет до следующего целого значения), а текущие соединения с сервером.

news.daily вызывает программу expire, которая сканирует файл history и основываясь на сроках хранения статей (прописанных в файле expire.ctl) удаляет старые статьи.

news.daily передает работу сценарию scanlogs, который выполняет следующее:

показывает критические ошибки от syslog (содержимое файла news.crit).

показывает фатальные ошибки от syslog (содержимое файла news.err).

показывает содержимое файла expire.log (о проделанной командой expire работе).

сканирует регистрационные файлы на наличие различных проблем относительно статей, которые были приняты или отправлены системой, а затем выводит для каждой категории по 20 верхних (по-умолчанию) элементов. В частности, будут выведены (если, конечно, есть)

20 сторон, отправлявших нам чаще всего (количество в первом столбце) статьи с ошибками;

20 сторон, посылавших нам чаще всего статьи из групп, на которые мы не подписывались;

20 наиболее частых из нежелательных распространений;

20 наиболее часто приходящих групп новостей, на которые мы не подписаны;

20 сторон из тех, которые наиболее часто пытались установить соединение по NNTP с нами, но не имели на то прав;

20 наиболее часто встречающихся основных проблем;

20 сторон посылавших нам чаще всего статьи с ошибочными заголовками.

scanlogs вызывает perl-сценарий innlog.pl, который обобщает syslog-информацию о работе innd и nnrpd

и выводит следующую статистику:

неизвестные для сценария вхождения в файле news;

команды, полученные демоном innd от ctlinnd;

группы новостей, созданные через ctlinnd;

группы новостей, удаленные через ctlinnd;

статистика о получении демоном innd статей (по системам и итоговая информация);

далее выводится различная innd статистика (об ошибочных ID статей, об ошибочных ihave- и sendme- сообщениях, об ошибочных командах, об отвергнутых из-за размера статей, и др.);

статистика об отправлении статей командой innfeed (если используется);

nntpd-статистика;

статистика об отправлении статей командой innxmit (по системам и итого);

попытки ( в том числе ошибочные) установления соединений для передачи статей другим системам (по системам и итого);

nntplink-статистика (если для отправки используется эта программа);

batcher-статистика;

rnews-статистика;

nnrp-статистика (статистика работы nnrp-клиентов по хостам и доменам, запросы на аутентификацию по пользователям, счетчики запросов статей по категориям и группам, ошибки при работе gethostbyaddr и др.);

mthreads-статистика (если используется).

после завершения работы сценария innlog.pl, scanlogsкомпрессует нужные файлы и производит их ротацию с циклом 3 (если у команды нет опции norotate), после чего возвращает управление работой сценарию news.daily;

news.daily снова вызывает сценарий innstat, который показывает статус innd после очистки. произведенной программой expire;

перенумерует файл active;

из временных файлов формирует окончательное почтовое сообщение для usenet;

и, наконец, завершает свою работу, формируя в каталоге /var/news/etc файл news.daily, в котором сообщает время завершения своей работы.

Copyright (C) by Yuri V. Savin, 1998.

MCIMail

Адрес в MCIMail - число, например, 123456.

В нотации Internet это выглядит 123456@mcimail.com.

Этот алгоритм разработан для представления

Этот алгоритм разработан для представления произвольных последовательностей байтов в форму, читаемую для человека. Кодирующий и декодирующий алгоритмы очень просты, но закодированные данные примерно на 33% больше, чем некодированные. этот метод идентичен тому, который используется в приложениях PEM (Privacy Enhanced Mail), описанной в RFC 1421 с одним отличием: base64 не приемлит встроенного "чистого" текста.

Base64 использует 65-символьный поднабор из US-ASCII, выделяя 6 бит на каждый печатный символ. (65-й символ "=" используется для обозначения функции спец. обработки).

ПРИМЕЧАНИЕ: этот поднабор имеет важное свойство: он идентичен всем версиям языковой кодировки ISO 646, включая US ASCII, а также всем версиям EBCDIC. Другие популярные механизмы кодирования (uuencode, base85 - часть уровня 2 PostScript) не разделяют этих свойств и поэтому не удовлетворяют требованиям переносимости для двоичных данных электронной почты.

Процесс кодирования преобразует 4 входных символа в виде 24-битной группы, обрабатывая их слева направо. Эти группы затем рассматриваются как 4 соединенные 6-битные группы, каждая из которых транслируется в одиночную цифру алфавита base64. При кодировании base64, входной поток байтов должен быть упорядочен старшими битами вперед.

Каждая 6-битная группа используется как индекс для массива 64-х печатных символов. Символ, на который указывает значение индекса, помещается в выходную строку. Эти символы выбраны так, чтобы быть универсально представимыми и исключают символы, имеющие специальное значение для SMTP-транспорта (".", CR, LF) и для синтаксиса вложенных тел MIME ("-").

Таблица 1: Алфавит Base64 Значение Код Значение Код Значение Код Значение Код 0 A 17 R 34 i 51 z 1 B 18 S 35 j 52 0 2 C 19 T 36 k 53 1 3 D 20 U 37 l 54 2 4 E 21 V 38 m 55 3 5 F 22 W 39 n 56 4 6 G 23 X 40 o 57 5 7 H 24 Y 41 p 58 6 8 I 25 Z 42 q 59 7 9 J 26 a 43 r 60 8 10 K 27 b 44 s 61 9 11 L 28 c 45 t 62 + 12 M 29 d 46 u 63 / 13 N 30 e 47 v 14 O 31 f 48 w = (заполнитель) 15 P 32 g 49 x 16 Q 33 h 50 y

Выходной поток ( закодированные бфайты) должен иметь длину строк не более 76 символов. Все признаки перевода строки и другие символы, отсутствующие в таблице 1, должны быть проигнорированы декодером base64. Среди данных в Base64 символы, не перечисленные в табл. 1, переводы строки и т.п. должны говорить об ошибке передачи данных, и, соответственно, почтовая программа должна оповестить пользователя о ней.

Если в хвосте потока кодируемых данных осталось меньше, чем 24 бита, справа добавляются нулевые биты до образования целого числа 6-битных групп. А до конца 24-битной группы остается от 0 до 3-х недостающих 6-битных групп, вместо каждой из которых ставится символ-заполнитель '='. Поскольку весь входной поток представляет собой целое число 8-битных групп (т.е., просто байтных значений), то возможны лишь следующие случаи: (1) входной поток как раз оканчивается 24-битной группой. В таком случае, выходной поток будет оканчиваться четырьмя символами Base64 без символа '='; (2) хвост входного потока имеет длину 8 бит. Тогда в конце выходного кода быдут два символа Base64, с добавлением двух символов '='; (3) хвост входного потока имеет длину 16 бит. Тогда в конце выходного будут стоять три символа Base64 и один символ '='.

Т.к. символ '=' является хвостовым заполнителем, его появление в теле письма может означать только то, что конец данных достигнут. Но такой гарантии нет, если число переданных битов кратно 24.

Любые бессмысленные последовательности в коде Base64 вроде "=====" должны быть игнорированы.

Если кодируемый текст не находится в канонической форме. то перед конвертацией в Base64 необходимо сначала все концы строк заменить стандартной последовательностью CRLF. Предпочтительнее эту функцию встроить в кодировщик Base64, нежели заставлять пользователя производить предварительную канонизацию текста другими средствами.

Нет нужды экранировать вложенные тела внутри многочастного тела (multipart) при кодировании его в Base64, так как в коде Base64 отсутствует символ '-'.

Механизм конвертации "Quoted-Printable"

Этот механизм предназначен для представления данных, в основном состоящих из байтов, соответствующих символам, имеющим изображение в символьном наборе ASCII. В результате данного кодирования все байты будут иметь такие значения, гарантированные от дальнейшей модификации почтовым транспортом. Если конвертируемые данные в основном представляют собой ASCII-текст, то конечная их форма остается узнаваемой и читаемой для человека. Тело, полностью состоящее из ASCII-символов, также может быть конвертироавано в Quoted-Printable, что гарантирует его содержимому целостность при прохождении через всякие шлюзы, в которых происходит языковая перекодировка символов или преобразование концов строк и т.д.

В Quoted-Printable байты должны быть рпедставлены в соответствии со следующими правилами:

ПРАВИЛО #1: (обычное 8-битное представление). Каждый байт, кроме тех, которые используются для обозначения конца строки, может быть представлен с помощью двух шестнадцатиричных цифр, предворяемых знаком "=". При написании шестнадцатиричных цифр с A по F должны использоваться заглавные буквы. Кроме тех случаев, когда нижеследующие правила позволяют альтернативное кодирование, данное правило является обязательным.

ПРАВИЛО #2: (Буквенное представление). Байты с десятичным значением с 33 по 60 и с 62 по 126 МОГУТ быть представлены ASCII-символами, соответствующими этим значениям (с '!' по '' по '~').

ПРАВИЛО #3: (Пробелы): Байты со значениями 9 и 32 МОГУТ быть

представлены как ASCII-символы "Табуляция" и "Пробел", но НЕ ДОЛЖНЫ быть представлены так в конце строки. Везде, где они представлены соответствующими ASCII-символами, за ними должен следовать символ, имеющий графическое изображение (печатный символ). В конце же строки символы табуляции и пробела должны быть представлены в соответствии с правилом #1, так как некоторые почтовые транспорты могут убирать пробелы в конце строки.

ПРАВИЛО #4: (Конец строки): Конец строки в тексте письма должен быть представлен (в соответствии с RFC 822) последовательностью CRLF.
Так как в каноническом представлении текста не требуется визуального отображения символов конца строки, в Quoted-Printable не используется видимых символов для обозначения конца строки. Для представления бинарных данных более предпочтительной является кодировка base64.

Необходимо заметить, что многие реализации почтовых программ могут кодировать по-своему. В частности, при представлеии текста в системах, использующих другие соглашения по обозначению конца строки (отличные от CRLF). Такие реализации недопустимы, и генерация концов строки должна быть стандартизована везде, чтобы не требовалось распознавать, используется ли какое-либо альтернативное представление.

ПРАВИЛО #5: (Мягкий конец строки): В соответствии с Quoted-Printable длина строки не должна превышать 76 символов. В противном случае используется 'мягкий' перевод строки, представимый знаком равенства. Например, если исходная строка имела вид:

Now's the time for all folk to come to the aid of their country.

то в Quoted-Printable encoding он может быть представлена следующим образом:

Now's the time = for all folk to come= to the aid of their country.

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

Поскольку символ дефиса ("-") представляется в Quoted-Printable в обычном виде, особую осторожность нужно соблюдать при заключении тела в Quoted-Printable в многочастное письмо, чтобы удостовериться, что граница этого включения не проявляется нигде внутри этого включения (лучше всего выбрать обозначение границы в виде последовательности символов "=_", которая никогда не появляется в теле, закодированном в Quoted-Printable. См. определение многочастного письма далее.)

ЗАМЕЧАНИЕ: Quoted-Printable представляет собой нечто вроде компромисса между читабельностью и сохранностью при пересылке. Тела в Quoted-Printable будут надежно защищены при прохождении многих почтовых шлюзов, но могут быть не очень хорошо переданы через некоторые шлюзы, использующие трансляцию в EBCDIC. (Теоретически, EBCDIC-шлюз должен кодировать тело из quoted-printable в base64 и затем декодировать обратно, но таких шлюзов пока не существует).

Единственный способ добится действительно надежной транспортировки через EBCDIC-шлюз - экранировать ASCII-символы

!"#$@[\]^`{|}~

в соответствии с правилом #1.

Так как данные в quoted-printable являются строчно-ориентированными, можно ожидать, что представление концов строки в Quoted-Printable будет изменено почтовым транспортом таким же образом, как и обычный текст может измениться при пересылке по Internet-почте между системами с разными соглашениями по представлению концов строки. Если подобные изменения могут нарушить целостность данных, то имеет смысл пользоваться кодировкой base64, а не Quoted-Printable.

Вниманию создателей ПО: Если двоичные данные пересылаются в Quoted-Printable, то надо соблюдать осторожность при кодировании символов CR и LF. В частности, последовательность CRLF должна быть представлена как "=0D=0A", в противном случае, если CRLF означает конец строки, то она может быть неверно интерпретирована в платформах с другими соглашениями по концу строки.

Синтаксис данных в quoted-printable описывается следующим образом:

quoted-printable := ([*(простой текст / ПРОБЕЛ / ТАБУЛЯЦИЯ) простой текст] ["="] CRLF) ; Максимальная длина строки - 76 символов, включая CRLF простой текст := байт /<любой ASCII-символ "=", ПРОБЕЛ или ТАБУЛЯЦИЯ>

; символы, не перечисленные в приложении B к RFC 1521 как безопас- ; ные для почты, также не рекомендуются к использованию байт := "=" 2(ФИФРА / "A" / "B" / "C" / "D" / "E" / "F") ; байт используется для символов > 127, =, ПРОБЕЛ, или ТАБУЛЯЦИЯ, ; и рекомендуется для представления любых символов, не перечислен- ; ных в приложении B к RFC 1521 как безопасные для почты

Multipart: общий синтаксис

Поле Content-Type многочастного письма требует одного параметра, "boundary", который определяет границы вложения. Границей является строка, состоящая из двух символов "-" (десятичный код 45) и значения параметра 'boundary' из поля заголовка Content-Type.

ЗАМЕЧАНИЕ: Два символа "-" используются для совместимости с более ранним методом вложения писем, описанным в RFC 934 и для облегчения поиска границ. Однако, многочастные письма MIME не полностью совместимы с RFC 934; в частности, они не подчиняются соглашению RFC 934 по экранированию строк символом "-", так как с каждым новым уровнем экранирования длина строк увеличивается. А поскольку SMTP-транспорты часто обрезают длинные строки, этот механизм становится неприменимым в случае многоуровневой структуры письма типа 'multipart'.

ВНИМАНИЮ ПРОИЗВОДИТЕЛЕЙ ПО: синтаксис параметров поля Content-Type таков, что зачастую необходимо значения границ в параметре 'boundary' заключать в кавычки. Это не всегда требуется, но никогда не повредит. Программистам следует изучить синтаксис внимательно, чтобы не допустить ошибок в поле Content-Type. Типичное поле Content-Type для типа 'multipart' может выглядеть следующим образом:

Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08jU534c0p

Но в следующем примере содержится ошибка:

Content-Type: multipart/mixed; boundary=gc0p4Jq0M:2Yt08jU534c0p

(из-за двоеточия), которая может быть исправлена следующим образом:

Content-Type: multipart/mixed; boundary="gc0p4Jq0M:2Yt08jU534c0p"

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

--gc0p4Jq0M:2Yt08jU534c0p

Нужно обратить внимание, что метка границы части письма должна располагаться в начале строки, то есть, сразу же после признака конца строки CRLF. Причем, последовательность CRLF полагается элементом метки границы, а не последним элементом тела предыдущей части (так как тело предыдущей части может неоканчиваться концом строки, что принципиально важно в случае бинарных данных.
Если же тело предыдущей части оканчивается концом строки, то метке границы соответственно должны предшествовать два конца строки). Сразу за меткой границы должен следовать конец строки (CRLF), или при отсутствии заголовка следующей части письма, два конца строки.

Метка границы не должна иметь длину более 70 символов, не считая два начальных дефиса.

Метка границы, следующая за последней частью письма, должна отличаться от предыдущих меток, чтобы показать, что далее не последует другой части письма. Отличие последней метки состоит в добавлении двух дефисов в конец:

--gc0p4Jq0M2Yt08jU534c0p--

Обычно оставляется пространство для дополнительной информации перед первой меткой границы и после последней. Обычно его следует оставлять пустым, и обработчики почты должны игнорировать все, что в этом пространстве содержится.

ЗАМЕЧАНИЕ: Эти области приамбулы и эпилога обычно не используются из-за отсутствия точной семантики для обработки этих областей почтовыми шлюзами, однако, многие программные MIME-продукты считают удобным помещать туда пояснительную информацию для получателей, которые пользуются до-MIME'овским ПО. По этой причине, MIME-совместимые программы должны игнорировать эти области.

ЗАМЕЧАНИЕ: Поскольку метки границы не должны появляться внутри тел частей письма, почтовая программа, создающая письмо, должна иметь алгоритм, позволяющий автоматически подобрать уникальную последовательность, не встречающуюся в теле ни одной из частей, либо имеющую минимальную вероятность появления, если данные предварительно не сканируются на наличие таковой.

В качестве простого примера предлагается двухчастное письмо, вторая часть которого оканчивается признаком конца строки, а первая нет:

From: Nathaniel Borenstein

To: Ned Freed

Subject: Sample message MIME-Version: 1.0 Content-type: multipart/mixed; boundary="simple boundary" Это приамбула. Должна быть игнорирована --simple boundary Это простой ASCII-текст. Он НЕ оканчивается признаком конца строки. --simple boundary Content-type: text/plain; charset=us-ascii Это простой ASCII-текст.

Он оканчивается признаком конца строки. --simple boundary-- Это эпилог. Тоже должен игнорироваться MIME-программами.

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

Использование типа 'multipart' в одночастном письме может быть полезно в некоторых контекстах и не запрещено.

Единственным обязательным параметром для типа 'multipart' является параметр 'boundary', состоящий из 1-70 символов без хвостовых пробелов (которые могут быть удалены в процессе пересылки, и тогда почтовая программа получателя не сможет разделить вложенные части).

граница := 0*69<символов границы> символ_границы_кроме_пробела символ границы := символ_границы_кроме_пробела / " " символ_границы_кроме_пробела := ЦИФРА / БУКВА ЛАТИНСКОГО АЛФАВИТА / "'" / "(" / ")" / "+" /"_" / "," / "-" / "." / "/" / ":" / "=" / "?"

Общий вид многочастного тела - следующий:

многочастное тело := приамбула вложения признак_конца эпилог вложение := разделитель часть_тела CRLF разделитель := "--" метка_границы CRLF ; метка границы должна браться из поля Content-Type. ; Не должно быть пробелов между "--" и меткой границы. признак конца := "--" метка_границы "--" CRLF ; Опять, без пробела перед "--", приамбула := игнорируемый текст эпилог := игнорируемый текст игнорируемый текст := *(*текст CRLF) часть_тела := <письмо RFC 822, со всеми необязательными полями заголовка>

ЗАМЕЧАННИЕ: В некоторых транспортах такие ограничения RFC 822, как использование тольеко печатных символов в теле, могут не действовать. Ослабления таких ограничений должны быть истолкованы как локальные расширения определения тела письма настолько, насколько они поддерживаются почтовым транспортом и адекватно документированы в поле заголовка Content-Transfer-Encoding.Однако, ни при каких обстоятельствах в заголовках как письма, так и его частей, не должно содержаться каких-либо символов, кроме US-ASCII.

Настройка системы INN

Итак, мы инсталлировали систему INN и запустили демон innd. Более того, мы не получили сообщений об ошибках и процесс innd выполняется на системе. Настала пора возложить на innd

реальные функции. Для этого нужно внести в конфигурационные файлы изменения, отражающие наши потребности. Для начала погасим демон innd

с помощью команды:

ctlinnd shutdown configure

Теперь мы смело можем править конфигурационные файлы пакета INN (главное, не пугаться их количества :-)). По умолчанию они находятся в каталоге /var/news/etc. Естественно, прежде чем редактировать файлы надо иметь представление о том, как функционирует пакет INN (Вы ведь прочитали ).

Попробуем выяснить, что нам может предложить провайдер (или любые хосты, которые согласны снабжать нас новостями). Для этого получим список новостей, на которые он подписан. Один из способов получения списка следующий. Воспользуемся командой пакета INN:

getlist -h newsserver.our.pro > active.provider

Созданный вышестоящей командой файл active.provider

содержит список групп новостей, на которые подписан наш провайдер. Выберем из этого списка те группы, на которые мы действительно хотим подписаться и пропишем их в нашем файле . Например, если Вы хотите подписаться на конференцию relcom.humor, добавьте в этот файл примерно следующее:

relcom.humor 0000000000 0000000001 y

Если Вы хотите принимать все (или почти все) группы новостей, на которые подписан Ваш провайдер, то файл active можно получить из active.provider, "прогнав" того через следующий сценарий (он обнуляет два средних поля каждой строки):

#!/bin/sh sed < active.provider > active \ -e 's/^$[^ ]*$ [0-9]* [0-9]* $[^ ]*$$/\1 0000000000 0000000000 \2/'

Наш файл active готов (он содержит строки для всех групп, которые поддерживает наш сервер), но надо сообщить и провайдеру о нашем выборе (чтобы он знал какие группы новостей ему нужно пересылать на наш хост).

Даже если провайдер пропишет нас в своей конфигурации сервера новостей, он не сможет скидывать нам новости по NNTP.
Мы должны дать ему разрешение на это. Для этого добавим строчку в файл hosts.nntp:

newsserver.our.provider:

Здесь надо заметить, что мы полагаемся на провайдера: мы знаем, что он будет снабжать нас только теми конференциями, о которых мы его попросили. Если же Вы не доверяете своим NNTP-соседям, то можно указать конкретно шаблон конференций, которые Вы принимаете на локальный диск от конкретного NNTP-соседа. Например, мы хотим принимать от newsserver.our.badprovider только relcom'овские группы новостей:

newsserver.our.badprovider::relcom.*

Отредактируем файл newsfeeds, указав всех NNTP-соседей, которых мы хотим снабжать статьями. Не забудем указать в этом файле своего провайдера. Ниже приведены два примера этого файла. В первом случае мы планируем снабжать статьями хост newsserver.our.provider по NNTP (используя программу nntpsend, о том как ее вызывать будет сказано ):

ME:*, !junk, !control*, !local*/!local:: newsserver.our.provider:*, !junk, !control*, !local*:Tf, Wnm:newsserver.our.provider

Во втором случае мы хотим снабжать этот же хост по UUCP (имя этой uucp-системы provider), используя программу sendbatch (опять же о том, как ее вызывать, будет сказано ):

ME:*, !junk, !control*, !local*/!local:: provider/newsserver.our.provider:*, !junk, !control*, !local*:Tf, Wnb:

Теперь назначим различные глобальные параметры сервера новостей (имя сервера, имя домена) и параметры, используемые при формировании заголовков статей, публикуемых у нас. Эта информация хранится в файле

Определимся теперь с клиентами нашего сервера новостей (хосты, которые через программу чтения новостей общаются с нашим сервером). Например, мы хотим ограничить пространство пользования ресурсами нашего сервера новостей нашей Интранет-сетью (192.168.111.0/255.255.255.0) и нашей внешней сетью (домен our.domain), причем пользователям этих сетей мы разрешаем и читать новости, и публиковать их на наш сервер. Ах, да, мы чуть не забыли о наших хороших партнерах из домена partner.domain (правда, им нечего делать в наших локальных конференциях).

Ну, а для остальных поместим первым правило, запрещающее все и вся. Для этого добавим строки в файл nnrp.access:

*:: -no- : -no- :!* 192.168.111.*:Read Post:::* *.our.domain:Read Post:::* *.partner.domain:Read Post:::*, !local*

Как только мы начнем получать статьи на локальный диск, надо будет следить за сроком их хранения на диске и удалять старые (диск же не резиновый :-)). К счастью, за нас это будет делать программа expire, а от нас требуется только дать ей соответствующие указания в файле (ну, и, конечно, запускать механизм очистки - об этом ). Мы должны указать в этом файле, во-первых - срок хранения идентификаторов статей в файле history (это делается для того, чтобы не принимать заново удаленные статьи), во-вторых - срок хранения самих тел статей. Пример ниже говорит о том, что запись об идентификаторе статей хранится в файле history 14 дней после удаления тела этих статей, тела статей из локальных телеконференций хранятся на системе от 5 до 7 дней (по умолчанию 6), а для всех остальных телеконференций тела хранятся от 3 до 5 дней (по умолчанию - 4 дня):

/remember/:14 *:A:3:4:5 local*:A:5:6:7

Заметим, что значение по умолчанию (образец '*') должно фигурировать раньше, чем строки для отдельных групп, поскольку применяется последнее соответствие образцу в первом поле.

Важным шагом после редактирования конфигурационных файлов является проверка корректности сделанных нами изменений. Система INN имеет ряд средств, помогающих нам в решении этой задачи. Вот некоторые из них:

Для поиска ошибок в файле newsfeeds можно дать следующую команду

innd -s

Например, если Вы получили в ответ следующее:

Found 1 errors --see syslog

то это значит, что командой обнаружена одна ошибка, о которой сообщается через syslog в файлах news.err и news.notice.

Для проверки файла на наличие неверных строк, можно дать следующую команду:

expire -n -x -t

Например, если Вы получили в ответ следующее:

/var/news/etc/active: line 5 wrong number of fields

то это значит, что Вы ошиблись с количеством полей в 5-той строке этого файла (их должно быть 4).

Однако, это не лучший способ проверки этого файла. В частности, expire не замечает отсутствие флага для группы новостей (в отличие от inncheck).

Итак, inncheck - perl-сценарий, предназначенный для проверки всех рассматриваемых нами конфигурационных файлов. Помимо проверки файлов на наличие синтаксических ошибок, он может осуществлять проверку прав доступа к файлам и их владельцев. Возвращаясь к примеру выше (отсутствие флага в конце строки файла active), inncheck

сообщит Вам об этой ошибке:

/var/news/etc/active:5: ends with whitespace

Запущенный без параметров, inncheck проверит синтаксис всех файлов (которые может проверить), с выводом на экран сообщений об ошибках. Если мы укажем опцию -v (verbose режим), то inncheck расскажет нам о том, что он просматривает. Мы можем ограничить работу inncheck проверкой синтаксиса конкретного файла, дав команду inncheck {файл}. Для того, чтобы проверить корректность прав доступа к файлам и корректность владельцев и групп файлов можно дать команду inncheck -perm. Ту же информацию, да еще и с указанием того, какие команды надо выполнить, чтобы устранить ошибки, дает команда

inncheck -f -perm

Последний шаг настройки - периодически запускать программу отправки статей с нашей машины, программу чистки каталога статей и обобщения log-файлов. Для этого отредактируем таблицу заданий пользователя news для демона cron:

crontab -u news -e

Ваш любимый редактор (определенный переменной окружения EDITOR) откроет файл /var/cron/tabs/news. Ежедневно в 4 часа утра мы будем запускать сценарий news.daily, в функции которого входит обобщение и ротация файлов регистрации, прогон программы expire и др. Далее, в 1 минуту и 28 минут каждого часа мы будем запускать программу nntpsend

для отправки потоков статей по NNTP нашим соседям.

0 4 * * * /usr/news/bin/news.daily > /dev/null 2>&1 & 1, 28 * * * * /usr/news/bin/nntpsend > /dev/null 2>&1 &

Наконец, если мы планируем отправлять потоки новостей по UUCP на UUCP-систему provider, то в 37 минут каждого часа из cron'a будем вызывать программу sendbatch:

37 * * * * /usr/news/bin/sendbatch -c provider > /dev/null 2>&1 &

Ну что ж, теперь можно запустить демон innd (rc.news

поможет нам в этом) и насладиться его работой!

Необязательное поле Content-Description

Возможность ассоциировать некоторую описательную информацию с данными часто очень желательна. например, может быть полезным описать тело, содержащее графическое изображение, как "a picture of the Space Shuttle Endeavor." Этот текст и может быть помещен в поле заголовка Content-Description.

описание := "Content-Description" ":" *текст

Описание должно иметь языковую кодировку US-ASCII, хотя механизм, определенный в RFC-1522 может быть использован для не-US-ASCII значений.

Необязательное поле Content-ID

При создании почтового агента верхнего уровня может быть желательно позволить одному телу иметь ссылку на другое. Для этого поля могут быть помечены с помощью поля заголовка "Content-ID", синтаксически идентичного полю "Message-ID":

идентификатор := "Content-ID" ":" идентификатор письма

Как и значения поля Message-ID, значения поля Content-ID должны быть абсолютно уникальными (для всего мира).

Такой идентификатор может быть использован для идентификации тела письма (части письма) в нескольких контекстах, в часности, для кэширования данных, указываемых с помощью механизма message/external-body. Хотя поле Content-ID является необязательным в общем случае, его использование необходимо в реализациях, генерирующих данные, имеющие дополнительный тип "message/external-body" (поле Content-type). Каждое тело такого типа должно обязательно иметь в своем заголовке поле Content-ID для обеспечения ссылки на такие данные.

Значение поля Content-ID имеет специальную семантику в случае типа multipart/alternative. (См. соотв. пункт).

Обработка ошибок

При вызове удаленных серверных методов могут происходить разного рода ошибки: синтаксические ошибки, ошибки времени исполнения, ошибки при вызове методов. RS имеет механизмы оповещения о происходящих ошибках.

Реакция на ошибки немного различается при синхронном и асинхронном вызове. Если при синхронном вызове произошла ошибка, механизм обработки ошибок выбрасывает сообщение об ошибке в окно браузера. Текстом сообщения является message свойство call объекта. Если ошибка происходит при асинхронном вызове, то вы можете ее перехватить, определяя error callback функцию.

При асинхронном вызове передаете ссылку на error callback функцию в качестве параметра. Т. к. передается указатель на функцию, то при таком вызове можно использовать только JavaScript. Примеры с использованием объекта ссылающегося на серверную страницу и без:

callObject = ASPObject.methodName(p1, p2[,...], callbackFunction, errorCallbackFunction, context)

callobject = RSExecute(url, methodName, p1, p2[,...], callbackFunction, errorCallbackFunction, context)

При синхронном и асинхронном вызове вы можете получать информацию о происходящих ошибках через свойства call объекта. Если вы определяете error callback функцию, то call объект передается в качестве параметра как и в случае callback функции. Полезные свойства call объекта при обработке ошибочных ситуаций:

status содержит -1 если при удаленном вызове произошла ошибка. data содержит необработанное сообщение переданное сервером в XML формате. Это лучший источник информации при отладке, т. к. он содержит полную информацию об ошибке. message содержит сообщение об ошибке созданное прокси процессом. Сообщение об ошибке в message не обязательно совпадает с содержанием свойства data. Например, если ASP страница содержит ошибку, детальная информация об ошибке содержится в data, а message только содержит сообщение о том, что при выполнение произошла ошибка.

Следующий пример демонстрирует работу error callback функции в клиентском скрипте.

function showErrors(co){ msg = "The raw data returned by the remote method call is " msg = msg + co.data alert(msg); msg = "The following error occurred during the " msg = msg + co.context msg = msg + " remote scripting call:\n" msg = msg + co.message; alert(msg); } </script>

Общая схема настройки сервера новостей

Выделить место на диске для хранения дерева статей Usenet (в INN /var/news/spool).

Инсталлировать один из пакетов программ телеконференций (например, INN).

Найти поставщика новостей и выяснить имя сервера поставщика.

Сообщить поставщику имя своего сервера новостей и список телеконференций, которые Вы хотели бы получать.

Внести всю необходимую информацию в конфигурационные файлы.

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

Это еще не все. Структуру надо иногда очищать. Для этого из демона cron необходимо запускать сценарии сопровождения и очистки новостей.

Основной подтип 'Application/Octet-Stream'

Используется для обозначения того, что тело содержит бинарные данные. Набор возможных параметров включает следующие (но не ограничивается ими):

TYPE -- обобщенный тип или категория двоичных данных, эта информация больше предназначена для получателя, чем для автоматической обработки.

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

Дополнительный параметр, "conversions", определенный в [RFC-1341], был исключен в последствии.

В RFC 1341 также определен параметр "NAME", указывающего имя файла, которое должно быть использовано при сохранении данных на диск. Но он опять же был отменен в ожидании введения отдельного поля заголовка Content-Disposition, которое будет определено в ближайшем будущем.

Рекомендуемое действие для почтовой программы, получившей почту типа application/octet-stream, - просто предложить записать данные в файл без какого-либо преобразования, или. возможно, произвести его в соответствии с указанием пользователя.

Для уменьшения опасности передачи вирусных и других намеренно разрушающих систему программ по почте, строго рекомендуется, чтобы почтовая программа получателя не производила запуск программы, заданной в параметре поля "Content-Type" (например, в параметре "interpreter="), использующей в качестве входных данных тело письма.

Основной подтип 'message/rfc822'

Этот подтип указывает, что тело письма содержит вложенное письмо в стандарте RFC 822, однако, в отличие от заголовка RFC 822 верхнего уровня, для каждой части, являющейся письмом RFC 822, не требуется наличия полей "From", "Subject" и, по крайней мере, одного поля "To".

Не смотря на использование числа "822", тело, имеющее подтип 'message/rfc822', может включать дополнительную информацию в соответствии со стандартом MIME. Другими словами, письмо 'message/rfc822' может быть MIME-письмом.

Основной подтип "multipart/mixed"

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

От автора

Уважаемый Читатель,

Предоставляемая Вашему вниманию брошюра содержит описание

программного пакета NCSA Telnet, ориентированное на рядового

пользователя сети Internet. В нем отсутствуют сведения о некоторых сложных

командах пакета, а также о выборе конфигурации NCSA Telnet,

поскольку это входит в компетенцию обслуживающего сеть персонала.

Если у Вас все же возникнут какие-либо проблемы, обратитесь к

администратору Вашей сети или напишите письмо по адресу:

Содержание


/////






/////




/////






























/////

/////




/////








/////




/////

Введение

I Обзор

Данное введение содержит обзор характеристик и возможностей

NSCA Telnet. Объясняется организация и назначение данного описания, а также объясняется используемые в нем обозначения.

II NCSA Telnet

Пакет NCSA Telnet Версия 2.3 для персонального компьютера предоставляет интерактивный доступ с компьютера IBM PC или совместимого

с ним к telnet серверам в сети TCP/IP. NCSA Telnet является реализацией стандартного пакета DARPA Telnet, к которому добавлены некоторые функции, ориентированные на использование вычислительной мощности персонального компьютера.

III Специальные функции

Специальные возможности пакета NCSA Telnet для персонального компьютера

эмуляция VT100

поддержка Вашего принтера при эмуляции VT100

одновременная работа со многими компьютерами

возможность передачи текста с экрана на диск персонального

компьютера или принтер

сервер передачи FTP (стандарт FTP)

сервер удаленного копирования (rcp) для применения на других

UNIX хостах

возможность использовать все преимущества цветов на экране

персонального компьютера

совместимость с программами Topview/Windows

эмуляция Tektronix 4014

дополнительные возможности, такие как lpr, lpq, lprm, rexec,

rsh, finger, setclock (совместимые с утилитами UNIX)

поиск имени домена

необязательное использование RARP и Bootp для определения IP

адреса Вашего компьютера

поддержка протокола Linemode

обратная прокрутка с поддержкой мыши

возможность вырезки и вставки текста (между сессиями)

переназначение клавиш

переадресация вывода текста

улучшенная передача сообщений telnet на экран дисплея

возможность копирования с дисплея в файл на диске

IV Требования

Для применения NCSA Telnet следует иметь следующую технику:

IBM PC, PC/XT, PC/AT, IBM PS/2 модели 30 или совместимые с ними,

имеющие один из следующих Ethernet адаптеров:

Appletalk Card

DecNet Card

3COM 3C501 Etherlink

3COM 3C503

3COM 3C505

AT&T Starlan 10

Western Digital WD8003EB

MICOM NI5210

Ungermann-Bass PC-NIC (аналог адаптера IBM Baseband)

Western Digital WD8003E EtherCard PLUS

IBM PS/2 моделей 50,60 или 80, либо совместимые с ними, имеющие

один из следующих адаптеров:

Ungermann-Bass NICps/2

3COM 3C523 Etherlink/MC

Western Digital WD8003A

Следующие адаптеры, работающие с пакетными драйверами:

3COM карты 3C501, 3C503, 3C505, 3C507 и 3C523

Любая ARCnet карта серии SMC

Любая карта AT&T Ethernet или StarLAN

Пакетный LAN адаптер D-Link Systems' DE-600

Эмулирующий драйвер в NetWare IPX

BICC Data Networks' ISOLAN

Apple Computer's LocalTalk PC Card

Sun/TOPS (Sitka) FlashCard

Эмулирующий драйвер в NetBIOS

NCR's ET-105B

Карты NE1000, NE2000 и их клоны

Racal-InterLan's NI5010, NI5210 и NI9210

Ungermann-Bass's NIC и NICps/2

все карты моделей Western Digital

минимум 384k памяти

Ethernet или Thin Ethernet связь PC с другими компьютерами

Чтобы использовать NCSA Telnet, Вы должны иметь следующее

программное обеспечение:

PC-DOS или MS-DOS версии 2.0 или последующих

стандартный текстовой редактор

V Содержание руководства

Это описание разбито на следующие главы:

описывает, как запустить

NCSA Telnet, как открыть и закрыть соединение между Вашим

персональным компьютером и другим хостом.

содержит описание возможностей NCSA Telnet по управлению множественными сессиями. Содержит также описание эмуляции стандартных VT100 ключей, ключей, используемых для общих операций редактирования,

применение файла перехватов.

содержит описание деталей управления сессиями. Обсуждаются опции меню параметров, возможности оболочки DOS и некоторые дополнительные функции.

содержит детальное описание некоторых полезных

программ, которые Вы можете использовать вместе с NCSA Telnet.

описывает процедуры по переносу файлов

между PC и компьютером, с которым установлено Telnet соединение.

VI Форма предоставления сервиса telnet

Пример предоставления сервиса

C:\>telnet имя_компьютера [имя_компьютера]

National Center for Supercomputing Applications

NCSA Telnet for the PC version 2.2

(c) Copyright 1987,1988 Board of Trustees of the University of

Illinois

ALT-H presents a summary of special keys

4.2 BSD UNIX (newton)

login:

Пояснения к синтаксису команд

ALT-key	Нажать и удерживать ALT, затем нажать указанную клавишу key. После этого отпустить обе клавиши одновременно.
variable	Не следует непосредственно вводить variable. Эта запись всего лишь означает, что вместо variable, набирая команду, Вы ставите некий текст. Другими словами, это переменная. Она зависит от компьютера и будет меняться в зависимости от имени файла, имени машины и т.д.
	Не вводить это многоточие. Оно указывает лишь на то, что Вы можете ввести дополнительную информацию, аналогичную той, которая была введена перед многоточием.
	Не следует при наборе команды вводить эти квадратные скобки. Текст или команда, помещенные между ними, являются необязательными и должны вводиться только в определенных случаях.

Pagers

Идентефикатором пейджера является его НОМЕР.

РадиоПейдж

rpg@demos.su, Subject: НОМЕР.

VessoLink

pager@vessolink.su, v1#НОМЕР в первой строке письма.

Национальная Пейджинговая Система "Континенталь"

pНОМЕР@conpage.msk.ru.

АльфаКом

pager@cea.su, Subject: НОМЕР.a.

Пакет NCSA Telnet

Радик Усманов

Март, 1995 г.

Реферат:

Описание программного пакета NCSA Telnet,

ориентированное на рядового пользователя сети Internet.

Пакет предназначен для работы в режиме удаленного терминала на компьютерах,

подключенных к сети.