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
