In the latest nightly build you will find a beta version of server-to-server and also of external component support. Many changes have been made to the code in particular to roster and presence management. We are now following the XMPP spec with almost an exact accuracy. Therefore, it should be now possible to run a gateway to ICQ, MSN, yahoo, etc. as an external component of JM. I didn’‘t have time to test any gateway but I’'m very confident of the outcome. Attached to this email you will find some screenshots of the admin console with the new s2s functionality.
And to make things more fun…I’'m going to give away points to the first users that report any problem with these new functionalities.
I have already tested with the May 29th nightly build, and I managed to connect 2 Jive servers without any problem. But I missed the “admin console” part of it so i’'ll try the new one…
Thanks for the great work, with S2S Jive Messenger becomes a really good and easy to use jabber server.
Do you have s2s configuration information anywhere? I couldn’'t find anything in the admin console to configure remote servers. I also searched the documentation in the nightly build.
Jive Messenger will use port 5269 to listen for server connections and to establish connections to remote servers. Currently there isn’'t much to configure in the admin console except for the port to use for s2s. We are planning to add white/black lists of remote servers and also an idle timeout for closing idle connections.
What other kind of information where you looking for?
I was looking for what system properties I need to set to activate the s2s and how to maybe tell it which direction. Our organizatiion is already using Jive Messenger at 2 sites. We are very excited at testing the s2s so we can deploy it to our production systems at the soonest so we can stand up more servers.
Currently, out-of-the-box JM will automatically start listening for server communications at port 5269 and will try to establish a communication to a remote server if a packet should be sent to a domain that is not the local server’'s domain. So the direction (incoming or outgoing) is handled automatically by JM.
In the main page of the Admin Console you can find the ports that the server is currently listening to. If you are using the latest version then you should see 4 ports (5269, 10015, 5222 and 5223). You can turn on the debug log so you can trace the s2s dialog between the servers.
If you want to disable the s2s feature then you should set the property xmpp.server.socket.active to false.
looks very interesting though we wount use it anyway:)
Incoming Session. Does it only receive packets? If so, so there must be only “Received packets” column header and no slash and zero in numbers. Same with Outgoing Session. Maybe i’‘m wrong about this, i dont know how it works. But you see how i’‘m trying hard to earn some points? Ok ok, it’‘s not a problem but i’'m always too picky about GUI:)
Below are the packets captured on the remote client connected to a remote server. I sent them from my login on host86 to admin on host183. The client received the packets, but did not change the presence or display the message from ebragg. Is there anything wrong with the packets? I am using PSi to send/receive as you can see.
I also noticed that authorization request would did not go through until I went offline then back online again. I wish I had captured those packets now. I could, if it would help.
I am unsure on how to “link” these 2 servers? Do the servers automatically link to each other when a server tries to communicate a user from one server to the other?
You are correct in your assumption. The server will create an outgoing connection to a remote server every time a packet needs to be sent to a domain that does not match the domain of the local server. So if a remote server needs to send a packet (of any type) whose domain matches your local domain then the remote server will create a connection to your server thus generating an incoming connection (from the point of view of your local server) from the remote server.
Are you running Jive Messenger in both servers? If not which servers are you using and where is JM running? Could you turn on the audit log to trace the packets being sent and received?
If you are just sending a message from a user to another user, no presence tracking will occur. That means that the users will not see the presence of each other. Moreover, the other user will not appear in the user’'s roster.
However, if you are sending presence subscriptions then I will ask you to try using the Exodus client to discard the client variable. I don’'t know Psi but some clients sometimes do not show presence subscription requests until you log in again.
Yes, both servers are Jive Messenger 2.20 beta (31 July nighly build). I’‘ve got audit logging activated on both servers so getting the logs shouldn’‘t be a problem. Note the packets I pasted before were from the client xml console as the messages came in. Unfortunately, it’‘s past the end of my work day, so I’‘ll have to continue tomorrow. I’‘ll try to track down a duplication of my issue with audit logs on the server. I’'ll also try my exodus client to see if I see the same issue.
s2s connections to servers such as coversant.net aren’‘t working because we’'re not doing DNS lookups for SRV records in all cases. In the case of coversant.net, I believe the server should resolve to a subdomain.
Server to server sounds great/nice/ - but some more details would be nice… What kind of S2S is supported? Is the link encrypted? Is sasl supported? Does dialback work? I’‘m in no way an expert, but I’‘ve seen some discussions about encrypted S2S links on various jabber mailing lists lately and I’'m curious what you are going to implement here.
Thanks for your input. Since our primary goal was to be able to interact with other servers then we decided to follow the most widely use method that is plain sockets (no encryption) with dialback. I think that is the lowest common denominator between all servers. Future versions will add support for encrypted links and/or sasl. As you have read on jdev forums using sasl for s2s is still an issue that needs to be figured out in a nice way.
Are there any plans to allow for Server To Server communication within the same Domain? We have multiple Domains that we would like to implement S2S with, but we share a Domain with a remote location via a VPN and would like to have a seperate server at each of the locations. Will this be possible in the future or will we be forced to share a single server on one Domain? Reading through the posts it seems that is the way S2S has been implemented thus far.
If I understand you right, your are talking about a cluster… A single virtual server with two real machines at both of your locations. That’‘s not what S2S does/can do (Anyone correct me, if there’'s a magic way).
You could of course use location1.yourdomain.tld and location2.yourdomain.tld… But that’'s still not the same, users are still local to one of those servers for example.
What you want is currently only possible with ejabberd, afaik. There are some discussions/threads related to clustering on this board, I’'m not sure what the final outcome was. I think it is still an interesting part/feature for the future.
Nice question. What we currently have implemented is server-2-server as defined by the XMPP spec where each server will have a different domain. On the other hand, a real clustering solution will let you have more than one server under the same domain and treat them as one logical server from the client point of view. There is another solution we’'ve been talking lately that involves having one server and many routers. The reasoning for that is that one server may handle at most 10K connections so having many routers where the users will connect to and in turn the router will connect to the server will let us have a very scalable solution. Moreover, the router idea can be used together with the clustering to achieve a HA solution and a scalable solution at the same time.
As I said we currently only have support for s2s and are planning to start working on the routing idea soon. The clustering solution is in our roadmap too but it’'s more a long term feature.
Regarding your requirement I think that you will be fine by creating a new hostname in your DNS and use a different domain for each server in each location. As I said this is not a clustering solution but will let you distribute the load in a manual way.
Let me clarify a bit more of my initial train of thought on this one. The idea was that in each location, we would have an independent server. So say we have three locations with server names of Loc1, Loc2, and Loc3, each in it’‘s own seperate domain. When a user at one of the domains logs into their client of choice, they log into their respected server, each with it’‘s own individual Host name… e.g. Someone at location 1 would sign in to server Loc1. That server, Loc1, will have it’'s own specific users, but utilizing S2S, they should be able to communicate with any of the users on Loc2 or Loc3. If my understanding is correct, S2S will accomidate this need.
Then you throw another server into the mix, Loc4, but this time it’'s within the same Domain as Loc1. I do not wish to cluster the servers to accomidate load or anything along those lines, but rather establish a S2S session with the other three servers. Perhaps my idea of S2S is skewed and I should be thinking more along the lines of Clustering?
Ok ok, it’‘s not a problem but i’'m always too picky about GUI:)