[JDEV] Re: Large scale Jabber bots

[Thomas Charron]

From: Jens Alfke
Subject: Re: [JDEV] Re: Large scale Jabber bots
>OK, that's different from what you said before. What you actually mean is
"mailservers run for end users by ISPs or portals", not just "mailservers".
That's clearly a policy decision for the people running the server, not a
>technical issue. I'm not interested in the policy issues here; that's
already covered by various tunable settings in jabber.xml.

    Technically, I belive he initially said a tunable number.

> Also, the point I initially made on this thread is that if you want a bot
(like a freshmeat announcer) sending you IMs, it is a much better model to
tie this to a Jabber subscription rather than having to invent your own
> higher level subscription model involving sending magic IMs to it (whose
syntax people will inevitably mess up or forget.) Let's not introduce all
the same problems that listservs have.

    Err, what does having something as a transport or service have to do
with a magic protocol?  A transport can just as easily use the same
mechanism, and actually provide an even EASIER mechanism for registering
with specific data that you might need.  Have you ever seen the old RSS
transpork working?  Did you know it existed?  It did exactly as you stated,
but, being a transport, could use the registration that has been setup for
transports, allowing much more flexibility.  Ever even glanced at the
jabber:x:register namespace for IQ packets?


>> If you are running a server, do you want some user to connect,
>> advertise their client as a bot, and start taking up memory and CPU usage
to
>> the scale described below?
> In the case of "some random user", clearly not. As I said above, this is a
policy decision, not a technical one. In cases where the server and the bot
belong to the same organization, this might be a fine idea.

    Have you ever written a large scale server and the protocol to go with
it?  You cannot design the two the same.  Period.  Things don't just
magically scale.  You either give things up, or you design around it.


>> I'm saying that you can't take protocol decisions made for an average
roster
>> size of 10 and scale it to a roster size of a quarter million.
> I don't see any protocol decisions here that don't scale. It sounds like
purely a server implementation issue.

    Oh, might I ask, are you going to store thousands of roster entries on a
server, and go thru the effort of notifying all of them that you are online,
and NOT have a massive performance impact?  Please, tell me how.  I want to
go trademark it and make millions..

>> If you are giving out a user address as the bot, it is a user; it cannot
be
>> farmed, it cannot be distributed. Again, it has to be attacked another
way.
> Again, is that an intrinsic limitation of the protocol, or just with the
design of the current server?

    It's a limitation put forth by the technical requirements decided upon
by the community.  It's either that, or an incredibly complex system such as
those that MSN uses, where you auth on one server, then get redirected to a
communications server, while another server in the background actually DOES
the authentication, and when you get therem, it lets you know you'r authed,
then points you to YET ANOTHER server.  Then, while your talking with
people, your conversations may be distributed amungst any number of servers.
Instead of a smaller number of smart boxes, it uses many, MANY dumb ones.
It's a design decision.