CloudServices/Notifications/Meetings/Research

From MozillaWiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

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"