Changes between Version 1 and Version 2 of XMPPServerArchitecture

09/03/2008 02:34:33 PM (11 years ago)



  • XMPPServerArchitecture

    v1 v2  
    11= XMPP Server Architecture  =
    3 ''These notes were taken from chat on #twisted with ralphm, metajack, glyph, radix, and oubiwann.''
     3''These notes were taken from chat on #twisted with ralphm, metajack, glyph, radix, and oubiwann. See the [wiki:XMPPIRCTranscript20080903 raw transcript] for more details.''
    55Server design usually goes like this:
    66 * there is a router which accepts component connections and moves stnazas between them
    77 * there is a c2s component which accepts client connections and stanzas and sends them to a session manager
    8  * a session manager componetn implements most of the xmpp stanzas rules
     8 * a session manager component implements most of the xmpp stanzas rules
    99 * and an s2s component would handle traffic that can't be routed internally
    1010 * 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
     12Common XMPP Server Architecture:
     13 * typical xmpp server design has been to build a core router that other parts of the server connect to over xmpp to form one 'server'
     14 * where the "router" is an application-agnostic process with no routing rules except to/from (see it as service bus with no business logic)
     16What to build, whose end result would be a simple jabber server suitable for small use:
     17 1. a router is step one
     18 1. xep 114
     19 1. c2s/sm/muc
    1221Key Points:
    13  * the "router" is an application-agnostic process
     22 * s2s and c2s have very specific routing rules on XMPP stanzas and often you want multiple c2s components to spread load, ie, 10k connections on machine 1, 10k on machine 2
    1423 * Twisted should support all components running in a single process as well as components distributed over multiple processes/machines
    1524 * 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
    3039All we are missing for a super complete component/service setup in twisted is s2s support
     41Thoughts for the near-term:
     42 * twisted.words should have a domain model for "chat" (multi-user chat, user-to-user (instant messaging), and presence), which should be protocol-independent.  That should integrate extremely gracefully (i.e. properly forward any extensions) with jabber, but also with IRC and, ideally, with SILC ( or whatever.
     43 * However, XMPP is obviously quite a bit more than chat, and there should be separate, unrelated 'twistd' plugins for invoking the various internal XMPP components, to facilitate multiprocess separation as you were describing above.
     44and with 'chat' you mean multi-user chat?
     45 * XMPP code in twisted should have a user- or devloper-visible entrypoint without coding
     46 * there is room for twistd plugins that each do a separate thing (router, c2s, sm, s2s) but can also imagine a xmpp-im one that does all of that in one process
     47 * words's domain model is kind of a piece of crap (I assume palaver has its own, and we'll probably need to do a bunch of maintenance to make a good one that can actually translate between the supported protocols without losing information)
     48 * User credentials should go through cred, and should use the normal cred stuff for user credentials and contact lists, and related:
     49 * we should package one incredibly terrible contact list storage mechanism with twisted, that uses a directory full of text files or something, and provide a nice abstract avatar interface for doing the storage that you should really implement yourself
     50 * there should be support for allowing any message to come along with bundled with "protocol extensions" which, in xmpp's case, can come along with arbitrary XML, so that the server does not need to understand them in order for clients or components to relay them to each other