Студентам СПбГУАП

5.1. Связываемые узлы.

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

Связываемыми узлами являются следующие:

• Background
• Fog
• NavigationInfo
• Viewpoint

5.1.1.Связывающийся стек.

Браузер поддерживает 4 структуры для внутренних работ, каждая для своего типа связываемых узлов. Они называются связывающими стеками. Когда браузером анализируется VRML файл, первый узел соответствующего типа помещен в верхнюю часть стека, который соответствует его типу. Последующие узлы добавляются в нижнюю часть стека. Текущий связанный узел (то есть тот, который является активным) – это тот, который находится в верхней части стека (остальные узлы не активны). Как только мир загружен, мы можем управлять стеком при помощи некоторого набора событий.

5.1.2. Связывание узлов.

Все связываемые узлы имеют 2 события – set_bind eventIn и isBound eventOut. У обоих значения типа SFBOOL. Когда событие set_bind со значением TRUE посылается узлу, этот узел перемещается в верхнюю часть стека, и становится связанным узлом. Затем этот узел пошлет событие isBound со значением TRUE. Узел, который был в верхней части стека, посылает isBound=FALSE в этот же момент. Здесь есть одно исключение – если узел уже в верхней части стека, ничего не случается, и никакие события не посылаются.

Если Вы посылаете set_bind=FALSE к узлу, это удаляет его из стека навсегда. Если это связанный узел, то посылается isBound=FALSE, и следующий узел в стеке делается связанным узлам. Если нет, узел просто удаляется, и никаких событий не посылается. Если послать событие set_bind узлу, который был удален из стека, то ничего не произойдет.

Событие bindTime – здесь посылается время, когда узел становится связанным, или перестает быть связанным.

5.1.3. Использование связывания.

Теперь, когда известно, как использовать связывание, что можно сделать полезного? Можно менять фон и стили тумана. Также, используя различные узлы NavigationInfo, можно изменять размеры аватара пользователя, менять тип навигации, и т.д.

Однако, наиболее полезный узел – Viewpoint. Если связать пользователя с точкой наблюдения, он будет перемещаться туда немедленно в стиле, определенном в узле (поле jump).  Таким образом, можно получить сценарии перемещения пользователя во всем мире, связывая пользователя с различными точками

6.1. Спецэффекты.

6.1.1. Background (Фон).

Полный синтаксис узла:

Background {

eventIn         SFBool          set_bind

exposedField    MFFloat         groundAngle             []

exposedField    MFColor         groundColor             []

exposedField    MFString        backUrl                 []

exposedField    MFString        bottomUrl               []

exposedField    MFString        frontUrl                []

exposedField    MFString        leftUrl                 []

exposedField    MFString        rightUrl                []

exposedField    MFString        topUrl                  []

exposedField    MFFloat         skyAngle                []

exposedField    MFColor         skyColor                [0 0 0]

eventOut        SFBool          isBound

}

Узел Background применяется обычно в двух вариантах:

1) Приписывается цвет угловым интервалам на сфере бесконечного радиуса, и этим цветом заливаются концентрические сферические кольца.

Background {

eventIn         SFBool          set_bind

exposedField    MFFloat         groundAngle             []

exposedField    MFColor         groundColor             []

exposedField    MFFloat         skyAngle                []

exposedField    MFColor         skyColor                [0 0 0]

eventOut        SFBool          isBound

}

Назначение полей:

• set_bind – см. раздел 5.1.
• skyAngle – здесь перечисляются углы внутри сферы (их количество на 1 меньше, чем количество цветов в skyColor), определяющие сферические кольца. Диапазон изменения углов от 0 до Pi, 0 соответствует верхней точке сферы.
• skyColor – последовательно определяются цвета, в которые будут покрашены сферические кольца. Первый цвет соответствует верхней точке сферы, остальные цвета соответствуют кольцам, определенным в skyAngle. Цвета между кольцами линейно интерполируются (если в браузере MS VRML Viewer 2.1 включен режим High Color).
• groundAngle – то же, что и skyAngle, только диапазон изменения углов от 0 до Pi/2, где 0 соответствует нижней точке сферы.
• groundColor – то же, что и skyColor, но для groundAngle.
• isBound – см. раздел 5.1.

Для определения всех сферических колец  и соответствующих им цветов можно пользоваться только параметрами skyColor и skyAngle за счет диапазона изменения углов.

Пример (файл 6-1-1.wrl): иллюстрирует смену фона (сфера бесконечного радиуса) при нажатии на TouchSensor.

#VRML V2.0 utf8

Background

{

skyAngle [1.57,3.14]

skyColor [0 1 0,0 0 1,0 1 0]

}

DEF BK Background

{

skyAngle [1.57,3.14]

skyColor [1 0 0,0 1 0,1 0 0]

}

# красный куб, к которому прикреплен TouchSensor

Transform

{

translation 0 3 5

children [

DEF TS TouchSensor

{

}

Shape {

appearance Appearance {

material Material {

diffuseColor 1 0 0

}

}

geometry Box {

}

}

]

}

# Камера

Viewpoint

