Базовые семантические модули
После того как мы прошли авторизацию, разберем основные базовые семантические модули XML-строф реализованных в протоколе, их довольно немного:
<Presence> - презентационные данные, определяют статусное состояние, видимость пользователей и управление подпиской.
<Message> - собственно сами сообщения переданные или принятые пользователем.
<IQ> - Info Query, данные информационных запросов, включают в себя сами запросы, а также результаты выполнения. Данные запросы позволяют Jabber-клиентам обменивается различными данными между собой. Информационное наполнение запроса и ответа определено в пространстве имен дочернего элемента. Дополнительные расширения протокола (XEP - XMPP Extension Protocol) очень сильно используют <iq> запросы. Подробнее об них я расскажу далее.
Отправка и прием сообщений <Message>
Прием и отправка сообщений осуществляется через XML-строфу <MESSAGE>. Так как в Jabber-е предусмотрены разные типы сообщений, то для их разграничений предусмотрен атрибут type содержащий информацию о типе сообщения.
Типы сообщений могут быть следующие:
chat - Одиночное сообщение от клиента к клиенту.
error - Сообщение об ошибке. Произошедшая ошибка связанна с предыдущим, посланным одиночным сообщением.
groupchat - Групповой чат. Данное сообщение пришло с группового чата, действующего по признаку "Одно сообщение - многим получателям".
headline - Системное сообщение, автоматически генерируется различными сервисами для шировещательной рассылки (новости, спорт, RSS-каналы и пр.) Отвечать на такие сообщение не нужно, да и не зачем.
normal - одиночное сообщение, посылаемое вне контекста взаимно-однозначного сеанса связи или группового чата. То есть это такое сообщение, на которое пользователь может дать ответ, не учитывая хронологии сеанса связи.
Дочерние элементы
У XML-строфы <Message> могут быть следующие дочерние элементы, определенные пространством имен 'jabber:client' или 'jabber:server'. По умолчанию за этими элементами зарезервировано пространство имен 'jabber:client'. Если <Message> имеет тип error то обработка такого сообщения идет в соответствии с RFC 3920 XMPP-Core.
Элемент строфы <Message> может содержать любой из следующих дочерних элементов без явного объявления пространства имен:
Код:
<subject/>, <body/>, <thread/>.
Где элемент <body> - является телом сообщения. В значении элемента содержится сам текст сообщения, предварительно перекодированный из-за ограничений XML. Элемент может содержать атрибут 'xml:lang' содержащий язык сообщения. В <Message> могут быть включены множественные экземпляры элементов <Body>, но только при условии, что каждый экземпляр обладает атрибутом 'xml:lang' с отличным языковым значением.
Например:
Код:
<message type="chat" to="получатель"
id="идентификатор"
from="отправитель">
<body>Текст (тело) сообщения</body>
</message>
Элемент <Subject> определяет тему сообщения. На него действуют те-же правила, что и для <Body>. Множественные экземпляры <Body> могут быть включены для расширения и дополнения смежных тем, но при условии, что каждый экземпляр обладает атрибутом 'xml:lang' с отличным языковым значением.
Элемент <thread> cлужит для обеспечения хронологии сеанса. Значение <thread> элемента сгенерированного отправителем должно быть послано назад в любых ответах. Этот элемент является дополнительным и обычно не используется для обмена сообщениями между пользователями. Используется он в сеансах связи. Более подробно можно прочитать о нем в RFC 3921.
Перекодировка символов текста
Поскольку символы "<" и ">" используются для обозначения самих XML тегов, то их вставка в текст сообщения недопустима (за исключением случая, когда вставлен символ ">", но никакой тег не был открыт). Поэтому для корректного формирования XML следующие символы должны быть заменены в теле сообщения при отправке оного и соответственно обратно возвращены при приеме:
Код:
"<" в "<"
">" в ">".
Таким образом, чтобы написать "2>1", нужно написать "2>1". То же самое касается и знака "&" - он заменяется "&". Также рекомендуется заменять и кавычки (хотя в большинстве случаев они хорошо распознаются и без этого). Эквивалент двойных кавычек - """
Статусы, состояния, информация о присутствии, управление подпиской <Presence>
Прием и отправка статусных сообщений, а также информации о видимости контактов и подписки на сообщения от них, осуществляется через XML-строфу <Presence>.
Атрибут type строфы <Presence> является дополнительным.
Строфа, которая не обладает атрибутом type, используется Jabber-ом, для сообщений о присутствии контакта в сети Jabber и указывает на то, что данный контакт находится в сети (онлайне) и доступен для коммуникации.
Если атрибут type присутствет в строфе <Presence>, то он управляет подпиской на сообщения и смену статусов другого контакта (объекта). Аналог подписки в IM-сетях является прохождение авторизации в ICQ.
Если атрибут включен, то он должен содержать иметь одно из следующих значений:,
unavailable - Сигнализирует, что данный контакт, больше не доступен для коммуникаций. Фактически контакт вышел в оффлайн.
subscribe - Запрос на подписку (авторизацию) от другого контакта.
subscribed - Информирует о том, что контакт разрешил авторизацию.
unsubscribe - Отправитель аннулирует подписку.
unsubscribed - Запрос на аннулирование подписки (отозвание авторизации) от другого контакта.
probe - Запрос о текущем присутствии контакта только сервером от имени пользователя.
error - Ошибка, произошедшая при доставки предыдущих данных. Обработка такого сообщения идет в соответствии с RFC 3920 XMPP-Core.
Например, запрос на подписку от контакта
ivanov@jabber.ru для нашего контакта может выглядеть так:
Код:
<presence to="delphi-test@jabber.ru" type="subscribe"
from="ivanov@jabber.ru"/>
</presence>
Разрешение авторизации в ответ :
Код:
<presence to="ivanov@jabber.ru" type="subscribed"/>
А запрет (отказ) вот так:
Код:
<presence to="ivanov@jabber.ru" type="unsubscribed"/>
Дочерние элементы
XML-строфа <Presence> может содержать следующие дочерние элементы, определенные пространством имен 'jabber:client' или 'jabber:server': <show>, <status>, <priority>. По умолчанию за этими элементами зарезервировано пространство имен 'jabber:client'. Если <Message> имеет тип error то обработка такого сообщения идет в соответствии с RFC 3920 XMPP-Core.
Элемент <show> определяет статус контакта и может иметь следующие значения:
away - Отошел,
chat - Готов чатится (В сети),
dnd - Занят,
xa - Недоступен
Пустой элемент <show/> определяет статус контакта " В сети ".
Элемент <status> определяет статусное сообщение. Значением элемента является строка с текстом сообщения, например:
Код:
<presence>
<status>Смотрю фильм</status>
</presence>
Необязательный элемент <priority> определяет приоритет уровня ресурса. Значением элемента является число от -128 до 127.
Информационные запросы <IQ>
Информационные запросы <IQ> разделяются на стандартные, определенные пространством имен 'jabber:client' или 'jabber:server', обеспечивающие базовые функциональные возможности и расширенные.
Расширенные запросы, определенные дополнительными пространствами имен, описаны в различных дополнениях к протоколу XMPP.
Пространство имен расширенных запросов, может содержать любое значение, кроме зарезервированных следующих пространств имен: "jabber:client", "jabber:server" или "http://etherx.jabber.org/streams". Такое расширение позволяет придать протоколу XMPP дополнительную функциональность и гибкость. Таким образом, расширенный информационный запрос <IQ> может содержать один или более дополнительных дочерних элементов, определяющих информационное наполнение, которое расширяет значение данного запроса. Это кардинальное отличие от стандартного информационного запроса.
Стандартный запрос не может содержать, дочерние элементы, кроме элемента <error>. Наличие данного элемента в запросе показывает наличие ошибки.
Поддержка любого расширенного пространства имен является дополнительной возможностью со стороны клиента. Если клиент не понимает такое пространство имен, то есть фактически не поддерживает данное расширение, то он должен проигнорировать данный пакет. Более подробно вы можете прочитать об этом в RFC 3921.
Структурная схема обмена информационными запросами:
Код:
Запрос Ответ
---------- ----------
/ /
/ <iq type='get' id='1'> /
/ ------------------------> /
/ /
/ <iq type='result' id='1'> /
/ <------------------------ /
/ /
/ <iq type='set' id='2'> /
/ ------------------------> /
/ /
/ <iq type='error' id='2'> /
/ <------------------------ /
/ /
Как мы видим, на структурной схеме обмен между клиентами происходит по такому алгоритму. Запрашивающая сторона посылает <IQ> запрос с атрибутом type равным значению "get". Данный атрибут на принимающей стороне говорит клиенту, что вы должны предоставить информацию по данному запросу (для расширенных запросов при условии, что он поддерживается клиентом). Принимающая сторона отправляет ответ с атрибутом с атрибутом type равным значению "result".
Это первый вариант обмена. Существует и второй, когда запрашивающая сторона информирует принимающую о каком-то изменении, для этого она отправляет запрос с атрибутом type равным значению "set". Данное значение атрибута говорит о том, что принимающая сторона должна обработать присланные данные. Если принимающая сторона не может по каким-либо причинам обработать присланные данные, то в ответ она посылает строфу <IQ> с атрибутом type равным значению "error" информируя запрашивающую сторону о невозможности обработки. Если принимающая сторона корректно обработала запрос c атрибутом "set" то она возвращает ответ с атрибутом равным значению "result".
Пример расширенного запроса определяющий информацию об использованном клиенте (XEP-0092 Software Version):
Запрос:
Код:
<iq from='delphi-test2@jabber.ru/QIP'
to='delphi-test@jabber.ru/тестовая'
xml:lang='ru' type='get' id='qip_30'>
<query xmlns='jabber:iq:version'/>
</iq>
Ответ:
Код:
<iq type='result' to='delphi-test2@jabber.ru/QIP'
from='delphi-test@jabber.ru/тестовая'
id='qip_30'>
<query xmlns='jabber:iq:version'>
<name>Мой клиент</name>
<version>0.5.0.1</version>
</query>
</iq>