From 07501f8085e7813310c08a40360eb0b6b9b41c65 Mon Sep 17 00:00:00 2001
From: Evgeniy Khramtsov ejabberd is a free and open source instant messaging server written in Erlang/OTP. ejabberd is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication. ejabberd is designed to be a rock-solid and feature rich XMPP server. ejabberd is suitable for small deployments, whether they need to be scalable or not, as well as extremely big deployments. ejabberd is:
- Introduction
+ ejabberd is a free and open source instant messaging server written in Erlang/OTP. ejabberd is cross-platform, distributed, fault-tolerant, and based on open standards to achieve real-time communication. ejabberd is designed to be a rock-solid and feature rich XMPP server. ejabberd is suitable for small deployments, whether they need to be scalable or not, as well as extremely big deployments. ejabberd is:
+ Moreover, ejabberd comes with a wide range of other state-of-the-art features:
- Moreover, ejabberd comes with a wide range of other state-of-the-art features:
+ A XMPP domain is served by one or more ejabberd nodes. These nodes can
+ A XMPP domain is served by one or more ejabberd nodes. These nodes can
be run on different machines that are connected via a network. They all must
have the ability to connect to port 4369 of all another nodes, and must have
the same magic cookie (see Erlang/OTP documentation, in other words the file
-~ejabberd/.erlang.cookie must be the same on all nodes). This is
+~ejabberd/.erlang.cookie must be the same on all nodes). This is
needed because all nodes exchange information about connected users, S2S
-connections, registered services, etc… Each ejabberd node have following modules:
-
-Ejabberd 2.1.12 Developers Guide
Alexey Shchepin
- mailto:alexey@sevcom.net
- xmpp:aleksey@jabber.ru
+Ejabberd community 14.05-120-gedfb5fc Developers Guide
Alexey Shchepin
+ mailto:alexey@sevcom.net
+ xmpp:aleksey@jabber.ru
+
-
I can thoroughly recommend ejabberd for ease of setup –
-Kevin Smith, Current maintainer of the Psi project
-Contents
-
-
-1 Key Features
I can thoroughly recommend ejabberd for ease of setup –
+Kevin Smith, Current maintainer of the Psi project
+Contents
+
+
+1 Key Features
-2 Additional Features
+
+2 Additional Features
+
+
+
-
-
+
-
+
-
+
-
+
-3 How it Works
3 How it Works
Each ejabberd node have following modules: +
This module is the main router of XMPP packets on each node. It routes +
This module is the main router of XMPP packets on each node. It routes them based on their destinations domains. It has two tables: local and global routes. First, domain of packet destination searched in local table, and if it found, then the packet is routed to appropriate process. If no, then it -searches in global table, and is routed to the appropriate ejabberd node or +searches in global table, and is routed to the appropriate ejabberd node or process. If it does not exists in either tables, then it sent to the S2S -manager.
-This module routes packets which have a destination domain equal to this server +manager.
+ +This module routes packets which have a destination domain equal to this server name. If destination JID has a non-empty user part, then it routed to the -session manager, else it is processed depending on it’s content.
-This module routes packets to local users. It searches for what user resource +session manager, else it is processed depending on it’s content.
+ +This module routes packets to local users. It searches for what user resource packet must be sent via presence table. If this resource is connected to this node, it is routed to C2S process, if it connected via another node, then -the packet is sent to session manager on that node.
-This module routes packets to other XMPP servers. First, it checks if an +the packet is sent to session manager on that node.
+ +This module routes packets to other XMPP servers. First, it checks if an open S2S connection from the domain of the packet source to the domain of packet destination already exists. If it is open on another node, then it routes the packet to S2S manager on that node, if it is open on this node, then it is routed to the process that serves this connection, and if a connection -does not exist, then it is opened and registered.
-The external authentication script follows -the erlang port driver API.
That script is supposed to do theses actions, in an infinite loop: -
The external authentication script follows +the erlang port driver API.
That script is supposed to do theses actions, in an infinite loop: +
Example python script -
#!/usr/bin/python +
Example python script +
#!/usr/bin/python import sys from struct import * @@ -242,10 +260,11 @@ while True: elif data[0] == "setpass": success = setpass(data[1], data[2], data[3]) to_ejabberd(success) --
Each XML stanza is represented as the following tuple: -
XMLElement = {xmlelement, Name, Attrs, [ElementOrCDATA]} ++ +
Each XML stanza is represented as the following tuple: +
XMLElement = {xmlelement, Name, Attrs, [ElementOrCDATA]} Name = string() Attrs = [Attr] Attr = {Key, Val} @@ -253,30 +272,31 @@ while True: Val = string() ElementOrCDATA = XMLElement | CDATA CDATA = {xmlcdata, string()} -
E. g. this stanza: -
<message to='test@conference.example.org' type='groupchat'> +
E. g. this stanza: +
<message to='test@conference.example.org' type='groupchat'> <body>test</body> </message> -
is represented as the following structure: -
{xmlelement, "message", +
is represented as the following structure: +
{xmlelement, "message", [{"to", "test@conference.example.org"}, {"type", "groupchat"}], [{xmlelement, "body", [], [{xmlcdata, "test"}]}]}} --
element_to_string(El) -> string()
-El = XMLElement -Returns string representation of XML stanza El.
crypt(S) -> string()
-S = string() -Returns string which correspond to S with encoded XML special -characters.
remove_cdata(ECList) -> EList
-ECList = [ElementOrCDATA] ++ +
element_to_string(El) -> string()
+El = XMLElement +Returns string representation of XML stanza El.
crypt(S) -> string()
+S = string() +Returns string which correspond to S with encoded XML special +characters.
remove_cdata(ECList) -> EList
+ECList = [ElementOrCDATA] EList = [XMLElement] -EList is a list of all non-CDATA elements of ECList.
get_path_s(El, Path) -> Res
-El = XMLElement +EList is a list of all non-CDATA elements of ECList.
get_path_s(El, Path) -> Res
+El = XMLElement Path = [PathItem] PathItem = PathElem | PathAttr | PathCDATA PathElem = {elem, Name} @@ -284,57 +304,60 @@ PathAttr = {attr, Name} PathCDATA = cdata Name = string() Res = string() | XMLElement -If Path is empty, then returns El. Else sequentially -consider elements of Path. Each element is one of: -
{elem, Name}
Name is name of subelement of
-El, if such element exists, then this element considered in
+If Path is empty, then returns El. Else sequentially
+consider elements of Path. Each element is one of:
+{elem, Name}
Name is name of subelement of
+El, if such element exists, then this element considered in
following steps, else returns empty string.
-{attr, Name}
If El have attribute Name, then
+{attr, Name}
If El have attribute Name, then
returns value of this attribute, else returns empty string.
-cdata
Returns CDATA of El.
-get_cdata/1, get_tag_cdata/1 +
cdata
Returns CDATA of El.
+get_cdata/1, get_tag_cdata/1 get_attr/2, get_attr_s/2 get_tag_attr/2, get_tag_attr_s/2 get_subtag/2 -
parse_element(Str) -> XMLElement | {error, Err}
-Str = string() +
parse_element(Str) -> XMLElement | {error, Err}
+Str = string() Err = term() -Parses Str using XML parser, returns either parsed element or error +Parses Str using XML parser, returns either parsed element or error tuple. -
The module gen_iq_handler
allows to easily write handlers for IQ packets
-of particular XML namespaces that addressed to server or to users bare JIDs.
In this module the following functions are defined: -
add_iq_handler(Component, Host, NS, Module, Function, Type)
-Component = Module = Function = atom() +
The module gen_iq_handler
allows to easily write handlers for IQ packets
+of particular XML namespaces that addressed to server or to users bare JIDs.
In this module the following functions are defined: +
add_iq_handler(Component, Host, NS, Module, Function, Type)
+Component = Module = Function = atom() Host = NS = string() Type = no_queue | one_queue | parallel -Registers function
Module:Function
as handler for IQ packets on
-virtual host Host
that contain child of namespace NS
in
-Component
. Queueing discipline is Type
. There are at least
+Registers function Module:Function
as handler for IQ packets on
+virtual host Host
that contain child of namespace NS
in
+Component
. Queueing discipline is Type
. There are at least
two components defined:
-ejabberd_local
Handles packets that addressed to server JID;
-ejabberd_sm
Handles packets that addressed to users bare JIDs.
-remove_iq_handler(Component, Host, NS)
-Component = atom() +
ejabberd_local
Handles packets that addressed to server JID;
+ejabberd_sm
Handles packets that addressed to users bare JIDs.
+remove_iq_handler(Component, Host, NS)
+Component = atom() Host = NS = string() -Removes IQ handler on virtual host
Host
for namespace NS
from
-Component
.
-Handler function must have the following type: -
Module:Function(From, To, IQ)
-From = To = jid() -
-module(mod_cputime). +Removes IQ handler on virtual host
Host
for namespace NS
from
+Component
.
+Handler function must have the following type: +
Module:Function(From, To, IQ)
+From = To = jid() +
-module(mod_cputime). -behaviour(gen_mod). @@ -368,9 +391,10 @@ process_local_iq(From, To, {iq, ID, Type, XMLNS, SubEl}) -> [{"xmlns", ?NS_CPUTIME}], [{xmlelement, "cputime", [], [{xmlcdata, SCPUTime}]}]}]} end. --
-module(mod_echo). ++ +
-module(mod_echo). -behaviour(gen_mod). @@ -404,10 +428,10 @@ stop(Host) -> Proc = gen_mod:get_module_proc(Host, ?PROCNAME), Proc ! stop, {wait, Proc}. -+ -
This document was translated from LATEX by -HEVEA.- +
This document was translated from LATEX by +HEVEA.