Directories | |
| directory | modules |
Files | |
| file | authreg.cc |
| handle authentication or new-user registration requests | |
| file | deliver.cc |
| handle incoming packets and check how they can be delivered | |
| file | jsm.cc |
| main part of the jsm (Jabberd session manager) module | |
| file | jsm.h [code] |
| definition of the jsm API | |
| file | modules.cc |
| jsm module API | |
| file | offline.cc |
| handle packets addressed to existing but offline users | |
| file | serialization.cc |
| functions for serialization an deserialization of JSM state | |
| file | server.cc |
| handle packets intended for the server: administration, public IQ (agents, etc) | |
| file | sessions.cc |
| handle messages to and from user sessions | |
| file | users.cc |
| functions for manipulating data for logged in users | |
| file | util.cc |
| utility functions for jsm | |
The Jabber session manager (JSM) is the component of jabberd14, that handles the visible part of transporting and storing messages, and managing presence and presence subscriptions. It implements the bussiness logic of the instant messaging and presence handling.
The JSM component itself is devided into two parts: The base JSM component and modules plugged into this base JSM component. (The modules can be found inside the directory jsm/modules.)
The base JSM component (implemented inside this directory) has as less bussiness logic as possible. Its main task is to manage lists of event subscriptions and to call all registered event handlers if an event gets triggered. Events can either be triggered by incoming stanzas, or may be triggered inside the handling of other events.
Which modules have to be loaded is configured inside the jabberd14 configuration file. The configured modules are loaded on startof of the JSM component by calling a function named like the XML element, that was used inside the load element in the configuration file. This function than have to initialize the module and register for the callbacks, the module wants to handle.
The events are devided into two categories. The two category of events differ on if they are bound to a specific session of a user or not. Events bound to a session of a user are prefixed by "es_" while the other event names are prefixed just by "e_". Typically a module registers for the es_ events inside the e_SESSION event, that is called when a new session starts up.
The events are defined inside the file jsm.h. The events not bound to a specific session are: e_SESSION, e_OFFLINE, e_SERVER, e_DELIVER, e_SHUTDOWN, e_AUTH, e_REGISTER, e_CREATE, and e_DELETE. The events bound to a specific session are: es_IN, es_OUT, and es_END.
When this component is started by a call of jsm(), it initializes internal data, registers the function js_packet() to get called by the XML router for packets addressed to the domain(s) that this session manager instance handles, and registers the function js_users_gc() to get called periodically.
If a stanza is routed to the JSM and received by js_packet(), it is first checked which type of stanza it is. Different actions are taken for <route/> stanzas than for other stanzas (<message/>, <iq/>, or <presence/>). Inside the <route/> elements there are stanzas forwarded by a component to the JSM. Normally this are elements received from the client by the client connection manager and forwarded to the session manager. They are wrapped inside this forwarding stanza, to ensure that each stanza of a user is send through the user's session manager and not to the recepient directly. Also there are special <route/> stanzas used to establish sessions (supporting two types of session establishment protocols: the traditional jabberd14 protocol (see http://svn.jabberd.org/trunk/jadc2s/PROTO) as well es a new protocol introduced by jabberd2 (see http://jabberd.jabberstudio.org/dev/docs/component.shtml)). The other stanzas are stanzas normally received from an other session manager (either local or remote in which case the stanzas already passed the dialback component) or a gateway/transport.
The normal, non-<route/>d stanzas are processed the following way (starting processing in js_deliver_local()): All modules registered for the e_DELIVER event are called. If one of the called modules returned M_HANDLED, the stanza is considered to be processed and no further actions are taken. If non of the modules handled the packet, the further processing is different for the following types of stanzas: Stanzas addressed just to the server domain or the domain and a resource, but no user; stanzas addressed to an existing user address for a user that is; stanzas addressed to an existing user address, but the user is not online or the stanza is addressed to a specified resource of the user and there is no session for this resource; and stanzas addressed to non-existing users.
Stanzas for non-existing users are just bounced with XTERROR_NOTFOUND, no further events are generated.
Stanzas for offline users and resources that are not online at present generate an e_OFFLINE event. If one of the modules registered for this event returns M_HANDLED, the stanzas is considered handled and not further processed. If no module returned M_HANDLED, the stanza is bounced using XTERROR_RECIPIENTUNAVAIL.
Stanzas for online users (and stanzas addressed to an explicit resource, that is currently online) generate an es_IN event. If one of the modules handling the es_IN event returned M_HANDLED, the stanza is considered to be processed and no further actions are taken for this stanza. If no module returned M_HANDLED, the session manager delivers the stanza to the client, by wrapping the stanza inside a <route/> stanza and sending the packet to the responsible client connection manager. While stanzas for online users are processed, it is checked before and after the es_IN event, if the session is still existing and not marked as being shut down. If it is marked as being shut down, the packet is reprocessed starting with the e_DELIVER process as described above.
Stanzas addressed to the server (no user part in the Jabber ID) generate an e_SERVER event. Again the stanza is considered to be handled, if one of the modules, that registered for this event, returned M_HANDLED, or else it is bounced with XTERROR_NOTFOUND.
The processing for <route/>ed stanzas is as the following: It is first checked if is a session control packet. Session control packets are processed by the following functions: _js_routed_session_packet(), _js_routed_auth_packet(), and _js_routed_error_packet() for the traditional jabberd14 session control protocol; and by _js_routed_session_control_packet() for stanzas for the jabberd2 compatible session control protocol.
All session control packets share the same set of events: e_SESSION is called, when a new session is created (in case of the traditional protocol, the session is not yet authenticated!); es_END is called, when a session is closed (a user logs out); e_REGISTER is called, for processing registration requests; e_CREATE is called if a user successfully registered for an account; e_DELETE is called if an account is being destroyed; e_AUTH is an event only called for the traditional protocol, when a packet arrives, that contain stanzas from a user, that is just authenticating (for the jabberd2 compatible protocol it is the task of the client connection manager to authenticate the user, therefore the session manager never gets stanzas while the user is not yet authenticated).
Normal <route/>d stanzas are processed by js_session_from(), which first checks if the from address is a valid address of this user and is present at all. Afterwards the es_OUT event is called. If one of the modules registered for this event returned M_HANDLED, the processing of the stanza is stopped. Else the stanza is considered to be okay and will just be delivered to the address, it is sent to by a call to js_deliver().
1.5.3