[JDEV] Request for comments on system using jabber

[Thomas Charron]

From: Jens Alfke
Subject: Re: [JDEV] Request for comments on system using jabber
On Friday, May 25, 2001, at 09:26 AM, Thomas Charron wrote:
>> Now your talking about the improper use of a jabber client.
> It's only "improper" based on the current server implementation. There's
nothing architecturally wrong with it at all. In fact, it's architecturally
superior because it's much more modular: it allows the bot to run on a
> separate machine from the server (anywhere on the Internet in fact),
doesn't require any server reconfiguration, and will [barring scale issues]
work with any conceivable Jabber server architecture, even ones that don't
> have the same internal design as the current one.

    It has nothing to do with it.  The major limitation I can see here is
that xdb_file reparses the entire file, which is technically a limitation of
the way the offline storage is setup, and not a limitation of the entire
'system', really.  And running a client as a server is *NOT*
'architecturally superior'.  There is no 'architecture' in saying that your
going to have an application running connected as a client while performing
the services of a server.  The server itself makes several assumtions when
dealing with client connections.  One of them is that eveyone wants to see
eachothers presence.  This presence list is not needed in the case of the
bot.  It causes vast amounts of overhead for something that is simply not
required.  Unless you're going to try to save money and only employ this bot
part time at minimum wage, it will always be online..  8-)  And by the same
reasoning as your using, why not take it a step further, and start making
clients gateways into other networks, and do away with the entire notion of
a transport all together.  I mean, it's so 'architecturally superior'.   8-P


>>Thats why that bot should actually be running off of a
>>transport that is written specifically to handle that kind fo traffic.
Most
>>likely storing the user data in some sort of in memory database, while
>>persisting some of the data it requires for operation to more permenent
>>storage.
> Well, any server that plans to handle thousands of users ought to be
written that way, since it sounds as though the current approach doesn't
scale well at all. Then you wouldn't need to use a special transport for
things like this.

    It doesn't scale well becouse of the processing power required for these
kind of things on a mass scale.  It takes into consideration that we're
dealing with a very large number of very idle connections.  Heres an
example.  Many people use lower scale machines as their SMTP servers, simply
becouse it's a good use for old machines.  If you look at a good majority of
the small to midrange ISP's out there, they run the SMTP servers are
relatively small boxes.  Now, if all of the sudden, several of their
customers began to barage the SMTP server with constant emails to numerouse
other locations, which are also replying to all of these, as fast as they
can throw stuff out there, the box is going to die.  Does sendmail no longer
scale well?  Of course it does, it's been proven.  Will the box begin to cry
bloody murder, becouse the mostly idle SMTP server is suddenly being asked
to do a crapload of work?  SURE it will.  If your going to do something like
barage people with email, you use more special software to do this.  And
special boxes for this.

    Backing up a bit, it's safe to make the assumtion that anything acting
like a client should remember the rule of many, mostly idle, TCP
connections.  If something is *NOT* going to be mostly idle, then it should
at least be looked at as a server, and communicate with the Jabber 'network'
as one.

>> e the server use an external SQL database for storage? That way small
installations that want to use free/open software can plug in mySQL, while
large portals can use Oracle or Sybase or whatever.

    Sure, there are unofficial patches out there.  Now, when you say 'use
SQL', thats a pretty large statement.  Applications can't just magically use
SQL, ya know..  You can't write software and just plug in MySQL, then later
plug in Oracle.  Thats like expecting a program written in C on a PC running
Linux to run on a Mac running OSX.