Version 1 (modified by oubiwann, 11 years ago) (diff)


XMPP Server Architecture

These notes were taken from chat on #twisted with ralphm, metajack, glyph, radix, and oubiwann.

Server design usually goes like this:

  • there is a router which accepts component connections and moves stnazas between them
  • there is a c2s component which accepts client connections and stanzas and sends them to a session manager
  • a session manager componetn implements most of the xmpp stanzas rules
  • and an s2s component would handle traffic that can't be routed internally
  • and then additional components can also play for doing dedicated tasks like a muc component (e.g., that is part of the server) or a pubsub component

Key Points:

  • the "router" is an application-agnostic process
  • Twisted should support all components running in a single process as well as components distributed over multiple processes/machines
  • a session manager handles the route rules for your client connection and keeps track of presence and contact lists; usually the session manager is extend to support various server features, like private xml storage, privacy lists, etc

What is in Twisted right now is:

  • support for XML stream. You can use this to initiate connections, or accept them, and do stuff with incoming Stanzas
  • a client connector
  • a component connector

What other work has been done:

  • to do XML streams, Xish implements a dom that handles streaming xml and XMPPs perculiarities with regard to serialization and namespaces and a way to subscribe to specific stanzas using XPath like queries
  • support for 'subprotocols', which hopes to abstract implementing a particular extension protocol in one container
  • s2s dialback in a branch
  • basic router code which is a generialized xmlstream
  • started on c2s (server side) but got stuck on implementing a session manager
  • a beginning of the presence handling

All we are missing for a super complete component/service setup in twisted is s2s support