RFC: 3920
Оригинал: Extensible Messaging and Presence Protocol (XMPP): Core
Другие версии: RFC 6120
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: Семенов Юрий Алексеевич

RFC 3920, Страница 32 из 63

8.3. Протокол

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

  1. Исходный сервер устанавливает ТСР-соединение с принимающим сервером.

  2. Исходный сервер посылает заголовок потока принимающему серверу:

    <stream:stream
        xmlns:stream='http://etherx.jabber.org/streams'
        xmlns='jabber:server'
        xmlns:db='jabber:server:dialback'>

    Заметим: атрибуты 'to' и 'from' являются опционными для элемента корневого потока. Включение декларации пространства имен xmlns:db с приведенным именем указывает принимающему серверу, что исходный сервер поддерживает dialback. Если имя пространства имен некорректно, тогда принимающий сервер должен сформировать ошибку потока <invalid-namespace/> и завершить XML-поток, а также разорвать TCP-соединение.

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

    <stream:stream
        xmlns:stream='http://etherx.jabber.org/streams'
        xmlns='jabber:server'
        xmlns:db='jabber:server:dialback'
        id='457F9224A0...'>

    Заметим: Если имя пространства имен некорректно, тогда исходный сервер должен сформировать ошибку потока <invalid-namespace/>, прервать поток и разорвать TCP-соединение. Принимающий сервер должен ответить, но может молча завершить XML-поток, в зависимости от принятой политики безопасности; однако, если принимающий сервер хочет продолжить, он должен послать исходному серверу заголовок потока.

  4. Исходный сервер посылает ключ dialback принимающему серверу:

    <db:result
        to='Receiving Server'
        from='Originating Server'>
      98AF014EDC0...
    </db:result>

    Замечание: Этот ключ не просматривается принимающим сервером, так как он не хранит информацию об исходном сервере по завершении сессии. Ключ, генерируемый исходным сервером, должен базироваться частично на значении ID, предоставленном принимающим сервером на предыдущем шаге, а также частично на секретном ключе, совместно используемом исходным и управляющим серверами. Если значение адреса 'to' не соответствует имени машины, распознанному принимающим сервером, тогда последний должен генерировать сообщение ошибки потока <host-unknown/> и прерывать XML-поток. Если значение адреса 'from' соответствует домену, с которым принимающий сервер уже установил соединение, тогда он должен поддерживать существующее соединение до тех пор, пока не будет установлено новое соединение. Кроме того, принимающий сервер может сформировать сообщение об ошибке потока <not-authorized/> для нового соединения и затем прервать XML-поток и его TCP-соединение, связанные с новым запросом.

  5. Принимающий сервер устанавливает TCP-соединение с доменным именем, представленным исходным сервером, как результ установления соединения с управляющим сервером.

  6. Принимающий сервер посылает заголовок потока управляющему серверу:

    <stream:stream
        xmlns:stream='http://etherx.jabber.org/streams'
        xmlns='jabber:server'
        xmlns:db='jabber:server:dialback'>

    Замечание: атрибуты 'to' и 'from' являются опционными для элемента корневого потока. Если имя пространства имен некорректно, тогда управляющий сервер должен генерировать сообщение ошибки потока <invalid-namespace/> и прерывать XML-поток и TCP-соединение.

  7. Управляющий сервер посылает заголовок потока принимающему серверу:

    <stream:stream
        xmlns:stream='http://etherx.jabber.org/streams'
        xmlns='jabber:server'
        xmlns:db='jabber:server:dialback'
        id='1251A342B...'>

    Замечание: Если имя пространства имен некорректно, тогда принимающий сервер должен сформировать сообщение ошибки потока <invalid-namespace/> и прервать XML-поток и соответствующее TCP-соединение между ним и сервером управления. Если ошибка потока случится между принимающим и управляющим серверами, тогда принимающий сервер должен сформировать сообщение об ошибке потока <remote-connection-failed/> и прервать поток и ТСР-соединение с исходным сервером.

  8. Принимающий сервер посылает управляющему серверу запрос верификации ключа:

    <db:verify
        from='Receiving Server'
        to='Originating Server'
        id='457F9224A0...'>
      98AF014EDC0...
    </db:verify>

    Замечание: Здесь уже получены имена машин, оригинальный идентификатор из заголовка потока принимающего сервера исходному серверу на шаге 3, и ключ, который исходный сервер послал принимающему серверу на шаге 4. На основе этой информации, а также на секретном, совместно используемом ключе сети управляющего сервера ключ верифицируется. Для генерации ключа может использоваться любой метод верификации. Если значение адреса 'to' не соответствует имени машины, выявленному управляющим сервером, тогда управляющий сервер должен сформировать сообщение об ошибке потока <host-unknown/> и разорвать XML-поток и ТСР-соединение. Если значение адреса 'from' не соответствует имени машины, представленному принимающим сервером при открытии TCP-соединения, тогда управляющий сервер должен сформировать ошибку потока <invalid-from/>.

  9. Управляющий сервер проверяет, является ли ключ корректным:

    <db:verify
        from='Originating Server'
        to='Receiving Server'
        type='valid'
        id='457F9224A0...'/>

    или

    <db:verify
        from='Originating Server'
        to='Receiving Server'
        type='invalid'
        id='457F9224A0...'/>

    Замечание: Если ID не соответствует тому, который предложен принимающим сервером на шаге 3, тогда принимающий сервер должен сгенерировать ошибку потока <invalid-id/> и прервать XML-поток и соответствующее TCP-соединение. Если значение адреса 'to' не соответствует имени машины, распознанному принимающим сервером, тогда принимающий сервер должен выработать ошибку потока <host-unknown/> и разорвать TCP-соединение. Если значение адреса 'from' не соответствует имени машины, представленному исходным сервером при открытии TCP-соединения, тогда принимающий сервер должен выработать ошибку потока <invalid-from/> и разорвать TCP-соединение. После возвращения флага верификации принимающему серверу, управляющий сервер должен прервать поток между ними.

  10. Принимающий сервер информирует исходный сервер о результате:

    <db:result
        from='Receiving Server'
        to='Originating Server'
        type='valid'/>

    Замечание: В этой точке, соединение либо верифицировано type='valid', либо объявлено некорректным. Если соединение некорректно, принимающий сервер должен прервать XML-поток и разорвать TCP-соединение. Если соединение верифицировано, исходный сервер начинает посылать данные, которые читаются принимающим сервером; перед этим все XML-строфы, посланные принимающему серверу должны быть молча отброшены.

Страница 32 из 63

2007 - 2022 © Русские переводы RFC, IETF, ISOC.