Re: Questions...

2016-04-14 Thread Adrian Reber
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...

2016-04-14 Thread Adrian Reber
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...

2016-04-14 Thread Matěj Cepl
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...

2016-04-14 Thread Adrian Reber
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...

2016-04-13 Thread John Oliver
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

2014-01-29 Thread Oriol Mula-Valls

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...

2012-10-26 Thread Alexandre Jousset

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...

2012-10-18 Thread Alexandre Jousset

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...

2012-10-15 Thread Tomasz Sterna
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...

2012-10-15 Thread Alexandre Jousset

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...

2012-10-15 Thread Tomasz Sterna
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...

2012-10-15 Thread Alexandre Jousset

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...

2012-10-15 Thread Alexandre Jousset

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...

2012-10-15 Thread Tomasz Sterna
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).

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.



-- 
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...

2012-10-15 Thread Alexandre Jousset

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...

2012-10-14 Thread Paul Tinson
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...

2012-10-14 Thread Alexandre Jousset

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...

2012-10-13 Thread James Wilson

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...

2012-10-12 Thread Tomasz Sterna
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...

2012-10-09 Thread Tomasz Sterna
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...

2012-10-09 Thread Tomasz Sterna
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...

2012-09-18 Thread Alexandre Jousset

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...

2012-09-18 Thread Tomasz Sterna
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...

2012-09-18 Thread Alexandre Jousset

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...

2012-09-18 Thread Alexandre Jousset

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...

2012-09-17 Thread Alexandre Jousset

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...

2012-09-17 Thread Tomasz Sterna
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...

2012-09-17 Thread Alexandre Jousset

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...

2012-09-17 Thread Alexandre Jousset

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...

2012-09-17 Thread Tomasz Sterna
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...

2012-09-17 Thread Alexandre Jousset

Le 17/09/2012 15:39, Tomasz Sterna a écrit :

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 know and I understand, this is why I said I didn't like these 
solutions. I thought about them because there are some cases where the router 
looks into the messages. Maybe not sending the error message but forwarding the 
message to only one SM could be possible without breaking too much that rule... 
But it's not perfect, I know.


 I'm still trying to think about a better solution.


What's wrong in pinning all user sessions to one SM instance?


Nothing, except race condition... I'm still thinking about how to 
resolve this issue too... It would be a much nicer solution I agree.
--
--  \^/--
---/ O \-----
--   | |/ \|  Alexandre (Midnite) Jousset  |   --
---|___|-----




Re: jabberd2 in cluster? ideas, proof of concept and questions...

2012-09-17 Thread Alexandre Jousset

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...

2012-09-17 Thread Tomasz Sterna
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...

2012-09-16 Thread Alexandre Jousset

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...

2012-09-16 Thread Alexandre Jousset

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...

2012-09-14 Thread Alexandre Jousset

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...

2012-09-14 Thread Tomasz Sterna
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...

2012-09-14 Thread Alexandre Jousset

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...

2012-09-14 Thread Tomasz Sterna
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...

2012-09-14 Thread Tomasz Sterna
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...

2012-09-13 Thread Alexandre Jousset

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...

2012-09-13 Thread Tomasz Sterna
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...

2012-09-13 Thread Alexandre Jousset

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...

2012-09-13 Thread Tomasz Sterna
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...

2012-09-13 Thread James Wilson
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...

2012-09-12 Thread Tomasz Sterna
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...

2012-09-11 Thread Tomasz Sterna
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...

2012-09-05 Thread Alexandre Jousset

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...

2012-09-05 Thread Alexandre Jousset

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...

2012-09-03 Thread Tomasz Sterna
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...

2012-08-31 Thread Alexandre Jousset

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

2011-02-04 Thread Keith Jay Gillis
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

2011-02-01 Thread Bernd Holzmüller (tiggersWelt.net)
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

2011-02-01 Thread Tomasz Sterna
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

2011-01-31 Thread 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


signature.asc
Description: This is a digitally signed message part


Couple of configuration questions.

2009-07-04 Thread jabberd2
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