[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [JDEV] A question regarding scaling



	Here's the reasoning I was thinking of wanting to connect to other servers
beside's your home server.  Different transports that not all servers may
run..  Let's use an example of a mod_perl module, or some other HTTP based
transport..  If my server doesn't run it, I'd want to be able to connect to
ANOTHER server.  My case would be while I'm at work behind an HTTP firewall.
In this way, if you wish to utilize another transport, you can..

	I know this really won't help load balancing in and of itself, I was more
stuck on the 'connect to any server' part.. ;-P  Although, it would seem to
me that 3 server connections that are remotely connected serving several
hundred users each would help load balance a little, but not all THAT much..
;-P

	Wow, I just had a though about this..  If we did have what I mentioned, you
could actually have the 'publically available server' be a different server
then the one that actually validating logins, allowing for the
authentication to be based on a machine inside a firewall, while the public
server is out in the open, but contains none of the password and user data..
Simular to this:

ClientA      ClientB      ClientC
    \           |          /
     \          |         /
      \         |        /
       \        |       /
        \       |      /
         \      |     /
          \     |    /
          |-----------|
          |Public     |
          |Server     |
          \-----------/
                |
                |
================|===============
==== Firewall ==|===============
================|===============
                |
           /----------------\
           | Authentication |
           | Server         |
           \----------------/

	This way an ISP could have their authentication based on the same system
that authenticates it's users (Which, if they're bright, is behind some sort
of firewall)..

--
Thomas Charron
United Parcel Service
Northeast Region
"Moving at the speed of a T3 Trunk Line!"


> -----Original Message-----
> From: owner-jdev@jabber.org [mailto:owner-jdev@jabber.org]On Behalf Of
> Jeremie Miller
> Sent: Tuesday, March 23, 1999 4:26 PM
> To: jdev@jabber.org
> Subject: RE: [JDEV] A question regarding scaling
>
>
>
> > 	Well, here is how I envision this being able to happen..
> Let's say I am
> > twolf@jabber.org.  jabber.org contains my password and personal
> information.
> > I then use my client to attach to jabber.tiac.net, as twolf@jabber.org.
> > jabber.tiac.net would contact jabber.org to validate my
> password, and tell
> > the server that twolf@jabber.org is connected on jabber.tiac.net, and to
> > forward messages there.
>
> There are a few issues here...
>
> First, having "roaming" setup where the server your connected to talking
> to your real server doesn't offer any benifits, since everything will end
> up going back to your real server anyway.  I think the direct
> client->server connection is always going to be the best route, just like
> how HTTP works.
>
> Next: load balancing and lots of simultaneous connections to servers.
> There are two solutions that I can think of easily.  First, do it just
> like how you'd do a large web site, round-robin DNS or the like.  Have a
> farm of front end servers and a hefty back end database server, and
> however the DNS resolves is the server you are connected to.  This would
> require the authoring of a special module on the server to do everything
> through the database, but much of that framework will probably already be
> in place for other purposes.  Secondly, there is a special type of
> "client" that the server understands, that's a "MULTI" client.  It can
> harbor multiple simultaneous user logins over one connection to the
> server.  A simple proxy could be built that groups of users connect to and
> everything feeds back to the one main server.
>
> I'm quite sure that any needed load balancing or roaming problems can be
> solved as they are found, the architecture is quite scalable.
>
> > > Sorry if I'm being obtuse here, but I need to ask these
> questions as I'm
> > > evaluating including support for Jabber in our product.
>
> No problem, please ask away :) I get quite a few personal inquiries from
> others evaluating supporting Jabber and am willing to help in any way I
> can.
>
> Jer
>