Le 21/01/2018 à 16:24, Tomasz Sterna a écrit :
W dniu nie, 21.01.2018 o godzinie 15∶01 +0100, użytkownik Alexandre
Jousset napisał:
[...]
I don't know if I'm skilled enough but instead of letting it
die, I would like to become the maintainer if nobody with better
skills wants
most is allowing multiple routers and Session Managers (SM) on a single domain
name to make jabberd2 service more resilient/easily scalable. I think that
works fine with multiple c2s already (I'll try this in the upcoming days).
- I think the branch made by Alexandre Jousset has not been merged
Hi Tomasz, hi all,
FYI I'm still working (when possible, mainly on my spare time) on this
feature, even if I'm quite silent.
I could say that I'm at ~70% of code modifications, the remaining 30%
are the remote routers management, i.e. connections / disconnections /
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
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
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
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
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 «
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
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
Le 12/10/2012 10:42, Tomasz Sterna a écrit :
There is a SMACK-324 [1] bug affecting a lot of Java client applications
(including most Android clients).
It would be trivial to work around it in jabberd2 codebase, but it just
doesn't feel right.
From practical point of view: There is a trivial
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
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
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
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
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
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
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.
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 :-(
--
-- \^/--
---/
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
, 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
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
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
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
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
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
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
27 matches
Mail list logo
