I’'m attempting to get S2S to work, but am running in to some roadblocks.
I’‘m running the June 7th nightly build on a Linux box with Sun’'s Java 1.5. Port 5269 is now open and un-firewalled.
I did discuss this a bit with Gato during the chat session, but it ended about the same time I got the AOL-style boot, so I wasn’'t able to finish.
I’‘m able to receive remote messages from people on other servers without any problems at all. However, I am unable to send messages to other servers. It is as though they are /dev/null’'d.
When I receive messages from other servers, I see the dialback information in the debug log, and all is good. When I try and send messages to users on other servers, I see nothing at all in the debug log - it is as though the message were never sent.
Any ideas? Where do I go from here? I am available to work on this real-time on and off during the day if somebody wants to debug it with me.
Is the remote server running ejabberd? Looking at http://paste.axpr.net/?show=182 I can see that JM is trying to initiate a connection to ursine.ca (first 3 lines) and then ursine.ca makes a connection back to you server (forth line). The problem is that the remote server is not trying to authenticate the domain but to establish an incoming connection. That’'s why you have RS (Receiving Server) in lines 5-11 instead of AS (Authorative server). So if the remote server never authenticates your outgoing connection you will not be able to send messages to that server.
I don’‘t know what the Ursine server is running… I just know it isn’'t written in Java (is eJabberd?).
However, it is one of three servers I have been unable to send messages to. I’'ve attempted to send messages to myself on jabber.org and xmpp.us, as well. Jabber.org is most certainly running Jabberd, either 1.4.x or 2.0.x.
Additionally, when I attempt to send a message to a user on another server, I see absolutely nothing in the debug log. It is only when somebody on another server sends me a message that information appears in the debug log.
The timeout that you are seeing is related to the original problem where the remote server is not trying to authenticate with JM but to establish a new incoming connection. Therefore, JM will wait for a minute for the remote server to answer if the outgoing connection (from JM to the remote server) is ok. Since the remote server is not replying then you are getting the timeout.
However, you should be able to exchange packets with jabber.org. Could you paste the debug log when connecting to jabber.org and when receiving a connection? Remember to wait a couple of minutes when dealing with jabber.org!!!
Sometime overnight it finally kicked in and got the messages through. Additionally, the Ursine.CA server finally kicked in and is also able to receive messages from the Slacksec.org server.
Something is definitely wrong here. Is anybody else testing S2S?
Surely you’'re seeing similar behaviour?
Jive is having a very difficult time establishing server connections with other servers. It seems to be timing out too easily, judging from my logs. It’‘s now reliably able to connect with jabber.org two-way after a half hour or so, but other smaller servers not so much. One I’'ve been trying to connect to most of the day.
ARE other people testing this out with random servers? If not, c’'mon guys… time to get testing.
Something is definitely wrong here. Is anybody else
testing S2S?
Good question. We’'ve been using s2s at jivesoftware.com without major issues. So far we know that JM is not getting along with ejabberd since ejabberd is not dialing back to authenticate but creating a new incoming connection instead. Today I tried with jabberd2 and never got a dialback either though this time no connection was made from the remote server to JM.
Jive is having a very difficult time establishing
server connections with other servers. It seems to
be timing out too easily, judging from my logs. It’'s
now reliably able to connect with jabber.org two-way
after a half hour or so, but other smaller servers
not so much. One I’'ve been trying to connect to most
of the day.
Download tomorrow’'s nightly build where you will be able to configure the read timeout. Currently a default of 60 seconds is being used. You will need to define the xmpp.server.read.timeout property with the number of milliseconds to wait. Notice that using very high timeout values may potentially block user connections that are trying to reach the same remote server.
ARE other people testing this out with random
servers? If not, c’'mon guys… time to get testing.
The Receiving Server establishes a TCP connection back to the domain name asserted by the Originating Server, as a result of which it connects to the Authoritative Server. (Note: As an optimization, an implementation MAY reuse an existing connection here.)