C2s, S2S, or enterprise clarification

Hello,

These questions may be redundant, but I can’t seem to find any clear threads or documentation. Here are my Questions/situation…

My original Openfire server is at a a centralized location where multiple satellite offices connect and everything works fine. The other day, our Co-location had an internet outage and I soon discovered that our employees have grown to rely on IM capabilities for quick communication. To stop such events from “slowing down” communication in the future, I was thinking about creating either a connection manager in each location or a separate Openfire server then using s2s so everyone can communicate.

End Goal: To have each user login and communicate locally then be able to communicate with other offices, that way if internet connectivity between offices goes down, the local users could still communicate with each other.

The Questions:

Will a Connection manager function like a normal openfire server? or will it merely process logins so there aren’t too many requests at one time to the openfire server?

Is there any detailed documentation for configuring a connection manager?

I have a feeling the s2s will be the “best” solution but how will that effect pre-populated roster’s? Can I edit the .XML roster files in the users profile folder and push that out to users? or will they have to manually add contacts from the other office’s Server?

Anybody else have a similar setup and care to share what they did?

Can this even be done with the free version? or is the enterprise version better suited for this type of setup?

Cheerz!

Matt

Hi Matt,

Does your End Goal also requires that all your users login id remains as user@yourdomain ?

If it does then S2S will not solve your problem. S2S will force you to split your users into smaller groups and login as user@server1.yourdomain, user@server2.yourdomain, etc. Instead, you need a clustering setup, which is not possible with the open source version of Openfire. Openfire Enterprise is suppose to be able to do clustering, but I’m not sure if its functional in the current version.

If the End Goal can do with breaking your users into smaller groups, then S2S is the solution. However, as you expect, your existing users’ rosters need refresh. User rosters are stored in the database, and each buddy is stored as its full JID. Changing the domain part of the JID would be troublesome if you want to do it yourself. I think it may be best to inform your users to backup their rosters and ask them to recreate it.

Will a Connection manager function like a normal openfire server? or will it merely process logins so there aren’t too many requests at one time to the openfire server?

Connection managers are not directly related to your End Goal whether or not you use S2S.

Connection managers will not function without an XMPP server. Like you said, connection managers takes the verbose client login process off the server. Connection managers also help reduce overhead of client-server TCP/IP connections, overcome a single-server limitation on the number of TCP/IP connections, and increase the number of users a server can handle at a given time.

I’m not sure of connection managers documents other than Ignite Realtime: Openfire Server.