I agree (connectionless, UDP) Re: [JDEV] scaling a single server?

Scott Robinson quad at jabber.org
Fri Feb 4 19:53:17 CST 2000


The currently existing Jabber-XML protocol used between etherx routers and
between clients and jabber-transport is TCP based.

HOWEVER, there is nowhere within the Jabber specification that guarantees
delivery. I touched on this subject quite a few months back when talking
about connection-less and unreliable physical layers. The answer to the
problem of connection-less and unreliable communiation layers is to create a
new "udp-jabber-transport" which would accept connections from Jabber
clients that used a specified UDP protocol.

I would suggest, given the problems with scability are quite real, that we
create a team that would flesh out a UDP protocol and transport to be
included in 1.0.

Scott.

* Robert Thompson translated into ASCII [Fri, Feb 04, 2000 at 07:00:34PM -0500][<000901bf6f6c$06cf1910$65390a18 at roalok1.mi.home.com>]
> > I strongly recommend connectionless protocols and UDP!
> 
> I **AGREE**
> 
> My goal has been to support client-to-client with the server being more of a
> directory.
> 
> I just don't see myself implementing Jabber for communities where the goal
> his high growth.
> 
> I've asked about this all along but a few keep saying that somehow this
> no-upgrade transport possibility outweighs this -- fooey....Jabber should at
> least have flexability for non-connect protocols....the chat I've got
> working uses UDP, but I lack a white pages type setup...that's what I
> thought Jabber would provide, but I'm starting to doubt that.
> 
> - Robert
> 
> 
> > Regards,
> > Stanislav
> >
> >
> > ----- Original Message -----
> > From: "Jacob O'Reilly" <jacob at clear.net.nz>
> > To: <jdev at jabber.org>
> > Sent: Thursday, February 03, 2000 9:27 PM
> > Subject: Re: [JDEV] scaling a single server?
> >
> >
> > > I can't give you any idea about scalability of Jabber, but I do know
> that
> > > the number of sockets a process can have open is tunable in the kernel.
> I
> > > don't know for Linux (as opposed to the commercial Unices I've used)
> > whether
> > > that is a socket specific parameter or just a factor of NFILE.  I
> imagine
> > > that with that many users tho., a fair few parameters might need to be
> > > changed.
> > >
> > > One of the things I've seen software do to scale better (to thousands of
> > > concurrent users) is to use the UDP protocol -- and maintain the idea of
> a
> > > connection at an application layer.  This doesn't provide for the
> simplest
> > > coding, but given that your average user may not act to cause any
> traffic
> > > very often at all, it provides the least load on the server machine (in
> > > terms of kernel/network resources anyway).
> > >
> > > It seems to me that a system of tiering connections through to a server
> > > would provide the most scalability.  Can etherx run on a different
> machine
> > > from the Jabber server?
> > >
> > > -- Jacob.
> > >
> > > -----Original Message-----
> > > From: Russell Nelson <nelson at crynwr.com>
> > > To: jdev at jabber.org <jdev at jabber.org>
> > > Date: Friday, 4 February 2000 09:48
> > > Subject: [JDEV] scaling a single server?
> > >
> > >
> > > >I've got a customer with 25 lakh users.  In case you're not familiar
> > > >with the units they use in India (I wasn't), 1 lakh == 10,000.  They
> > > >also comma-ize in an original and inventive manner, so they have
> > > >2,50,000 users.  I'm trying to convince them NOT to implement a
> > > >proprietary system.  This should not be impossible since they have
> > > >developed a predilection to Open Source solutions.
> > > >
> > > >They want to add all 25 lakh users to Jabber all at once, and announce
> > > >it.  Clearly there is not going to be a ramp-up period to give them
> > > >time to gain experience with Jabber.  They need to know that it will
> > > >scale from the get-go.
> > > >
> > > >Obviously this is OS dependent.  My customer is running Redhat 6.1 on
> > > >a machine with 18GB of hard drive and 1GB of memory.  Those values
> > > >should not be the constraint.  I'm more concerned with the number of
> > > >sockets that can be open at any one time.  If Linux has a limit of
> > > >1,000 sockets, and they have (they estimate) 25 thousand users online
> > > >at any one time, that means they need 25 servers.  This is double-plus
> > > >ungood.
> > > >
> > > >Does anyone have any experience with how big a single Jabber server
> > > >can scale?
> > > >
> > > >--
> > > >-russ nelson <sig at russnelson.com>  http://russnelson.com
> > > >Crynwr sells support for free software  | PGPok | "Ask not what your
> > > country
> > > >521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other
> people
> > to
> > > >Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | do for
> ou..."  -Perry
> > M.
> > > >
> > > >_______________________________________________
> > > >jdev mailing list
> > > >jdev at jabber.org
> > > >http://mailman.jabber.org/listinfo/jdev
> > > >
> > >
> > >
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> >
> >
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
> 

-- 
jabber:quad at jabber.org         - Universal ID (www.jabber.org)
http://dsn.itgo.com/           - Personal webpage
robhome.dhis.org               - Home firewall

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GAT dpu s+: a--- C++ UL++++ P+ L+++ E- W+ N+ o+ K++ w++
O M V PS+ PE Y+ PGP++ t++ 5++ X+ R tv b++++ DI++++ D++
G+ e+ h! r-- y-
------END GEEK CODE BLOCK------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20000204/5815f47e/attachment-0002.pgp>


More information about the JDev mailing list