Changes between Version 1 and Version 2 of XMPPServerArchitecture


Ignore:
Timestamp:
09/03/2008 02:34:33 PM (6 years ago)
Author:
oubiwann
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • XMPPServerArchitecture

    v1 v2  
    11= XMPP Server Architecture  = 
    22 
    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.'' 
    44 
    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. conference.jabber.org, that is part of the jabber.org server) or a pubsub component 
    1111 
     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) 
     15 
     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 
     20 
    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 
     
    2938 
    3039All we are missing for a super complete component/service setup in twisted is s2s support 
     40 
     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 (http://silcnet.org/) 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