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<--> gateway
(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:
/server/core/src/main/java/org/apache/vysper/xmpp/server
/server/core/src/main/java/org/apache/vysper/xmpp/server/s2s
I would also try to debug through an actual regular connection handshake.
Bernd
Thanks,
Marc
-----Original Message-----
From: Bernd Fondermann [mailto:[email protected]]
Sent: Monday, February 13, 2012 3:58 PM
To: [email protected]
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:[email protected]]
Sent: Monday, February 13, 2012 4:36 AM
To: [email protected]
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 [email protected] 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:[email protected]]
Sent: Thursday, February 09, 2012 1:56 AM
To: [email protected]
Subject: Re: [Vysper 0.7] Server-to-Server communication...
On Thu, Feb 9, 2012 at 3:52 AM, Marc Neeley<[email protected]> 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
