CloudServices/Notifications/Meetings/Research

From MozillaWiki
Jump to: navigation, search

XMPP over Bosh

Overview

    • each http body contains a <body/> wrapper
    • requests sent over a single persistent http connection using http pipelining in order to maximize throughput
    • can't use Chunked Transfer Coding due to potential buffering issues
    • clients include can HTTP Accept-Encoding header and in that case, the Connection manager will include the HTTP Content-Encoding header and compress the body accordingly.
    • make use of HTTP connection sharing at the risk of having packets from different session then the current one, slightly delayed.


<body/> wrapper

    • qualified by 'http://jabber.org/protocol/httpbind' namespace
    • cannot contain: Partial XML elements, XML comments, XML processing instructions, Internal or external DTD subsets, Internal or external entity references

Initiating a BOSH Session

Session Creation

     POST /webclient HTTP/1.1
     Host: httpcm.example.com
     Accept-Encoding: gzip, deflate
     Content-Type: text/xml; charset=utf-8
     Content-Length: 104

     <body content='text/xml; charset=utf-8'
           from='user@example.com'
           hold='1'
           rid='1573741820'
           to='example.com'
           route='xmpp:example.com:9999'
           ver='1.6'
           wait='60'
           ack='1'
           xml:lang='en'
           xmlns='http://jabber.org/protocol/httpbind'/>


  • Parameters
    • Wait - longest amount of time where the connection manager allowed to wait before responding.
    • Hold - number of requests to keep waiting at any given time.
    • POLLING IS NOT RECOMMENDED AS IT WILL RESULT IN LOW THROUGHPUT
    • may need to also include a 'route' parameter if the session is across multiple severs
    • from attribute can also be included if this information is meaningful
    • the ack parameter is also optional and if included, ack will become meaningful.

Session Creation Response

     HTTP/1.1 200 OK
     Content-Type: text/xml; charset=utf-8
     Content-Length: 128

     <body wait='60'
           inactivity='30'
           polling='5'
           requests='2'
           hold='1'
           ack='1573741820'
           accept='deflate,gzip'
           maxpause='120'
           sid='SomeSID'
           charsets='ISO_8859-1 ISO-2022-JP'
           ver='1.6'
           from='example.com'
           xmlns='http://jabber.org/protocol/httpbind'/>
  • This would be generated by the connection manager which in return would associate a session with a particular connection.
    • polling - shortest allowable polling interval. no empty requests more often then needed
    • inactivity - enables the client to ensure that the periods no requests pending are never too long.
    • requests - simultaneous requests

XML Payload

   POST /webclient HTTP/1.1
   Host: httpcm.example.com
   Accept-Encoding: gzip, deflate
   Content-Type: text/xml; charset=utf-8
   Content-Length: 188

   <body rid='1249243562'
         sid='SomeSID'
         xmlns='http://jabber.org/protocol/httpbind'>

         <message to='contact@example.com' xmlns='jabber:client'>
            <body>Good morning!</body>
         </message>
        
         <message to='friend@example.com'  xmlns='jabber:client'>
            <body>Hey, what's up?</body>
         </message>
   </body>
  • Couple of things to note
    • content first forwarded to a content manager
    • content manager should wait for server delivery before sending an HTTP response but should not go above the delay set by the parameters.
    • in order to respect all the requirements, if no payload is available for delivery, an empty body needs to be delivered.
    • if the client really wants, it can send empty body requests in order to poll the connection manager (this way, the request is handled first come first served)
    • json messages can also be sent
    • the client must also respect the inactivity restraint. if it has nothing to ask the connection manager, it needs to send an empty request. violate the constraints and you're CUT!
    • if the connection manager violates the inactivity restraint, the client can send back an ack request with the last request ID it has received, prompting the connection manager for a response.
    • if a client is making too many requests and no pause/disconnect requests are amongst them, the client will be CUT due to spam with a response of privacy violation.

Additions to Facilitate XMPP

Additions to the <body/> wrapper

  • all bodies in this protocol have a stream stanza containing the message.
  • This protocol asks that you ignore the TLS (transport layer security) since this will be negotiated at the HTTP layer.
  • A restart request from the client will assume that all other open connections have terminated and the connection manager will be responsible for shutting them down.
  • The client can then bind again using the required protocols.
  • Remote - stream - error returns if there is some sort of issue, where the type of message is termination.
  • If the receiver is unavailable and the server requests an attendance, connection manager must drop the request entirely, and when a message stanza is receiver, an error stream should be returned.

Active MQ

Javascript + JMS.

AMQP

  • RabbitMQ the de facto implementation of an AMQP message broker
    • Scalable (can create clusters of nodes)
    • 4 Primitives:
      • Message
      • Queue - stores messages (used as a client delivery queue)
      • Exchange - routes messages to queues via bindings (1 exchange per user)
      • Binding - specifies which messages that arrive at an exchange are sent to a queue, specified on a per-queue basis (binding for each of a user's clients)
    • Authenticates using SASL PLAIN authentication mechanism

Server-side

  • Can choose from multiple python client libraries for communicating with broker (e.g. pika)
  • Simple to set up a publish/subscribe framework

Client-side

  • JavaScript client node-amqp makes it easy to subscribe to a queue and register an async callback (and was worked on by Shaver!)

XMPP vs AMQP

XMPP

  • Strengths
    1. Presence
    2. Quick
    3. Queue Like (store "offline chat")
    4. Feedback and control
    5. Explicit identities
  • Weaksauce
    1. Manage relationships
    2. Presence updates -> large overhead
    3. REST bridge
    4. File transfers are an "extension" to protocol

AMQP

  • Strengths
    1. No roster (queues)
    2. Security inside broker
    3. 1:1 communication
    4. 1:many communication
    5. File transfer on wire
    6. Plug-in architecture allows extensibility
  • Weaksauce
    1. No presence API
    2. User IDs/passwords must be stored with the broker, instead of doing a separate authentication mechanism LDAP authentication possible with plug-in

Others

Some others possible technologies:

  • Jabber Long Polling
Retrieved from "https://wiki.mozilla.org/index.php?title=CloudServices/Notifications/Meetings/Research&oldid=765677"