I've been setting up a new server, and have noticed a problem in the way clients and servers seem to communicate.
My Jabber server resides on a machine, fornost.cataclysm.cx. However, I want the machine to respond to packets sent to @cataclysm.cx. For s2s, this is easy - SRV records are already in place. However, for clients it's a little more difficult, it seems. I use Gabber most of the time, but I don't think this is specific to that client. When I connect, it asks for a username and server. It combines these to form the user's JID. So, I need to enter user 'rob' and server 'cataclysm.cx' to get the correct JID. However, the A record in the DNS for cataclysm.cx points to a different machine, so it doesn't work. Entering 'fornost.cataclysm.cx' as the server works, but it builds the wrong JID. I can think of the following solutions: 1. Set up a redirector on the other machine that forwards cataclysm.cx:5222 to fornost.cataclysm.cx:5222 2. Point the A record for cataclysm.cx to fornost.cataclysm.cx, and set up redirectors for the other services. 3. Hack JID rewriting stuff into the JSM, so that any to/from attributes get rewritten to what I want them to be. 4. Get clients to use SRV records for the client connection. 5. Get clients to treat the JID and the server as different entities. Option 1 is a pain, but is probably the best short-term solution for me. Option 2 is similar, but is even more painful, and not really good. Option 3 is problematic, because the server and the client have a different idea of who they are - if the client puts its JID into the packet somewhere other than in the to/from attributes, the server has no way to know to rewrite it. Option 4 is definently the correct way to solve this, but requires client support. Option 5 should accompany option 4. This isn't too much of an issue for me - I'm the only one who uses my server. However, I can see this becoming a major issue in any large installation - things like load-balancing and farming are going to exhibit this problem on a much grander scale. What do others think? Has anyone else come across this problem and come up with an elegant solution to it? Rob. -- Robert Norris <[EMAIL PROTECTED]> GPG: 1024D/FC18E6C2
msg04667/pgp00000.pgp
Description: PGP signature
