< CloudServices | Notifications | Meetings(Redirected from Services/Notifications/Meetings/Research)
- 1 XMPP over Bosh
- 2 AMQP
- 3 XMPP vs AMQP
- 4 Others
XMPP over Bosh
- 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.
- 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
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' email@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'/>
- 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
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 firstname.lastname@example.org' xmlns='jabber:client'> <body>Good morning!</body> </message> <message email@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.
- RabbitMQ the de facto implementation of an AMQP message broker
- Scalable (can create clusters of nodes)
- 4 Primitives:
- 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
- Can choose from multiple python client libraries for communicating with broker (e.g. pika)
- Simple to set up a publish/subscribe framework
XMPP vs AMQP
- Queue Like (store "offline chat")
- Feedback and control
- Explicit identities
- Manage relationships
- Presence updates -> large overhead
- REST bridge
- File transfers are an "extension" to protocol
- No roster (queues)
- Security inside broker
- 1:1 communication
- 1:many communication
- File transfer on wire
- Plug-in architecture allows extensibility
- No presence API
User IDs/passwords must be stored with the broker, instead of doing a separate authentication mechanismLDAP authentication possible with plug-in
Some others possible technologies:
- Jabber Long Polling