Re: Questions...
On Thu, Apr 14, 2016 at 04:19:06PM +0200, Matěj Cepl wrote: > On 2016-04-14, 10:26 GMT, Adrian Reber wrote: > > In the configuration I am running jabberd2 on Fedora I did not > > have many (maybe any) upgrading the last few versions. EPEL-7 > > would be an upgrade from 2.3.2 to 2.3.6. It probably depends > > on the installation and which backends are used if the > > upgrade. Looking at > > > > https://github.com/jabberd2/jabberd2/blob/master/NEWS > > > > it seems upgrading from 2.3.4 to 2.3.5 can require database > > changes. Not sure how to handle this. But we can try. > > # mod_verify requires CREATE TABLE "verify" in DB. Make sure > # you created it before enabling the module in sm.xml. > > However, the mod_verify is new in 2.3.5, so we don't have to > care about its migration, right? Or what am I missing? Ah, now that you say so. I never read it that way. But true. Then it is probably not more than a 'git merge master' to get the latest jabberd2 on EPEL-7. If you want you can update it for EPEL-7. Adrian
Re: Questions...
On Thu, Apr 14, 2016 at 10:49:30AM +0200, Matěj Cepl wrote: > On 2016-04-14, 06:27 GMT, Adrian Reber wrote: > > On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote: > >> 1) Is this project the 'jabberd' that's available in EPEL? > > > > I can answer that one. jabberd in EPEL is jabberd2. As it is EPEL it > > will not see as many updates as the upstream package > > I agree that I would keep EPEL-6 (or even EPEL-5) untouched just > with possible security patches, but it seems to me that rebase > in EPEL-7 would not be the worst idea. What do you think? I am > willing to help with patching. > > Do we know what is the upgrade story? Does the latest jabberd2 > just takes over the original configuration? In the configuration I am running jabberd2 on Fedora I did not have many (maybe any) upgrading the last few versions. EPEL-7 would be an upgrade from 2.3.2 to 2.3.6. It probably depends on the installation and which backends are used if the upgrade. Looking at https://github.com/jabberd2/jabberd2/blob/master/NEWS it seems upgrading from 2.3.4 to 2.3.5 can require database changes. Not sure how to handle this. But we can try. Adrian
Re: Questions...
On 2016-04-14, 06:27 GMT, Adrian Reber wrote: > On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote: >> 1) Is this project the 'jabberd' that's available in EPEL? > > I can answer that one. jabberd in EPEL is jabberd2. As it is EPEL it > will not see as many updates as the upstream package I agree that I would keep EPEL-6 (or even EPEL-5) untouched just with possible security patches, but it seems to me that rebase in EPEL-7 would not be the worst idea. What do you think? I am willing to help with patching. Do we know what is the upgrade story? Does the latest jabberd2 just takes over the original configuration? Best, Matěj -- https://matej.ceplovi.cz/blog/, Jabber: mc...@ceplovi.cz GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC SCSI is *not* magic. There are *fundamental* *technical* reasons why you have to sacrifice a young goat to your SCSI chain every now and then. -- John F. Woods
Re: Questions...
On Wed, Apr 13, 2016 at 09:19:45AM -0700, John Oliver wrote: > 1) Is this project the 'jabberd' that's available in EPEL? I can answer that one. jabberd in EPEL is jabberd2. As it is EPEL it will not see as many updates as the upstream package Adrian
Questions...
1) Is this project the 'jabberd' that's available in EPEL? 2) Can jabberd2 authenticate against LDAP? 3) Can jabberd2 have users auto-join or automatically be buddies? Thanks... -- *** * John Oliver http://www.john-oliver.net/ * * * ***
Re: Ldapvcard questions
Hi,
I've finally been able to get it working after few modifications.
First, as I was getting an error ([error] failed loading storage module
'ldapvcard' (/usr /lib/jabberd/storage_ldapvcard.so: undefined symbol:
_ldap_get_lderrno)) while trying to use as storage ldapvcard, I removed
the extern and copied the function to storage_ldapvcard.c
Then I've also modified storage_ldapvcard.c with the idea of being able
to add the realm in the basedn line like in ldapfull. This way the realm
is appended to the user while publishing the roster.
You can find the patch attached.
Kind regards,
Oriol
On 01/12/13 17:47, Oriol Mula-Valls wrote:
Hi,
I've been using jabberd2 for more than two years in our research unit. During
this time the amount of people has increase although some people has gone.
I am tired of adding and removing people from our roster template and from our
xmpp client, pidgin. Therefore, I decided to switch to
ldapvcard and user roster-publish. However, I am facing two problems one of
them also happens with roster template.
Roster template works perfect for a new user that arribes but although all
contacts are shown, they are all off-line and user has to make a re-request
authorization for all of them. An example entry of our roster.xml is:
item name='Oriol Mula-Valls' jid='omula@cfu.local'
subscription='both'groupIT/group/item
I have also this problem with roster-publish and ldapvcard.
Now that version 2.3.1 has been released with jabberd2.schema I
understand more or less how to use ldapvcard. I have loaded the
provided schema on our ldap server but I have not managed to get it working
properly.
I use uid, posixAccount and userPassword because
on the one hand the other attributes are not in the ldap schema provided and on
the other hand it would be duplicating information. This setup has the problem
that the domain is not appended to the uid attribute and therefore it doesn't
work. I tried to modified a user appending the realm to its uid (e.g.: uid:
omula@cfu.local) and it this case it worked. Nonetheless, user was offline and
authorization request was needed.
!-- LDAPVCARD driver configuration --
ldapvcard
!-- LDAP server host and port (default: 389) --
urildap://ldap.cfu.local//uri
binddncn=admin,dc=cfu,dc=local/binddn
bindpwXXX/bindpw
!-- LDAP attribute that holds the user ID (default: uid) --
uidattruid/uidattr
objectclassposixAccount/objectclass
pwattruserPassword/pwattr
!-- if you use included jabberd.schema use this:
uidattrjid/uidattr
objectclassjabberUser/objectclass
pwattrjabberPassword/pwattr --
basednou=users,dc=cfu,dc=local/basedn
groupattrjabberPublishedGroup/groupattr
publishedattrjabberPublishedItem/publishedattr
publishedcachettl60/publishedcachettl
mapped-groups
/mapped-groups
/ldapvcard
Can anyone help me to fix configuration problems, please? Thanks in advance.
Kind regards,
Oriol
--
Oriol Mula Valls
Institut Català de Ciències del Clima (IC3)
Doctor Trueta 203 - 08005 Barcelona
Tel:+34 93 567 99 77
--
Oriol Mula Valls
Institut Català de Ciències del Clima (IC3)
Doctor Trueta 203 - 08005 Barcelona
Tel:+34 93 567 99 77
--- storage/storage_ldapvcard.c 2013-10-07 15:27:54.0 +
+++ /tmp/jabberd-2.3.1/storage/storage_ldapvcard.c 2013-12-02
20:28:58.674258262 +
@@ -37,7 +37,6 @@
#define LDAPVCARD_SEARCH_MAX_RETRIES 1
-extern int _ldap_get_lderrno(LDAP *ld);
/** internal structure, holds our data */
typedef struct drvdata_st {
@@ -47,6 +46,7 @@
const char *binddn;
const char *bindpw;
const char *basedn;
+const char *realm;
const char *objectclass; // objectclass of jabber users
const char *uidattr; // search attribute for users
@@ -103,6 +103,16 @@
{NULL,NULL,0}
};
+/** utility function to get ld_errno */
+static int _ldap_get_lderrno(LDAP *ld)
+{
+int ld_errno;
+
+ldap_get_option(ld, LDAP_OPT_ERROR_NUMBER, ld_errno);
+
+return ld_errno;
+}
+
static int processregex(char *src, const char *regex, int patterngroups, int
wantedgroup, char *dest, size_t dest_size, st_driver_t drv) {
regex_t preg;
regmatch_t pmatch[patterngroups];
@@ -269,7 +279,7 @@
const char *attrs_prg[] = { data-groupnameattr, NULL };
LDAPMessage *result, *entry;
ldapvcard_entry_st le;
-int i,ival;
+int i,ival,realm_len,user_len;
int tried = 0;
char jid[2048], group[1024], name[2048]; // name is sn[1024] + ' ' +
initials[1024]
@@ -442,7 +452,17 @@
ldap_value_free(vals);
continue;
}
-strncpy(jid,vals[0],sizeof(jid)-1); jid[sizeof(jid)-1]='\0';
+strncpy(jid,vals[0],sizeof(jid)-1);
+if(data-realm) {
+realm_len = strlen(data-realm);
+if(realm_len 0) {
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 18/10/2012 16:42, Tomasz Sterna a écrit : Dnia 2012-10-18, czw o godzinie 16:12 +0200, Alexandre Jousset pisze: What if you do not manage all the routers in the mesh? And you were given a password to access only one or two routers of the mesh? I think it is pretty unusual for the admin not to have access to all routers (at least all routers managing the same domains). I'm sure there could be cases and this would add a lot of flexibility, but see below for the drawbacks. I've been building collaborative mesh networks (ircd, eggdrop) a lot. Believe me, the situations when you have just an entry point to the network are not that rare. Besides, it goes along the philosophy of jabberd2. router-users.xml is there for a reason. If it was assumed one administrator controls the whole components network, there would be no need for separate users. The problem with the multi-hop proposal is that you have to manage cases where there is cyclic connections. e.g. A = B = C = A What exactly is the problem with cyclic connections? A solution may be to add the ID of the component binding the domain / bare JID to the bound route, and to check if that combination is already bound, but this will increase CPU usage and the data structure sizes. TTL/distance would be enough. This does not increase data structures that much and CPU use is neglectable - you have to choose the route anyway. Premature optimisation is the root of all evil. - let's concentrate on the design first. Now that I think of it, implementing distance would be beneficial anyway, as we could mark routers on slow connections as less preferable. For the moment I have 2 hash tables (finally I differentiated them), one for domains where we don't really care of the size of the values, and one for bare JIDs bindings where the value is just the component_t. This component_t can be the local component for local connections, or other routers connection for remotes. So we would have to add a char * malloc'ed, strcpy'ed, etc., for each new connection in bare JID binding mode. So this would add CPU and memory consumption just for multi-hop support. It's a choice to do, if you really want me to do this I'll do it, but I'm a bit against that solution. I'm sorry, I don't understand. Give me for-instance. Forget about all this ;-) As I was writing a response to this post I understood that my problem was an implementation issue indeed, and I found a solution for it ;-) Roughly, instead of storing a component_t as bare JID hash table values I'll store a pointer to an element of a pool of component_t / component ID / distance associations. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
About this topic, I have some more comments and questions: Le 15/10/2012 02:22, Alexandre Jousset a écrit : Le 12/10/2012 19:53, Tomasz Sterna a écrit : We do. In the simplest way to do it, routers don't forward other routers' binding requests. Of course it is possible to implement it to allow multi-hops, but I'm afraid this could lead to problems (and inefficiency) for no real gain (except simplistic configuration). Of course it would be easier to only list just one router of the mesh when adding a router, but I would prefer sacrificing this easiness in favor of efficiency. After all, the administrator has all knowledge about its server architecture. So when adding a router, the config file should list *all* other already running routers in the mesh. What if you do not manage all the routers in the mesh? And you were given a password to access only one or two routers of the mesh? I think it is pretty unusual for the admin not to have access to all routers (at least all routers managing the same domains). I'm sure there could be cases and this would add a lot of flexibility, but see below for the drawbacks. In my proposal nothing stops you from making each router know all the others to make it more efficient, but it shouldn't be _required_. The problem with the multi-hop proposal is that you have to manage cases where there is cyclic connections. e.g. A = B = C = A A solution may be to add the ID of the component binding the domain / bare JID to the bound route, and to check if that combination is already bound, but this will increase CPU usage and the data structure sizes. For the moment I have 2 hash tables (finally I differentiated them), one for domains where we don't really care of the size of the values, and one for bare JIDs bindings where the value is just the component_t. This component_t can be the local component for local connections, or other routers connection for remotes. So we would have to add a char * malloc'ed, strcpy'ed, etc., for each new connection in bare JID binding mode. So this would add CPU and memory consumption just for multi-hop support. It's a choice to do, if you really want me to do this I'll do it, but I'm a bit against that solution. Of course, if you have better solution... :-) -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-10-15, pon o godzinie 02:22 +0200, Alexandre Jousset pisze: We talked earlier about weighted randomization instead of priorities. With weighted randomization it is impossible to be sure that a local component will be preferred, this is why I made an implicit priority for local components, still using weighted random between local components, or between remote components when needed. Right. But I still don't see a rationale, why local components are better than remote ones? Why does local component should be preferred just because the connection happened to come from local c2s? To do otherwise, we should use weighted random + priorities, this would add more complexity and misunderstanding in the configuration process. I was thinking more of a binary switch prefer local components, than reintroducing priorities.
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 15/10/2012 10:03, Tomasz Sterna a écrit : Dnia 2012-10-15, pon o godzinie 02:22 +0200, Alexandre Jousset pisze: We talked earlier about weighted randomization instead of priorities. With weighted randomization it is impossible to be sure that a local component will be preferred, this is why I made an implicit priority for local components, still using weighted random between local components, or between remote components when needed. Right. But I still don't see a rationale, why local components are better than remote ones? Why does local component should be preferred just because the connection happened to come from local c2s? Going to a remote component involves going through local router, then through remote router, then remote component. It adds a hop + a (physical) network access. To do otherwise, we should use weighted random + priorities, this would add more complexity and misunderstanding in the configuration process. I was thinking more of a binary switch prefer local components, than reintroducing priorities. Ok. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-10-15, pon o godzinie 12:15 +0200, Alexandre Jousset pisze: But I still don't see a rationale, why local components are better than remote ones? Why does local component should be preferred just because the connection happened to come from local c2s? Going to a remote component involves going through local router, then through remote router, then remote component. It adds a hop + a (physical) network access. That's a technical detail that should not affect the load balancing algorithm. If I set two components one with weight 1 and one with weight 2, the second one should get two times more requests than first one, regardless where is it connected and where the requests are coming from.
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 15/10/2012 14:43, Tomasz Sterna a écrit : Dnia 2012-10-15, pon o godzinie 12:15 +0200, Alexandre Jousset pisze: But I still don't see a rationale, why local components are better than remote ones? Why does local component should be preferred just because the connection happened to come from local c2s? Going to a remote component involves going through local router, then through remote router, then remote component. It adds a hop + a (physical) network access. That's a technical detail that should not affect the load balancing algorithm. If I set two components one with weight 1 and one with weight 2, the second one should get two times more requests than first one, regardless where is it connected and where the requests are coming from. You're right. I think both behaviors make sense so I agree with you to add a binary switch in configuration to tell the router whether it should take care of local / remote components or not. This would make, for example, the use of a (separate and protocol agnostic) load balancer in front of the cluster more efficient. But it's true that in that example the weighted randomization would be useless. But as it (the binary switch) is easy to implement, letting the admin choose is better. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
I respond to this message back in time to ask a question: Le 11/09/2012 13:35, Tomasz Sterna a écrit : [...] Components have its own names. Each component needs to be uniquely named. Is it because components could previously have same names that there is « switch(targets-rtype) » at router/router.c:502, and all the multi attribute, route_MULTI_TO and route_MULTI_FROM? If not, I have misunderstood something about the purpose of these...? If yes, I think I can remove that functionality completely...? -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 15/10/2012 19:38, Tomasz Sterna a écrit : Dnia 2012-10-15, pon o godzinie 18:29 +0200, Alexandre Jousset pisze: Is it because components could previously have same names that there is « switch(targets-rtype) » at router/router.c:502, and all the multi attribute, route_MULTI_TO and route_MULTI_FROM? If not, I have misunderstood something about the purpose of these...? Take a look in the code how these are set. :-) In short, these choose on which attribute router does hash computation. In case of jabberd2 component protocol connections we have route_MULTI_TO, which computes hash of stanza to attribute. In case of legacy component connections we compute hash of from attribute. Legacy connections are used to connect transports, so we need to make sure all your packets are directed to the same transport instance - so we use from attribute (route_MULTI_FROM). Ok, I was confused by the from directing to which component to send the packet... I understand now. jabberd2 component protocol connections are jabberd2 components like sm, s2s and we need to make sure all stanza sent to you are directed to the same sm instance - thus we compute hash of the to attribute to select sm instance to route to. So, you may remove this support from jabberd2 protocol connections, but we need to keep route_MULTI_FROM behavior for legacy component connections, as we cannot extend this protocol. Ok, thanks for explanation. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
RE: Fwd: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-10-13, sob o godzinie 22:37 +1100, James Wilson pisze: Just thought of this: if you use an 'auto-config' type setting perhaps we could take a 'Bonjour' like route in that each server broadcasts within its local IP range / subnet for other XMPP servers and makes a live, real time list of available instances. Cool idea. Along these lines, I was also thinking some time ago about putting all router instances on RFC 3259 [1] Mbus wire [2]. This would greatly simplify binding and routing. [1] http://www.rfc-editor.org/in-notes/rfc3259.txt [2] http://www.mbus.org/ -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio mbus looks interesting but potentially brittle. The use of reliable messaging is quite interesting though. It could give you the ability for a platform neutral way to do service discovery. If you used something like Zeroconf you would have to write your own implementation of it i suspect so you could continue to support all the platforms you do, unless you use the resident tools like avahi for linux - BSD, Bonjour for mac, windows is lacking in this and uses uPNP. You could also look at using SLP, its a bit neglected though. Interesting thread. paul
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 12/10/2012 19:53, Tomasz Sterna a écrit : We do. In the simplest way to do it, routers don't forward other routers' binding requests. Of course it is possible to implement it to allow multi-hops, but I'm afraid this could lead to problems (and inefficiency) for no real gain (except simplistic configuration). Of course it would be easier to only list just one router of the mesh when adding a router, but I would prefer sacrificing this easiness in favor of efficiency. After all, the administrator has all knowledge about its server architecture. So when adding a router, the config file should list *all* other already running routers in the mesh. What if you do not manage all the routers in the mesh? And you were given a password to access only one or two routers of the mesh? In my proposal nothing stops you from making each router know all the others to make it more efficient, but it shouldn't be _required_. Ok. Also, in the pseudo-code I've written (and started to implement) I had to make a distinction between local components and remote routers, just for efficiency, to allow the use of a local component preferably before trying a remote one. So the local components have greater priorities than remote ones, and both are chosen with weighted random in their category. What do you think about this? Explicit is better than implicit. If you want local components to have higher priority - just say so in the configuration file. But default should be that remote binds are as equal as local ones. We talked earlier about weighted randomization instead of priorities. With weighted randomization it is impossible to be sure that a local component will be preferred, this is why I made an implicit priority for local components, still using weighted random between local components, or between remote components when needed. To do otherwise, we should use weighted random + priorities, this would add more complexity and misunderstanding in the configuration process. But maybe I've misunderstood something? Finally, I've added a routers.xml file (with a final 's', naming can be changed of course) to allow reloading it dynamically to change its connections settings if needed. What do you think about this? Do you think it could be necessary? Seams reasonable and simple. remote-routers.xml maybe? Ok. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Fwd: jabberd2 in cluster? ideas, proof of concept and questions...
Just thought of this: if you use an 'auto-config' type setting, perhaps we could take a 'Bonjour' like route in that each server broadcasts within its local IP range / subnet for other XMPP servers and makes a live, real time list of available instances. Regards, James This message was sent from my iPhone On 13/10/2012, at 4:53, Tomasz Sterna to...@xiaoka.com wrote: Dnia 2012-10-12, pią o godzinie 17:18 +0200, Alexandre Jousset pisze: Maybe it would be a good thing to say this (only 1 SM per domain to use less memory) in the install / config guide after the changes. I've now reread it and got it. Yes, it is worth mentioning in the documentation. We do. In the simplest way to do it, routers don't forward other routers' binding requests. Of course it is possible to implement it to allow multi-hops, but I'm afraid this could lead to problems (and inefficiency) for no real gain (except simplistic configuration). Of course it would be easier to only list just one router of the mesh when adding a router, but I would prefer sacrificing this easiness in favor of efficiency. After all, the administrator has all knowledge about its server architecture. So when adding a router, the config file should list *all* other already running routers in the mesh. What if you do not manage all the routers in the mesh? And you were given a password to access only one or two routers of the mesh? In my proposal nothing stops you from making each router know all the others to make it more efficient, but it shouldn't be _required_. Also, in the pseudo-code I've written (and started to implement) I had to make a distinction between local components and remote routers, just for efficiency, to allow the use of a local component preferably before trying a remote one. So the local components have greater priorities than remote ones, and both are chosen with weighted random in their category. What do you think about this? Explicit is better than implicit. If you want local components to have higher priority - just say so in the configuration file. But default should be that remote binds are as equal as local ones. Finally, I've added a routers.xml file (with a final 's', naming can be changed of course) to allow reloading it dynamically to change its connections settings if needed. What do you think about this? Do you think it could be necessary? Seams reasonable and simple. remote-routers.xml maybe? -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-10-12, pią o godzinie 17:18 +0200, Alexandre Jousset pisze: Maybe it would be a good thing to say this (only 1 SM per domain to use less memory) in the install / config guide after the changes. I've now reread it and got it. Yes, it is worth mentioning in the documentation. We do. In the simplest way to do it, routers don't forward other routers' binding requests. Of course it is possible to implement it to allow multi-hops, but I'm afraid this could lead to problems (and inefficiency) for no real gain (except simplistic configuration). Of course it would be easier to only list just one router of the mesh when adding a router, but I would prefer sacrificing this easiness in favor of efficiency. After all, the administrator has all knowledge about its server architecture. So when adding a router, the config file should list *all* other already running routers in the mesh. What if you do not manage all the routers in the mesh? And you were given a password to access only one or two routers of the mesh? In my proposal nothing stops you from making each router know all the others to make it more efficient, but it shouldn't be _required_. Also, in the pseudo-code I've written (and started to implement) I had to make a distinction between local components and remote routers, just for efficiency, to allow the use of a local component preferably before trying a remote one. So the local components have greater priorities than remote ones, and both are chosen with weighted random in their category. What do you think about this? Explicit is better than implicit. If you want local components to have higher priority - just say so in the configuration file. But default should be that remote binds are as equal as local ones. Finally, I've added a routers.xml file (with a final 's', naming can be changed of course) to allow reloading it dynamically to change its connections settings if needed. What do you think about this? Do you think it could be necessary? Seams reasonable and simple. remote-routers.xml maybe? -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-19, śro o godzinie 01:19 +0200, Alexandre Jousset pisze: You need bare-jid level binds only when there is more than one component handling the domain. If there is only one, you can do domain based routing without the need for user@domain binding. This approach does not use more memory than current solution. I was thinking about multiple SMs handling one domain. Maybe it would be a good thing to say this (only 1 SM per domain to use less memory) in the install / config guide after the changes. That would effectively disable clustering support, doesn't it? Now I have a question about the routers interconnections. In my proof of concept, each router had IPs/ports of each other router (including itself, just to copy/paste this part of the config file), and each one connected to each other in a client-server way, trying to reconnect roughly each X seconds (with a customizable X) in case of error / lost connection. I don't like this approach. Each router should have a list of router it needs to connect. This does not need to be a list of all routers present in the mesh. When each router binds all names known to it at the connect, routing is simple - you just route to the router binding the name. You don't care whether it forwards the packet to some other router/component using its own routing table. Multi-hops are possible, but we don't care really, do we? How do you see these interconnections? How to configure them? What if (and how) one add or remove a router/host from the cluster? In my other XMPP server implementation serves has a telnet command port. You just connect to the port and issue connection connect address port command. :-) But in our case a list of connections in the router.xml is enough I think. Only the new connecting router may have a connection listed. The connected router does not have to know the connecting router. Connecting server just need to know the secret needed to connect to and having proper right bind. Especially the first router in the mesh can have no predefined connections configured at all. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-19, śro o godzinie 05:08 +0200, Alexandre Jousset pisze: I don't see any need to stick with a (now weighted) random decision, other than in the user@domain auto-bind case. According to the pseudo code I've just written there are 3 cases where the router makes a random decision: [...] Do you see any other case? No. But it doesn't mean I didn't forget any. ;-) -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 17/09/2012 17:50, Tomasz Sterna a écrit : This case could be resolved if the router auto-binds the user@domain route. There could still be problems if there are more than one router. But that case (2+ routers auto-binding user@domain at the same time) could be fixed by the conflict resolution we thought before, just by canceling all the binds for user@domain...? What do you think? Brilliant idea! Works for me. Thanks :-) I would just make it temporary and extend it to all routing levels. Whenever the router makes a (random) decision to choose one of equal binds to route to, it sticks to this decision for a predefined time. Ok. I'm going to change my pseudo-code according to our latest decisions and when everything is OK I'll start to write real code. I'll keep you informed when there will be something interesting and / or more questions. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-18, wto o godzinie 21:50 +0200, Alexandre Jousset pisze: About routing levels and the user@domain binding... With this solution, there's no more domain-only level at the beginning, so each SM should bind directly bare JIDs and domains (still with auto-binding). Moreover, as the same SM will manage all user@domain, there is no more full JID binding level either... This simplifies binding and routing (and all changes needed to the code), as we only have to maintain 2 hash tables (preferably), one for domains (with multiple routes/priorities) and one for bare JIDs (with only 1 route and no priority, everything would be managed by the SM)... Do we need priorities in case of domain binds? This would cause sm with higher priority to take all the load. Maybe weights instead priorities. This would help tune load balancing. To sum it up, it is the end of the adaptive routing... And this has an implication, it is that the router memory consumption will be higher than before with single-router architecture... Then wouldn't it be a good solution to --enable-multi-router at ./configure time? It would add the burden of maintaining both binding/routing solutions (hopefully only in the router) but it will make the changes invisible to the currently deployed servers. Not really. You need bare-jid level binds only when there is more than one component handling the domain. If there is only one, you can do domain based routing without the need for user@domain binding. This approach does not use more memory than current solution. I won't accept #ifdef'd implementation. Even dynamic modules make releases difficult. Having switchable code is even more PITA. There were some screw ups with libsubst and mio implementations in the past. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 19/09/2012 00:19, Tomasz Sterna a écrit : Dnia 2012-09-18, wto o godzinie 21:50 +0200, Alexandre Jousset pisze: About routing levels and the user@domain binding... With this solution, there's no more domain-only level at the beginning, so each SM should bind directly bare JIDs and domains (still with auto-binding). Moreover, as the same SM will manage all user@domain, there is no more full JID binding level either... This simplifies binding and routing (and all changes needed to the code), as we only have to maintain 2 hash tables (preferably), one for domains (with multiple routes/priorities) and one for bare JIDs (with only 1 route and no priority, everything would be managed by the SM)... Do we need priorities in case of domain binds? This would cause sm with higher priority to take all the load. Maybe weights instead priorities. This would help tune load balancing. I thought it was what you meant previously, sorry. But you're right, ok for this. To sum it up, it is the end of the adaptive routing... And this has an implication, it is that the router memory consumption will be higher than before with single-router architecture... Then wouldn't it be a good solution to --enable-multi-router at ./configure time? It would add the burden of maintaining both binding/routing solutions (hopefully only in the router) but it will make the changes invisible to the currently deployed servers. Not really. You need bare-jid level binds only when there is more than one component handling the domain. If there is only one, you can do domain based routing without the need for user@domain binding. This approach does not use more memory than current solution. I was thinking about multiple SMs handling one domain. Maybe it would be a good thing to say this (only 1 SM per domain to use less memory) in the install / config guide after the changes. I won't accept #ifdef'd implementation. Even dynamic modules make releases difficult. Having switchable code is even more PITA. There were some screw ups with libsubst and mio implementations in the past. Ok again :-) Sorry for insisting ;-) Now I have a question about the routers interconnections. In my proof of concept, each router had IPs/ports of each other router (including itself, just to copy/paste this part of the config file), and each one connected to each other in a client-server way, trying to reconnect roughly each X seconds (with a customizable X) in case of error / lost connection. The client router component binded the domains it managed on the server, so when the server wanted to send a packet it used that bind information to route. Each router was at the same time a client and a server, receiving packets from other routers on its client side and routing outgoing packets on its server-side. This architecture is far from perfection of course, but it has the advantage of being symmetric, avoiding problems about which router has to connect to which router and some other issues. How do you see these interconnections? How to configure them? What if (and how) one add or remove a router/host from the cluster? I'm thinking about something like editing the router.xml file on each host, or a specific routers.xml containing only these informations that could be copied verbatim on each host, and sending a SIGsomething to reload it, but if you have a better idea you're welcome :-) -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
About this, and after reading/writing other posts in other parts of this thread: Le 17/09/2012 17:50, Tomasz Sterna a écrit : I would just make it temporary and extend it to all routing levels. Whenever the router makes a (random) decision to choose one of equal binds to route to, it sticks to this decision for a predefined time. I don't see any need to stick with a (now weighted) random decision, other than in the user@domain auto-bind case. According to the pseudo code I've just written there are 3 cases where the router makes a random decision: 1) to=ad...@example.com (with or without resource) or to=example.com, and no example.com domain bound = weighted random on default routes (whether we accept multiple default routes or not, and how, is another question) 2) to=ad...@example.com (with or without resource), no ad...@example.com bare JID bound and more than one component accepting example.com = weighted random on example.com routes + auto-bind ad...@example.com to the chosen route 3) to=example.com and more than one component accepting example.com = weighted random on example.com routes Do you see any other case? -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 17/09/2012 10:05, Tomasz Sterna a écrit : Dnia 2012-09-16, nie o godzinie 23:06 +0200, Alexandre Jousset pisze: Err... Sorry again, but in case of delivery I've found that: http://xmpp.org/rfcs/rfc3921.html#rules (see 11.1.4.1 for messages)... This page was what I saw before posting my solution (I remember now). Anyway, it is for messages, where one can deliver them to *all* with same priority without ACK problems and there are other treatment (see same URL) for other types of stanzas. Am I still wrong and mixing things or...? ;-) I still don't see how this might work. Could you give an example protocol flow? The question was: But then - what happens if two resources of the same priority get connected to two different sm instances? After reading the link I posted in my previous message, I don't see what could be the problem with this...? The router should send the messages to both SMs where the resources with same priority are bound, they will know what to do with them. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-17, pon o godzinie 10:55 +0200, Alexandre Jousset pisze: The question was: But then - what happens if two resources of the same priority get connected to two different sm instances? After reading the link I posted in my previous message, I don't see what could be the problem with this...? The router should send the messages to both SMs where the resources with same priority are bound, they will know what to do with them. What about iq and/or presence? - iq-get would get two responses then - presence-subscribe could get both accept and deny, which to use?
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 17/09/2012 11:02, Tomasz Sterna a écrit : Dnia 2012-09-17, pon o godzinie 10:55 +0200, Alexandre Jousset pisze: The question was: But then - what happens if two resources of the same priority get connected to two different sm instances? After reading the link I posted in my previous message, I don't see what could be the problem with this...? The router should send the messages to both SMs where the resources with same priority are bound, they will know what to do with them. What about iq and/or presence? - iq-get would get two responses then - presence-subscribe could get both accept and deny, which to use? This would cause problems only if the message is sent to user@domain. And in that case, the link I've posted (rfc3921) says that for IQs the server should reply with an error on behalf of the user. And For presence stanzas other than those of type probe, the server MUST deliver the stanza to all available resources; I suppose that in the latter case the response includes the full JID...? -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 17/09/2012 13:10, Tomasz Sterna a écrit : Again. There is 'u...@example.com/foo' resource with priority 1 bound on sm1. There is 'u...@example.com/bar' resource with priority 1 bound on sm2. 1. There is an incoming iq-get request for u...@example.com vCard. - it is being sent to sm1 and sm2 - sm1 and sm2 answers on behalf of the user - querying user gets two responses I see a possibility for this but it looks hackish...: router looks into the messages when there are more than 1 possible recipient component (in user@domain case). If it is an IQ = it generates the error itself. Or it passes the message to one of the component (at random) that will generate the error message... I'm not happy with these ideas, though... I'm still trying to think about a better solution. 1. Presence case - you're right. Presence packets are replicated to all resources, so we're good here. Ok. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-17, pon o godzinie 14:29 +0200, Alexandre Jousset pisze: I see a possibility for this but it looks hackish...: router looks into the messages when there are more than 1 possible recipient component (in user@domain case). If it is an IQ = it generates the error itself. Or it passes the message to one of the component (at random) that will generate the error message... I would like to keep the current separation, that router does not have to know XMPP-IM at all. It shouldn't be inspecting content of the package. Implementing XMPP-IM is a job of SM component (and C2S a bit). I'm still trying to think about a better solution. What's wrong in pinning all user sessions to one SM instance?
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 14/09/2012 16:08, Tomasz Sterna a écrit : Let's say, that we won't allow several SM instances handle resources of the same user. How? This needs tiny modification of C2S/SM protocol. Instead sending the user session creation request to the user domain, let's send it to the user bare-JID. This way if there is no session for u...@example.com bound on example.com SMs, router will revert to routing by domain and will pick up one SM at random. Then this SM will bind 'u...@example.com' name and all subsequent user sessions will be created with this SM. So there will be no need for communication between SMs. (There is a possibility of race - handling several session creation requests by router and pushing to several random SMs, before first one binds user bare JID.) This case could be resolved if the router auto-binds the user@domain route. There could still be problems if there are more than one router. But that case (2+ routers auto-binding user@domain at the same time) could be fixed by the conflict resolution we thought before, just by canceling all the binds for user@domain...? What do you think? -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-17, pon o godzinie 17:25 +0200, Alexandre Jousset pisze: (There is a possibility of race - handling several session creation requests by router and pushing to several random SMs, before first one binds user bare JID.) This case could be resolved if the router auto-binds the user@domain route. There could still be problems if there are more than one router. But that case (2+ routers auto-binding user@domain at the same time) could be fixed by the conflict resolution we thought before, just by canceling all the binds for user@domain...? What do you think? Brilliant idea! Works for me. I would just make it temporary and extend it to all routing levels. Whenever the router makes a (random) decision to choose one of equal binds to route to, it sticks to this decision for a predefined time.
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 14/09/2012 21:17, Tomasz Sterna a écrit : There is nothing in XMPP about delivering to most recent resource. I would like to stick to the specification :-) Sorry, I mixed the notions of binding and delivering :-( -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 16/09/2012 21:54, Alexandre Jousset a écrit : Le 14/09/2012 21:17, Tomasz Sterna a écrit : There is nothing in XMPP about delivering to most recent resource. I would like to stick to the specification :-) Sorry, I mixed the notions of binding and delivering :-( Err... Sorry again, but in case of delivery I've found that: http://xmpp.org/rfcs/rfc3921.html#rules (see 11.1.4.1 for messages)... This page was what I saw before posting my solution (I remember now). Anyway, it is for messages, where one can deliver them to *all* with same priority without ACK problems and there are other treatment (see same URL) for other types of stanzas. Am I still wrong and mixing things or...? ;-) -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Hi, Le 13/09/2012 16:15, James Wilson a écrit : I've been watching this discussion unfold and thought I might contribute. Thanks for your contribution. Personally, I have not ran a jabberd2 instance in a long time, but this question below: On 13/09/2012, at 11:35 PM, Tomasz Sterna wrote: Dnia 2012-09-13, czw o godzinie 15:07 +0200, Alexandre Jousset pisze: But then - what happens if two resources of the same priority get connected to two different sm instances? *This* was my real question ;-) I don't have answer. Will have to think about it. leads me to believe that they should act like so: [...] I don't know if this would work in practice, but this is one way I see the issue of the above question being resolved. I don't know what Tomasz thinks about this, but I think it is quite complicated for just that case. I was thinking about another idea: AFAIK the protocol says that in that case the message should either be duplicated, and we've seen previously that this may lead to problems (IQs, ACKs), or sent to one of the recipients based on the implementation's choice. Maybe we can just record the time when the session was started and add this information to each related bind request, keep at router level that information in the hash table values' structure, and use it in that case. The message would then be delivered to the recipient of the most recently started session. ...? -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-14, pią o godzinie 00:15 +1000, James Wilson pisze: It should be noted this is a hair-brained idea that has no testing or code to back it up. 1) Lets just say that, for arguments sake, you have an SM instance setup within the cluster that says: I will accept ONLY high-priority resources I agree with Alexandre that this is a bit too complicated. The beauty of the idea we are discussing is that it takes only router to take the burden of clustering and meshing. There is no need to make other components involved and participating. But... Your idea planted some seed and I think I came up with something. Let's say, that we won't allow several SM instances handle resources of the same user. How? This needs tiny modification of C2S/SM protocol. Instead sending the user session creation request to the user domain, let's send it to the user bare-JID. This way if there is no session for u...@example.com bound on example.com SMs, router will revert to routing by domain and will pick up one SM at random. Then this SM will bind 'u...@example.com' name and all subsequent user sessions will be created with this SM. So there will be no need for communication between SMs. (There is a possibility of race - handling several session creation requests by router and pushing to several random SMs, before first one binds user bare JID.)
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 14/09/2012 16:08, Tomasz Sterna a écrit : [...] (There is a possibility of race - handling several session creation requests by router and pushing to several random SMs, before first one binds user bare JID.) This race condition, in theory, has small probability to happen, but actually I see some cases where it is possible (e.g. c2s crash and / or restart, some network problems...), especially with a lot of users and auto-reconnecting clients. What exactly will happen if this race condition occurs? I think it may be complicated too to recover from it. You haven't told your opinion about my idea...? Its advantage is that there could not be such race condition. The drawback is just that SM needs to keep track of session start time (which may be already the case, I haven't checked) and to send it on each of this session related bind. In any case SM has to be patched at least to implement the new binding algorithm, so this addition would be just a small change. What do you think? -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-14, pią o godzinie 15:50 +0200, Alexandre Jousset pisze: I was thinking about another idea: AFAIK the protocol says that in that case the message should either be duplicated, and we've seen previously that this may lead to problems (IQs, ACKs), or sent to one of the recipients based on the implementation's choice. Maybe we can just record the time when the session was started and add this information to each related bind request, keep at router level that information in the hash table values' structure, and use it in that case. The message would then be delivered to the recipient of the most recently started session. But the only parameter to take into consideration when deciding which resource gets the message is priority. There is nothing in XMPP about delivering to most recent resource. I would like to stick to the specification :-) -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-14, pią o godzinie 17:10 +0200, Alexandre Jousset pisze: This race condition, in theory, has small probability to happen, but actually I see some cases where it is possible (e.g. c2s crash and / or restart, some network problems...), especially with a lot of users and auto-reconnecting clients. What exactly will happen if this race condition occurs? I think it may be complicated too to recover from it. But there is a chance. And like you said it messes things up badly. If we go this route (and it looks very appealing), we may need to come up with an idea how to prevent it. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 13/09/2012 00:05, Tomasz Sterna a écrit : [...] Looks simple. Too simple? ;-) It's never too simple :-) I think that, as you said before, the current implementation was designed open enough to be adapted and that will greatly simplify the coding of these new features. In real life the incoming part of the split would get disabled parts already handled on the accepting part, and all disconnected sessions would have to cope. Err... I'm not sure I understand this one. Sorry if my English and / or understanding is too bad :-/ BTW I have another question. AFAIK the routing to a domain is done only from c2s to sm when a user connects. Then the sm answers with the domain in the from part and gives its ID too for further communication. So, after this moment c2s knows to which component it should send messages for that user session. My question is: is this the only case where the routing to a domain is needed? If yes, in case of domain routing (e.g. when to is example.com) one should only route to one of the bound component serving that domain, maybe randomly. If no, ...? That is not the same as routing to u...@example.com without resource because in that case we said we should duplicate the message to all components bound to this user (whatever their resources). -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-13, czw o godzinie 13:45 +0200, Alexandre Jousset pisze: AFAIK the routing to a domain is done only from c2s to sm when a user connects. Then the sm answers with the domain in the from part and gives its ID too for further communication. So, after this moment c2s knows to which component it should send messages for that user session. My question is: is this the only case where the routing to a domain is needed? The other case is communicating with the jabber server (sm) itself. You can disco the domain to see the server features. You can xmpp-ping the domain, you can even get server presence (it has some resources answering). If yes, in case of domain routing (e.g. when to is example.com) one should only route to one of the bound component serving that domain, maybe randomly. If no, ...? Not randomly. To the highest priority bind. But what happens if there are many binds of the same priority? Cannot do randomly, as messages need to go to all highest priority resources. Cannot do all, as iq requests would get response many times. That is not the same as routing to u...@example.com without resource because in that case we said we should duplicate the message to all components bound to this user (whatever their resources). Not all. I suggested that the priority of the bare-JID bind should be equal to the highest priority resource connected to sm. But then - what happens if two resources of the same priority get connected to two different sm instances?
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Le 13/09/2012 14:57, Tomasz Sterna a écrit : Dnia 2012-09-13, czw o godzinie 13:45 +0200, Alexandre Jousset pisze: AFAIK the routing to a domain is done only from c2s to sm when a user connects. Then the sm answers with the domain in the from part and gives its ID too for further communication. So, after this moment c2s knows to which component it should send messages for that user session. My question is: is this the only case where the routing to a domain is needed? The other case is communicating with the jabber server (sm) itself. You can disco the domain to see the server features. You can xmpp-ping the domain, you can even get server presence (it has some resources answering). If yes, in case of domain routing (e.g. when to is example.com) one should only route to one of the bound component serving that domain, maybe randomly. If no, ...? Not randomly. To the highest priority bind. Yes, sorry, I meant randomly between components bound with same priority. But what happens if there are many binds of the same priority? Cannot do randomly, as messages need to go to all highest priority resources. Cannot do all, as iq requests would get response many times. See above. That is not the same as routing to u...@example.com without resource because in that case we said we should duplicate the message to all components bound to this user (whatever their resources). Not all. I suggested that the priority of the bare-JID bind should be equal to the highest priority resource connected to sm. Yes, sorry again, I meant with taking priority into account. But then - what happens if two resources of the same priority get connected to two different sm instances? *This* was my real question ;-) -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-13, czw o godzinie 15:07 +0200, Alexandre Jousset pisze: But then - what happens if two resources of the same priority get connected to two different sm instances? *This* was my real question ;-) I don't have answer. Will have to think about it. -- /\_./o__ (/^/(_^^' ._.(_.)_
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Hi everyone, I've been watching this discussion unfold and thought I might contribute. Personally, I have not ran a jabberd2 instance in a long time, but this question below: On 13/09/2012, at 11:35 PM, Tomasz Sterna wrote: Dnia 2012-09-13, czw o godzinie 15:07 +0200, Alexandre Jousset pisze: But then - what happens if two resources of the same priority get connected to two different sm instances? *This* was my real question ;-) I don't have answer. Will have to think about it. leads me to believe that they should act like so: It should be noted this is a hair-brained idea that has no testing or code to back it up. 1) Lets just say that, for arguments sake, you have an SM instance setup within the cluster that says: I will accept ONLY high-priority resources and all the cluster SM instances take note of this. 1) The resources connect and are given the same priority and connected to two different SM instances (let's say SM-1 and SM-2) 2) SM-1 and SM-2 communicate with the high-priority (HP) SM manager (SM-HP) when the new resources connect. A simple message might be: Hey there, it appears that I have a resource with priority A (highest). Here it is: (RESOURCE). Bye 3) SM-HP responds to both SM-1 and SM-2 and informs that: Please tell the client to reconnect to ME if possible, with this token: (A UNIQUE TOKEN). Otherwise, could you please forward ALL information to me AS SOON AS you get it. Bye. 4) SM-1 and SM-2 then proceed to inform the resources that: There exists a high-priority server at this address: 1.2.3.4 that you must reconnect to, if possible, using this token: (THE UNIQUE TOKEN). 5a) Resource-1 (connected to SM-1) supports this and would automatically reconnect to SM-HP without actually informing the user that they have 'disconnected' - rather it would log that a High-Priority Server exists at this address and automatically reconnected to it. 5b) Resource-2 (connected to SM-2) does not support this and responds with a message like: Oops, I have no clue what you are on about. (or similar) to SM-2; this means that SM-2 must now respect SM-HP's request and forward all traffic/activity to SM-HP WITHOUT interference and with the highest priority. SM-2 tells SM-HP this is the case and to expect a lot of HP traffic from SM-2, Resource-2. -- In the event that the SM-HP server (or process) dies, this might happen: 1) All the other SM's in the group may realise this and broadcast to each other and ask: Hey, is there a High-Priority server around here? for a duration of 30 seconds (for argument's sake). 2a) If a response from another SM-HP server is given, then all HP traffic/connections/resources are forwarded (or reconnected) to it. 2b If, at no point, a response is given, each server waits a random time and then announces that it intends to become a High-Priority server. 3a) All other SM's stop waiting and inform the new SM-HP in-waiting to proceed and become the new SM-HP server. 3b) If a 'collision' of announcements is detected, then all servers reset their timers and start again, with the offending servers adding a penalty time to their countdown period. I don't know if this would work in practice, but this is one way I see the issue of the above question being resolved. -James
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-12, śro o godzinie 20:22 +0200, Alexandre Jousset pisze: How do you recover from this split when parts get reconnected? :-) Well, why not behave as if it was a normal bind? I haven't thought a lot about it, I definitely need to do it, but in my first thoughts there can be collisions on JID's resource parts. This is why I asked if the resource could be renamed *after* a session is started...? You're right. We might have resource level collisions on daily basis. If 'u...@example.com/foobar' connects to two different c2s we need to detect it at the router level. Currently we do it on c2s level by generating new resource: https://github.com/Jabberd2/jabberd2/blob/master/c2s/c2s.c#L297 and sm level by disconnecting previous session: https://github.com/Jabberd2/jabberd2/blob/master/sm/sess.c#L144 https://github.com/Jabberd2/jabberd2/blob/master/c2s/c2s.c#L1135 We would need to modify sm to react on router denied bind and disconnect c2s session. We could have bind-revoked messages in the protocol. If the target of bind-revoked message is user JID we disconnect the user session (or all sessions if bare-JID). If it is sm itself (via bound domain name) we shutdown domain handling in sm. If it is the component name itself, we shutdown the component. Looks simple. Too simple? ;-) In real life the incoming part of the split would get disabled parts already handled on the accepting part, and all disconnected sessions would have to cope. In case of user sessions - the client usually just reconnects. (To already fixed mesh.) -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-10, pon o godzinie 19:40 +0200, Alexandre Jousset pisze: with separate set of 'ad...@example.org/something' full-JIDs. Ok for this. I'll use linked lists, which will be pretty small after all (and ordered, too). Or you can just stick to one routing table for all connected components and routers in one xhash. Should be simple and work fine. Of course I'll try to minimize the changes. Anyway, as in my previous attempt I've set up 2 options for the configure script: --enable-adaptive-routing and --enable-cluster (= should I change this last one to --enable-router-mesh? ;-) ) that activate these functionalities that should be marked as experimental for a while. Just drop it. It makes no sense in maintaining two separate routing strategies. The one we are talking about should work as good as the current implementation in simple deployments with just single router component. thought why not use a single flat hash table that could be used as a tree as well?. It's a detail but I think it simplifies some implementation details. Yeah. Why not. :-) I like this idea. Greatly simplifies the implementation. So ie. for incoming packet to 'ad...@example.com/foobar' you would look for component/router bound to 'ad...@example.com/foobar', if not found look for 'ad...@example.com', if not found look for 'example.com', if not found use default route (look for component binding '' ?) This way a router connected to another router can be seen, for the routing purpose, as a normal component. What do you think about this? Yes. I like the idea. So, in the hash table values structure, one can store a linked list of possible routes (which is a structure containing a component_t, a priority and a next pointer) sorted descendant by priorities, and an enum containing the request type for this entry (domain, bare JID or full JID). Right. About the default route(s), they could be stored in the hash table using the same schema (using a special hash key), so there could be more than one default route (with, e.g., a constraint about not being possible to have 2 default routes with same priority). I would just bind (empty string) or null and use the same hash-table. Components like sm and c2s could be stored the same, using just the domain part of the JID, as it is the case now. Components have its own names. Each component needs to be uniquely named. If we would enforce the rule, that component names cannot contain dot (.) we would minimise possibility for collision with domain name. [...] Just a note about the routing table sharing, when a component is requested to send binds for all its sessions, this could be done in a bulk way. Same for unbinding. And this bulk could be forwarded as-is to other connected routers. This is the easy part. The real issue is when you have a working mesh that got split in two parts and worked for some time independently. How do you recover from this split when parts get reconnected? :-) But I would leave the answer to this question for later. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/portfolio
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Hello, Le 03/09/2012 18:10, Tomasz Sterna a écrit : I didn't get to designing routing exchange protocol yet. Building a working implementation of adapting binding of components should shine some light on what is required to be exchanged. Ok. I started to look at the process you sent earlier, and I could start to think about the tree structure just by following the process. That led me to have to ask some questions about this: 1) A minor one: is it right that it's a typo when you wrote example.org instead of example.com at some places? 2) Is is OK to assume that all non full-JIDs are of priority 0 (or, better said, have no priority at all)? 3) I have a doubt when you say at different places that a component needs to bind bare-JIDs / full-JIDs from now on. Does that mean that it needs to send bind requests for all sessions it already has, or just make *new* bind requests of the type you mentioned? 4) In this process, what if component1 disconnects? I suppose that the router needs to crawl through its tree to update it, but that can be CPU intensive and can cause lags... I know that this event is not a normal event anyway and is not supposed to happen often, so it can be negligible. 5) A Jabber protocol question, I know I could find the answer in the online docs, but as I have you at hand ;-) Is it possible to have 2 full-JIDs connected at the same time? With equal or different priorities? I suppose the answer is no to both questions, but just to be sure... 6) The tree structure I'm thinking about uses hashes to find the next node (root = domain = user = resource), and finally a pointer or an array of pointers to components for the leaves. If the answer to previous questions at 5) is no, there is only one case where there can be more than one leaf: at each node is a default route leading to one or more components. If I use a static sized array to store them, that will use more memory. So the best would be to use a linked list, but that would make the process slower. I would tend to use linked lists because the cases where one has to crawl through them are (relatively) less frequent. What do you think? That's it for the questions. I you need I could draw a diagram of the tree structure I'm thinking about to make things clearer, just tell me. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Hm, I answer to myself, after thinking some more ;-) Le 05/09/2012 21:04, Alexandre Jousset a écrit : 1) A minor one: is it right that it's a typo when you wrote example.org instead of example.com at some places? Obviously, yes. 2) Is is OK to assume that all non full-JIDs are of priority 0 (or, better said, have no priority at all)? Obviously, yes. 3) I have a doubt when you say at different places that a component needs to bind bare-JIDs / full-JIDs from now on. Does that mean that it needs to send bind requests for all sessions it already has, or just make *new* bind requests of the type you mentioned? I think the component has to send all its already online sessions. And I think this can be a hint for the routers' synchronisation in multi-router implementation. In a multi-router implementation, why not consider a router as a more or less normal component (when connected to other routers)? With one exception, that when a random has to be chosen between components, only the local components have a chance. I have to think more about this... 4) In this process, what if component1 disconnects? I suppose that the router needs to crawl through its tree to update it, but that can be CPU intensive and can cause lags... I know that this event is not a normal event anyway and is not supposed to happen often, so it can be negligible. 5) A Jabber protocol question, I know I could find the answer in the online docs, but as I have you at hand ;-) Is it possible to have 2 full-JIDs connected at the same time? With equal or different priorities? I suppose the answer is no to both questions, but just to be sure... Obviously, no. 6) The tree structure I'm thinking about uses hashes to find the next node (root = domain = user = resource), and finally a pointer or an array of pointers to components for the leaves. If the answer to previous questions at 5) is no, there is only one case where there can be more than one leaf: at each node is a default route leading to one or more components. If I use a static sized array to store them, that will use more memory. So the best would be to use a linked list, but that would make the process slower. I would tend to use linked lists because the cases where one has to crawl through them are (relatively) less frequent. What do you think? Stupid question: the case where there is multiple choice for components is only the domain case. So I can use a reasonnably configurable-at-compile-time sized array. -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Dnia 2012-09-01, sob o godzinie 00:21 +0200, Alexandre Jousset pisze: I didn't want to create huge routing tables too. c2s and sm are quite big memory consumers when many users are connected, I didn't want to make the router the same. But I'm afraid this is unavoidable. The good thing is that it doesn't make a difference in non-clustered environment. And if you want to go big and fancy - there's always some price to pay. As I'm not a lot used to the protocol(s), what kind of messages would you see possible to share the routing information? I didn't get to designing routing exchange protocol yet. Building a working implementation of adapting binding of components should shine some light on what is required to be exchanged.
Re: jabberd2 in cluster? ideas, proof of concept and questions...
Hi Tomasz, Thanks for your answer. I'll study your message in detail when I'll have time to. I think I'll be able to work on this topic during the week-end. Regards, -- -- \^/-- ---/ O \----- -- | |/ \| Alexandre (Midnite) Jousset | -- ---|___|-----
Re: Questions about component protocol and multi-user chat without subdomain
I always find this annotation as misleading. It tightens the current habbit of tightly binding services with servers. Yeah, that's the main thing about it that bothered me. The standards seem to encourage the use of sub-domains for naming services. The examples in XEP-0030 place each service on a sub-domain. I wonder if the standard could be updated to add some way of addressing services and components that doesn't require extra domains or sub-domains? ---BeginMessage--- Dnia 2011-01-31, pon o godzinie 23:23 -0800, Keith Jay Gillis pisze: A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of a Jabber server (e.g., conference.jabber.org). I always find this annotation as misleading. It tightens the current habbit of tightly binding services with servers. Is it possible to use mu-conference with jabberd2 without putting mu-conference on a sub-domain? It's perfectly possible to run a conference service on its own domain. It's domain name is nothing special and does not have to be a subdomain of jabber server. ie. I run my conference service and transports on a completely separate host, with only router and s2s components companion. Router to handle component protocol connections, and s2s to give the components network connectivity. I had hoped that a chat service and XMPP server could both have the same domain. But... If you want to share a single domain between different components, ie. a chat component and a session manager - it's not possible with jabberd2. This would require an application protocol level stanza routing which is not supported. In other words - router would have to inspect contents of every packet and decide which component the packet should be routed to. It is possible to do, but it's complicated and inefficient. I see from XEP-0045 that a chat service needs to have a JID to direct room queries to. Could it have a JID of confere...@example.com of example.com/conference instead of conference.example.com? Not possible. MUC encodes nicknames as resources. You need to run it on separate domain. Also, are there plans to make the jabberd2 component protocol an official extension? Kind of... Some elements of jabberd2 component protocol are on it's way to standardization. See XEP-0225 The rest is jabberd2 internal design specific and may not be that useful for other implementations. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/ -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com ---End Message--- signature.asc Description: This is a digitally signed message part
Re: Questions about component protocol and multi-user chat without subdomain
Hi Keith, I did some investigations on this topic last year. As far as I see it is not possible without rewriting the sm-component to pass some iq-stanzas to its clients. My approach was to write a component that binds to a dummy-domain and simulates a c2s-connection (e.g. the component starts a session in the designated domain) and then acts like a normal jabber-client. I managed it to do the session-stuff, but it seems that the sm does not pass IQ-stanzas to the bare JID (without ressource) to its clients, so techniques like Service-Discovery - which much heavily depends on - are not possible. Kind regards, Bernd Am 01.02.2011 08:23, schrieb Keith Jay Gillis: Hi, XEP-0045 defines a multi-user chat service as: A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of a Jabber server (e.g., conference.jabber.org). Is it possible to use mu-conference with jabberd2 without putting mu-conference on a sub-domain? Does often but not necessarily a sub-domain just meant that it could be on an entirely separate domain? I had hoped that a chat service and XMPP server could both have the same domain. I see from XEP-0045 that a chat service needs to have a JID to direct room queries to. Could it have a JID of confere...@example.com of example.com/conference instead of conference.example.com? Also, are there plans to make the jabberd2 component protocol an official extension? Thanks, Keith -- \\\||/// \\ - - // ( @ @ ) -oOo--( )--oOo--- tiggersWelt.net www.tiggerswelt.net Inhaber Bernd Holzmüller i...@tiggerswelt.net Tel: 07 11 / 550 425-90 Mönchstraße 25 Fax: 07 11 / 550 425-99 70191 Stuttgart OpenPGP/GnuPG: 0x957C378B -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Re: Questions about component protocol and multi-user chat without subdomain
Dnia 2011-01-31, pon o godzinie 23:23 -0800, Keith Jay Gillis pisze: A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of a Jabber server (e.g., conference.jabber.org). I always find this annotation as misleading. It tightens the current habbit of tightly binding services with servers. Is it possible to use mu-conference with jabberd2 without putting mu-conference on a sub-domain? It's perfectly possible to run a conference service on its own domain. It's domain name is nothing special and does not have to be a subdomain of jabber server. ie. I run my conference service and transports on a completely separate host, with only router and s2s components companion. Router to handle component protocol connections, and s2s to give the components network connectivity. I had hoped that a chat service and XMPP server could both have the same domain. But... If you want to share a single domain between different components, ie. a chat component and a session manager - it's not possible with jabberd2. This would require an application protocol level stanza routing which is not supported. In other words - router would have to inspect contents of every packet and decide which component the packet should be routed to. It is possible to do, but it's complicated and inefficient. I see from XEP-0045 that a chat service needs to have a JID to direct room queries to. Could it have a JID of confere...@example.com of example.com/conference instead of conference.example.com? Not possible. MUC encodes nicknames as resources. You need to run it on separate domain. Also, are there plans to make the jabberd2 component protocol an official extension? Kind of... Some elements of jabberd2 component protocol are on it's way to standardization. See XEP-0225 The rest is jabberd2 internal design specific and may not be that useful for other implementations. -- Tomasz Sterna Instant Messaging Consultant : Open Source Developer http://tomasz.sterna.tv/ http://www.xiaoka.com/ -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
Questions about component protocol and multi-user chat without subdomain
Hi, XEP-0045 defines a multi-user chat service as: A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of a Jabber server (e.g., conference.jabber.org). Is it possible to use mu-conference with jabberd2 without putting mu-conference on a sub-domain? Does often but not necessarily a sub-domain just meant that it could be on an entirely separate domain? I had hoped that a chat service and XMPP server could both have the same domain. I see from XEP-0045 that a chat service needs to have a JID to direct room queries to. Could it have a JID of confere...@example.com of example.com/conference instead of conference.example.com? Also, are there plans to make the jabberd2 component protocol an official extension? Thanks, Keith signature.asc Description: This is a digitally signed message part
Couple of configuration questions.
Hello. I have jabberd2 mostly up and running. Could somebody please clarify exactly which settings should be set to completely deny unencrypted client-to-server and client-to-client communications? Also, what's the simplest way to deny the setting of account passwords of less than a given length and/or complexity? Thanks, M -- To unsubscribe send a mail to jabberd2+unsubscr...@lists.xiaoka.com
