>From your description, it seems that a hardware load balancer in front of your web service farm would do this job easily and transparently. -Paul <div>On 2/13/06, Matthew Wilson <<a href="mailto:mw44106@gmail.com">mw44106@gmail.com</a>> wrote:<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> We have a bunch of boxes (20 or so) that offer web-services to our server farm of several hundred boxes.  Right now, if a box on a farm needs to connect to one of the web service boxes, it iterates through a list of all the web-service boxes, and tries to connect to each one, until it finds one that is free to handle the request. I'm thinking that a better model might be to create a MUC where each of the web-service boxes are persistently connected.  They would use their presence attribute to indicate whether they are available or busy. When one of the farm boxes needs to make a request, it would connect to the chat, get the presence info for all the web-service boxes, and then choose one of the available servers to send a request to. In order to send the request, I figured the client could send a message to the room and specify in the message which server process it is sending the request to. At this point, the server would * update its presence to busy; * handle the request; * put a message back into the chat room, with the request results; * update its presence to available I'd prefer that the clients and servers communicate through the room, rather than directly, so that I can just log the chat room and see all the transactions. A few questions: * Is this asinine? * Has anyone done anything like this?  Are there any hidden gotchas you discovered?   * Is there any reason to mix in some jabber-RPC? All advice is appreciated. </blockquote></div>