mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: [Vysper 0.7] Server-to-Server communication...
Date Mon, 13 Feb 2012 22:41:23 GMT
On 13.02.12 23:18, Marc Neeley wrote:
> Sure,
>     I'm addressing a Server-to-Server communication environment where
> connectivity may be a little more ad-hoc than typical resource-rich
> environments. Nodes (along with their domains) may come and go, so in order
> to keep some of the internal servers stable, the gateway would keep a steady
> connection to the vysper environment while negotiating ad-hoc connections on
> the other side. A vysper server, for example would likely not lose a network
> connection, but traffic like presence, etc. would behave as it should by
> appearing and leaving based on stanza frequency and established timeouts. So
> the path would look like:
>      XMPP Server(domain a)<-->  gateway (domain a)<-->  chaos<--> 
> (domain b)<-->  XMPP Server(domain b)

ok, I think I'm starting to understand.
Your intention is to put a proxy in front of Vysper which is more 
capable of handling the kind of network situation you are experiencing 
or prepare for.

>    Now my original question was is there a particular area of the vysper
> distribution that I could look at that would help me with the XMPP side of
> the gateway to implement a proper connection and handshaking to establish
> what would typically be a normal XMPP -to- XMPP interaction?  I'm not as
> familiar with XMPP as I am with other integration technologies yet, so
> that's why I'm asking.

I would start looking into the following packages:

I would also try to debug through an actual regular connection handshake.


> Thanks,
> Marc
> -----Original Message-----
> From: Bernd Fondermann [mailto:bf_jak@brainlounge.de]
> Sent: Monday, February 13, 2012 3:58 PM
> To: dev@mina.apache.org
> Subject: Re: [Vysper 0.7] Server-to-Server communication...
> On 13.02.12 16:09, Marc Neeley wrote:
>> Bernd,
>>     Thanks for clearing me up on this. You are correct concerning the
>> separate routing based on the local domain (pub/sub) vs s2s (remote
>> domain) and I was not separating the two correctly in my thinking.
>>     Ultimately what I am experimenting with is XMPP server federation,
>> so I am only concerned with remote domain conditions. I realize that
>> is currently supported via XMPP in Vysper in the s2s implementation,
>> but I am working with some gateway type functionality that I would
>> like the Vysper server to attach to rather than to another Vysper
>> server directly. Is there a straightforward handshaking routine that
>> is in the implementation now that my server could comply to initiate the
> connection?
> Can you elaborate a little bit more on your use case? I'm still struggeling
> with understanding what "gateway" would mean. Do you want anything like
> intercepting, forwarding, listening into, processing etc.
> incoming/outgoing stanzas?
>> Thanks again for answering my questions.
>> Marc
>> -----Original Message-----
>> From: Bernd Fondermann [mailto:bf_jak@brainlounge.de]
>> Sent: Monday, February 13, 2012 4:36 AM
>> To: dev@mina.apache.org
>> Subject: Re: [Vysper 0.7] Server-to-Server communication...
>> On 09.02.12 16:19, Marc Neeley wrote:
>>> Niklas,
>>>      Thanks for the reply. I did run across the XEP-0114 spec and
>>> discussion online, but it has been unclear to me how  s2s vs. non-s2s
>>> traffic is separated for any given implemented component.
>> Should it be separated. In short each server is handling only stanzas
>> targeted for his own domain plus subdomains, every stanza for other
> domains
>> must either be rejected, or send to the authorized server via s2s.
>>> For example, if I don't
>>> enable s2s as shown in the Vysper docs then can I then use say the
>>> XEP-0060 Pub/Sub implementation  for s2s instead? I didn't know, for
>>> example, if things like dialback would only be active and sent if the
>>> s2s configuration is turned on and thus, the XEP-0060 implementation
>> wouldn't see it.
>> Maybe I'm not getting you right, but these are separate issues. pub/sub
>> requests for [pubsub.]mydomain.com must be handled by the server handling
>> mydomain.com stanzas. If client me@mydomain.com request to subscribe to a
>> topic on pubsub.some-other-domain.com, this request can't be fulfilled by
>> mydomain-server anyway (it can only be relayed). If s2s is enabled, the
>> subscription request would be relayed to some-other-domain.com, otherwise
> it
>> would be rejected by mydomain.com-server (because this server is
> responsible
>> for relaying, but s2s is turned off). This is unlike HTTP where any client
>> can connect to any server: XMPP clients must go through their servers to
>> other servers.
>> Did this match your question?
>>     Bernd
>>      Thanks
>>> again for the reply and any other thoughts would be appreciated.
>>> Marc
>>> -----Original Message-----
>>> From: Niklas Gustavsson [mailto:niklas@protocol7.com]
>>> Sent: Thursday, February 09, 2012 1:56 AM
>>> To: dev@mina.apache.org
>>> Subject: Re: [Vysper 0.7] Server-to-Server communication...
>>> On Thu, Feb 9, 2012 at 3:52 AM, Marc Neeley<neeleym@ociweb.com>    wrote:
>>>>     Can anyone tell me what XMPP specs focus on the server-to-server
>>>> communication portion of a distributed chat deployment and if Vysper
>>>> would allow that portion of the server to be extended with a
>>>> different implementation of the communication? So if I had a Vysper
>>>> server and a non-Vysper server running on different nodes and need to
>>>> communicate between them, is there an extension spec I should be
>> considering?
>>> Vysper supports server-to-server communication as described in the
>>> XMPP RFCs and server dailback (http://xmpp.org/extensions/xep-0220.html).
>>> If the non-Vysper server is an XMPP server, regular S2S should work for
>> you.
>>> If not, you might want to check out the component protocol
>>> (http://xmpp.org/extensions/xep-0114.html) for which there is a branch
>>> in Vysper with some basic support.
>>> /niklas

View raw message