{

position 0 7.5 -3

orientation 0.2 1 0.2 3.14

description “Камера”

}

# по нажатию на TouchSensor BK перемещается в вершину

# связывающего стека

ROUTE TS.isActive TO BK.set_bind

2) Куб бесконечного объема, внутри которого находится пользователь, покрывается изнутри

7.1. Script (Скрипт, сценарий).

Полный синтаксис узла:

Script {

exposedField    MFString        url                     []

field           SFBool          directOutput            FALSE

field           SFBool          mustEvaluate            FALSE

а также любые из следующих полей:

eventIn         Type            name

field           Type            name                    default

eventOut        Type            name

}

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

Мы перечисляем набор полей, входных и выходных событий, которые мы бы хотели определить. Поле типа exposedField мы определить не можем.

Назначение полей:

• url – здесь определяется сценарий (программа).

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

1)      можно использовать откомпилированную программу на Java; в этом случае в поле url указывается название внешнего файла.

например:

url ”abc.class”

2)      можно использовать код, написанный на языке JavaScript из внешнего файла (с расширением .js).

например:

url ”abc.js”

3)      можно включать код, написанный на языке JavaScript,  непосредственно в поле url.

например:

url ”javascript:

…

<программа>

…

”

• mustEvalute – если значение этого поля = TRUE, то посланные узлу события обрабатываются в первую очередь. При значении этого поля равном FALSE, если появляется несколько событий одновременно, браузер строит все появившиеся события в очередь, и обрабатывает в той последовательности, которую сочтет наиболее эффективной.
• directOutput – если значение этого поля = TRUE,  то браузер для данного узла игнорирует цепочку событий, и помещает значения непосредственно в поля тех узлов, которые доступны узлу Script.

При написании программы в поле URL основной задачей является связь входных событий узла Script с выходными. Эта программа состоит из функций, каждая из которых вызывается в определенный момент времени. Функции, соответствующие именам входных событий, определенных в узле, вызываются при появлении этих событий. Функция initialize() вызывается, как только завершается загрузка мира. Когда завершается работа со сценой, вызывается функция shutdown(). Функция eventProcessed() вызывается после обработки ряда событий (как часто будет вызываться эта функция, определяется браузером). Чтобы послать исходящее событие из узла Script, нужно присвоить в программе значение для имени этого события.

Например:

Script {

eventIn SFTime touchTime_f   # определяем

eventIn SFTime touchTime_b   # 2 входящих события

field SFInt32 number 10      # определяем переменную number

# с начальным значением 10

eventOut SFInt32 output      # определяем одно выходящее событие

url “javascript:

# эта функция вызывается сразу после завершения загрузки сцены

function initialize() {

output = 0;

out_light=FALSE;

}

# эта функция вызывается при

ОСОБЕННОСТИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ
В БЕСПРОВОДНЫХ СЕТЯХ
Введение
Основными требованиями, предъявляемыми к безопасности информации в любой системе, являются:
1) доступность – возможность работы пользователя с устройством
и предотвращение DoS&атак, т. е. необходимо предусмотреть защиту
от возможностей организации несанкционированных воздействий на
устройство, приводящих к его отказу в обслуживании легальных
пользователей сети;
2) конфиденциальность – защита передаваемой информации от ее
несанкционированного прочтения;
3) аутентичность – возможность для устройств сети определить
источник принимаемой информации;
4) целостность – защита передаваемой информации от несанкционированного изменения;
5) неотрицаемость – необходимость исключить возможность отказа от переданной информации.
Следует отметить, что в теории информационной безопасности хорошо известны криптографические примитивы, способные обеспечить
решение большинства из перечисленных требований [1]. Одним из
основных элементов всех криптографических методов является
ключ. Именно система выбора, распределения и использования ключа является основной особенностью защиты информации в беспроводных сетях. Во многом это связано с ограниченностью вычислительных ресурсов устройств, используемых в беспроводных сетях и,
соответственно, с приоритетом симметричных систем криптографической защиты информации.

Основные варианты схем управления ключами
Возможные подходы к решению задачи распределения и управления
ключами в беспроводных сетях можно представить следующей схемой
(рис. 1). Вторая классификационная схема (рис. 2) определяет возможные подходы к схемам распределения ключей в зависимости от наличия
или отсутствия инфраструктуры в беспроводной сети. Для нас в данном случае наибольший интерес представляют беспроводные сети, у которых отсутствует инфраструктура. Рассмотрим более подробно возможные варианты схем управления ключами.
1. Демонстративная аутентификация [2, 3] предполагает наличие
некоторого физически защищенного секретного канала между отдельными пользователями сети, например визуального или звукового. Информация, передаваемая по такому каналу, должна быть доступна лишь
ограниченному кругу легитимных пользователей. Одним из хорошо
известных вариантов демонстративной аутентификации является выдача общего предварительного ключа для участников совещания, написанного на доске в помещении, где проводится совещание.
2. Схемы с предварительным распределением ключей [4–8] предполагают наличие некоторого специального устройства, обеспечивающего создание и предварительную выдачу парных ключей для всех участников сети. При этом могут использоваться схемы, построенные на