[JDEV] (no subject)

2001-05-09 Thread СÖÓ

ÄúºÃ£¡

×â100M»ò200MÐéÄâÖ÷»ú£¬Ë͹ú¼ÊÓ¢ÎĶ¥¼¶ÓòÃû£¡£¡£¡ÁíËÍ5¸ö10Mµç×ÓÐÅÏ䣡£¡£¡   
   

ÍøÂçÒѳÉΪÐû´«ÆóÒµ»ò²úÆ·µÄÖØÒªÇþµÀÖ®Ò»£¬ÆäÖÐÍøÕ¾ºÍÓòÃû¸üÊDz»¿ÉȱÉÙµÄ×é³É²¿·Ö¡£Ë×»°Ëµ¡®Âäºó¾ÍÒª°¤´ò¡¯£¬ÄúÔ¸ÒâÊÜ¡°°¤´ò¡±Â𣿲»£¬³É¹¦ÊôÓÚÎÒ£¡

¡°ÉêÓòÏȷ桱http://www.net009.netΪÄúÌṩ£º
 1¡¢¹ú¼Ê¡¢¹úÄÚÖС¢Ó¢ÎÄÓòÃû×¢²á£¨Ó¢£º100Ôª/¸ö/Ä꣩
 2¡¢ÐéÄâÖ÷»ú×âÓã¨100M£º350Ôª/¸ö/Äꣻ200M£º500Ôª/¸ö/Ä꣩
 
3¡¢1+1ÆóÒµÉÏÍøÌײͣ¨×âÓÃÒ»¸ö100M»ò200MÐéÄâÖ÷»úËÍ5¸ö10Mµç×ÓÓÊÏä+Ò»¸ö¶¥¼¶¹ú¼ÊÓ¢ÎÄÓòÃû£¬ÏÖÔÚ100MÖ»Òª350Ôª/Ì×/Äꣻ200MÖ»Òª500Ôª/Ì×/Ä꣩
 
 4¡¢·þÎñÆ÷×âÓ㺵¥Óû§2Ôª/Äê¡¢10Óû§3000Ôª/Äê¡¢20Óû§2000Ôª/Äê¡£
 5¡¢.biz;.info;.pro;.name¹ú¼ÊÓòÃûÃâ·ÑÔ¤µÇ¼Ç¡£ 
ÇÒÓС°ÏÈ×¢²á£¬ºóÊÕ·Ñ£»ÏÈ¿ªÍ¨£¬ºó¸¶¿î£¬ÖÐ;¿ÉÍ˿µÄÓŻݡ£
µÍÁ®µÄ¼Û¸ñ£¬Ò»Á÷µÄ·þÎñ£¬Äú»¹ÓÌԥʲô£¿¸Ï¿ìÐж¯°É£¡¡°ÉêÓòÏȷ桱»¶Ó­ÄúµÄµ½À´£¡
ÏêÇéÇëÉÏhttp://www.net009.net ÍøÕ¾¡£TEL£º0592-523 E-mail:[EMAIL PROTECTED] 
OICQ:66530521

 Ìṩ´úÀí£¬ÓÐÒâÕßÇëÁªÏµ¡£ÖÓÏÈÉú¡£

  ÖÂ
Àñ£¡

ÉêÓòÏÈ·æ
   [EMAIL PROTECTED]

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



[JDEV] Customizing Jabber server

2001-05-09 Thread Gerard BUNEL

Hello,

I'm new to IM and also to Jabber of course.
I'm working on a project which purpose is to plug some Jabber
functionalities into an Application server.
So I'm looking to informations on how to customize the Jabber server so
that it could delegate some
requests like authentication, rosters, etc to the Application server

I had a look to the server sources but didn't exactly found the entry
points to start from.

Any Idea ?

Thanks

--
[EMAIL PROTECTED] - Atlantide - http://www.ago.fr/atlantide/
Technopole Brest Iroise BP 80802 - Site du Vernis - 29608 Brest cedex -
France
Tel. : +33 2 98 05 43 21 - Fax. : +33 2 98 05 20 34
e-mail: [EMAIL PROTECTED]
Centre Affaires Oberthur - 74D, rue de Paris -  35700 Rennes - France
Tel. : +33 2 99 84 15 84 - Fax : +33 2 99 84 15 85
e-mail: [EMAIL PROTECTED]


___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



Re: [JDEV] Customizing Jabber server

2001-05-09 Thread wasted


we're working on similar types of issues and my take on it this... jabber
isn't an application server itself.  it facilitates the routing of
messages to the appropriate destination - normally a human for chat.  of
course the destination can be an agent or a transport with
business/application logic coded for a purpose which returns some data or
whatever.  an agent could be a stock watcher, a weather man, a news
grabber, data mine - the list is endless.  you can write an agent in
almost any language with all the cool tools the dev guys have done -
Net::Jabber, JabberCOM, JabberBeans, etc...  i'm partial to JabberBeans
'cause we do a lot of Java programming.  then again, as JAM develops,
jabber could become more application server-ish.

not sure if that's the sorta explanation you're looking for, but i hope it
helps.

and if i'm wrong or off base in any way, someone let me know! ;-)

-wasted

On Wed, 9 May 2001, Gerard BUNEL wrote:

 Not exactly if my understanding of jabber protocol is correct.
 I beleive that the Jabber server acts simply as a router for messages whose 
destination is another server.
 But in my case, the Jabber user is also an Application Server user. So I try to not 
constraint the user to log twice for example
 I also want that some data already managed by the Application Server could be used 
as Jabber user's Data (vCard, Rosters, etc...).
 
 My first starting point seems to be XDB module. If my understanding is correct I 
should have to patch or replace the default
 xdb_file so that all persistent data could be completely managed by the Application 
Server.
 
 But, in that case, what about authentication data for example. Should they really be 
retreived from the Application Server.

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



Re: [JDEV] Customizing Jabber server

2001-05-09 Thread David Waite

Part of the reason for the Jabber Foundation is to separate the linking between the 
Jabber protocol and an 'official'
Jabber server implementation.  Hopefully one of the many tasks the foundation will 
handle is clarifying some of the
rough edges in the current client and interserver protocol, and possibly define some 
standards for intraserver
protocol (for different server implementations to be capable of sharing the same 
components)

-David Waite

Peter Saint-Andre wrote:

  I've been wondering why the Jabber Server hasn't been implemented in other 
languages such as Java or Python with

 Um, 'cause it's a lot of work? :) But seriously, we are currently
 working to document the internal protocols for the server, and once we
 have those it will be much easier to write servers in other languages. I
 know of one effort underway (by Iain Shigeoka) to write a server in
 Java, but I'm sure others would be interested in Perl, Python, C++, etc.
 I think these will happen over time, but it ain't easy

 Peter

 --
 Peter Saint-Andre
 [EMAIL PROTECTED]

 ___
 jdev mailing list
 [EMAIL PROTECTED]
 http://mailman.jabber.org/listinfo/jdev

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



RE: [JDEV] Strange Packets

2001-05-09 Thread Randy Higginbotham

I don't find anything in the source code.

Randy

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Todd Bradley
Sent: Wednesday, May 09, 2001 12:45 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JDEV] Strange Packets


Maybe this is a stupid question, but have you already looked into the
possibility that one of your users has an offline message for someone at
that address and the server-to-server component is trying to deliver it?


Todd.

 -Original Message-
 From: Denny Chambers [mailto:[EMAIL PROTECTED]]
 Sent: Wednesday, May 09, 2001 10:38 AM
 To: [EMAIL PROTECTED]
 Subject: [JDEV] Strange Packets
 
 
 Does anyone know why when I start up my jabber server that it starts
 sending out packets to kelvinator.websavvy.com? Has anyone else looked
 at sniffer traffic of jabber, and are you seeing the same thing?
 
 Thanks,
 -- 
 Denny Chambers
 ___
 jdev mailing list
 [EMAIL PROTECTED]
 http://mailman.jabber.org/listinfo/jdev
 
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



Implementing Jabber Server in other Languages (Was RE: [JDEV] Customizing Jabber server)

2001-05-09 Thread Matt Diez
Title: Implementing Jabber Server in other Languages (Was RE: [JDEV] Customizing Jabber server)





 I've been wondering why the Jabber Server hasn't been implemented in other languages such as Java or Python with
 C calls to the appropriate libs. It seems that multiple server platform implementations could only help in the 
 adoption of Jabber.



This is something I've been thinking about for a
while, and would like to open up to some discussion.

I really don't see implementation of Jabber in other
languages as being that practical or necessary. I
must confess, I really don't like changing server code
to change server behavior (registration, I'm looking 
at you). But, I really can't see how/when/where/why
a server in, say Python is all that advantageous,
save for its multiplatform capabilities. But, I must
say, given the speed Jabber must work to route messages,
I don't see a Python (or any other language of your choice)
server as 
a) useful
b) practical


This demands the inside-out reworking of the Jabber server
in a variety of languages, and the development of alternate
servers that can anticipate future changes to Jabber 
internal protocols and such.


Now - the ability to change certain server behaviors does
make itself attractive, and is a pretty compelling argument
for implementing Jabber in other languages, but I'm not 
sure there aren't simply better ways around this, particularly 
ones that don't require wholesale server rewrite whenever
fundamental changes in the default Jabber server occur.


I think the focus of current server developers should be
to first document all internal protocols - (s2s and xdb
being fine examples), and then to worry about making
Jabber as portable as possible. I've got a pretty hefty
RS6K sitting next to my desk begging to run Jabber, but
even IBM's porting efforts have only been partially 
successful. 


Which, in many ways - is a pretty strong argument for
much more platform-agnostic languages (perl, python,
java), but I think we need to look at Apache as a good
model. 


Yes, I know that Apache is only a server (well not so
much these days) and Jabber is a set of related technologies, but 
I feel that making the current Jabber server as fast/friendly/portable 
as possible is the real key here, and maintaining a variety of
separate server implementations would be...



On second thought - David Waite's right - we have to look at separating protocol
from server implementation.


You know - I just contradicted myself. 


Matthew D. Diez
[EMAIL PROTECTED]





Re: [JDEV] Strange Packets

2001-05-09 Thread Thomas Charron

No worries.  Jabber.org port 5222 ends up going to
kelvinator.websavvy.com.  My guess is it's doing some forwarding.  Go ahead
and telnet to jabber.org at port 5222.  Do a netstat..  8)

From: Denny Chambers [EMAIL PROTECTED]
Subject: [JDEV] Strange Packets
 Does anyone know why when I start up my jabber server that it starts
 sending out packets to kelvinator.websavvy.com? Has anyone else looked
 at sniffer traffic of jabber, and are you seeing the same thing?


___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



[JDEV] performance numbers.. questions

2001-05-09 Thread Dustin Puryear

I am actually now getting some hard numbers from the jabbertest tools.
One test I ran connected 1000 users to a Jabber server running on a
Pentium III 600 with 192MB of RAM. I saw some odd results. But first,
here is how the test works:

active_jab basically connects 1..n users serially, and sends x messages
when each user connects. It does NOT send messages concurrently for each
connected user. (Although that would be an excellent feature--to be
added soon!) Instead, if you want to simulate multiple users sending
messages at the same time to the same server then you just run muliple
instances of active_jab on the same or different client machines. (Very
simple.) The basic idea is:

for user 1..n do
  connect user to jabber
  send x messages and track delivery times
done

for user 1..n do
  disconnect user from jabber
done

Memory
===
First of all, I assumed that Jabber would consume a lot of memory, which
turned out to be a wrong assumption. I saw my %memused jump from a rough
minimum of 81% to maybe 95%. My %swpused did not change significantly,
which indicates that I had enough core memory for the job. (Remember
Linux always uses as much memory as it can for buffers, so the starting
value of 81% isn't surprising.) The big issue here is that there was
only a small jump--around 14%.

CPU
===
Big surprise here. Jabber seems to *quickly* begin eating CPU cycles as
the number of connected users increases. Here is some data:

users   idle  user  sys
0   99%   1%0%
200 70%   24%   3%
500 45%   50%   5%
800 30%   64%   6%
100020%   70%   10%

(Yes, the totals may be more or less that 100%. I am getting these
numbers from graphs and quickly jotting them down.)

Note that Jabber is consuming 24% of the CPU at 200 users on a Pentium
III 600. I also noticed that as more users are connected the message
delivery time decreased. The progession was slow.. usually going from 0
seconds to 2 seconds as the number of users went from 0..1000. But
still.. why is that? Remember I am not sending message concurrently.
Instead, as each user connects active_jab sends x messages (defaults to
5), and then proceeds to the next user.

I would like some feedback on this data. Does this look like what
everyone else has been experiencing? Are my numbers out of wack?! What
other numbers would be useful?

I think the next logical step is to run active_jab on several machines
at once. That way we can test how many *concurrent* users can connect
and send messages.

Regards, Dustin

-- 
Dustin Puryear [EMAIL PROTECTED]
http://members.telocity.com/~dpuryear
In the beginning the Universe was created. 
This has been widely regarded as a bad move. - Douglas Adams
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



[JDEV] RE: Implementing Jabber Server in other Languages (Was RE: [JDEV]Cus tomizing Jabber server)

2001-05-09 Thread Max Metral

It seems like the prototyping point here is the strongest.  From a perf
perspective, C/C++ all the way seems pretty important for carriers and large
ISPs (like us if I may be so bold), but not for people tooling around with
new features...  If we all agree with this, the nice thing might be that a
second/alternate language version would have an EXPLICIT goal of being
readable and modifiable and NOT being efficient or cheaply/quickly scalable.

Of course, we'd never agree on the language, so there'd end up being 10.

-Original Message-
From: John Hebert [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 09, 2001 3:43 PM
To: [EMAIL PROTECTED]
Subject: Re: Implementing Jabber Server in other Languages (Was RE:
[JDEV] Cus tomizing Jabber server)


5/9/01 8:03:42 AM, Matt Diez [EMAIL PROTECTED] wrote:
   I really don't see implementation of Jabber in other
   languages as being that practical or necessary. I
   must confess, I really don't like changing server code
   to change server behavior (registration, I'm looking
   at you). But, I really can't see how/when/where/why
   a server in, say Python is all that advantageous,

Quicker to prototype and test new capabilities, for one. Lots
of XML libs/tools for another. Python works best as a glue
scripting language between components.

   save for its multiplatform capabilities. But, I must
   say, given the speed Jabber must work to route messages,

That's why I mentioned calling C binaries from Python or
language X if needed. Also, performance may not be a priority.
I can imagine using the jabber server for other tasks besides
IM chatting.

   I don't see a Python (or any other language of your choice)
   server as

   a) useful
   b) practical

Oh yeah? Moldy bread.

   This demands the inside-out reworking of the Jabber server
   in a variety of languages, and the development of alternate
   servers that can anticipate future changes to Jabber
   internal protocols and such.

Interesting. Kinda like Apache httpd's DSO modules.

   Now - the ability to change certain server behaviors does
   make itself attractive, and is a pretty compelling argument
   for implementing Jabber in other languages, but I'm not
   sure there aren't simply better ways around this, particularly
   ones that don't require wholesale server rewrite whenever
   fundamental changes in the default Jabber server occur.

I'm getting confused... didn't you just say something to the
contrary before this? And don't you mean protocol instead
of your last use of server in the above paragraph?
If so, agreed, server rewrites for protocol changes is icky. 

   I think the focus of current server developers should be
   to first document all internal protocols - (s2s and xdb
   being fine examples), and then to worry about making
   Jabber as portable as possible. I've got a pretty hefty
   RS6K sitting next to my desk begging to run Jabber, but
   even IBM's porting efforts have only been partially
   successful.

Yup, you are correct. St. Peter mentioned that this work is
being done. Bring out the cat o' nine tails.

   Which, in many ways - is a pretty strong argument for
   much more platform-agnostic languages (perl, python,
   java), but I think we need to look at Apache as a good
   model.

Are you skipping on your Lithium again?

   Yes, I know that Apache is only a server (well not so
   much these days) and Jabber is a set of related technologies, but
   I feel that making the current Jabber server as fast/friendly/portable
   as possible is the real key here, and maintaining a variety of
   separate server implementations would be...

Jabber = related technologies? That's not what I thought Jer had in mind.

   On second thought - David Waite's right - we have to look at separating
   protocol from server implementation.

My point all along. Apache has the W3C. What does Jabber have? Do we
need a separate jabber protocol effort separate from the server devel
effort?

   You know - I just contradicted myself.

I'm getting used to it.

--
John Hebert
System Engineer
http://www.vedalabs.com
Changing your state of mind through sound. 

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



RE: [JDEV] RE: Implementing Jabber Server in other Languages (Was RE: [JDEV] Cus tomizing Jabber server)

2001-05-09 Thread Ted Rolle

 It seems like the prototyping point here is the strongest.  From a perf
 perspective, C/C++ all the way seems pretty important for carriers and
large
 ISPs (like us if I may be so bold), but not for people tooling around with
 new features...  If we all agree with this, the nice thing might be that a
 second/alternate language version would have an EXPLICIT goal of being
 readable and modifiable and NOT being efficient or cheaply/quickly
scalable.

These goals are not mutually exclusive.  The meeting/common point is called
elegance.
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



[JDEV] Possible Fix for SSL Woes

2001-05-09 Thread temas

I was helping reatmon fix his server for SSL usage and it turns out he
had the same error as everyone else, so I poked it a bit and behold I
found an answer.

Line 168 of mio_ssl.c (jabberd directory)

Change:

if(SSL_accept(ssl) = 0)

to

if(SSL_accept(ssl)  0)

I guess the = 0 was from my usage of 0.9.6 and newer versions, the
problem crept in from 0.9.5 versions.  It probably should be just a  0
scenario anyway.  Please let me know if this works.

--temas

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



[JDEV] Re: Implementing Jabber Server in other Languages (Was RE: [JDEV]Cus tomizing Jabber server)

2001-05-09 Thread temas

I personally (and I believe jer too) would love love love to see the
server implemented in other languages.  The more options available the
stronger I can see the growth of Jabber as a whole.  The whole reason we
have a common protocol is so we can have many servers.  Yes, some of the
servers may not scale as well, some might not expose more advanced
functionality, but having a more dynamic server to test on could be
helpful in many scenarios.  Just had to throw in my $0.02

--temas 

On 09 May 2001 14:42:37 -0500, John Hebert wrote:
 5/9/01 8:03:42 AM, Matt Diez [EMAIL PROTECTED] wrote:
I really don't see implementation of Jabber in other
languages as being that practical or necessary. I
must confess, I really don't like changing server code
to change server behavior (registration, I'm looking
at you). But, I really can't see how/when/where/why
a server in, say Python is all that advantageous,
 
 Quicker to prototype and test new capabilities, for one. Lots
 of XML libs/tools for another. Python works best as a glue
 scripting language between components.
 
save for its multiplatform capabilities. But, I must
say, given the speed Jabber must work to route messages,
 
 That's why I mentioned calling C binaries from Python or
 language X if needed. Also, performance may not be a priority.
 I can imagine using the jabber server for other tasks besides
 IM chatting.
 
I don't see a Python (or any other language of your choice)
server as
 
a) useful
b) practical
 
 Oh yeah? Moldy bread.
 
This demands the inside-out reworking of the Jabber server
in a variety of languages, and the development of alternate
servers that can anticipate future changes to Jabber
internal protocols and such.
 
 Interesting. Kinda like Apache httpd's DSO modules.
 
Now - the ability to change certain server behaviors does
make itself attractive, and is a pretty compelling argument
for implementing Jabber in other languages, but I'm not
sure there aren't simply better ways around this, particularly
ones that don't require wholesale server rewrite whenever
fundamental changes in the default Jabber server occur.
 
 I'm getting confused... didn't you just say something to the
 contrary before this? And don't you mean protocol instead
 of your last use of server in the above paragraph?
 If so, agreed, server rewrites for protocol changes is icky. 
 
I think the focus of current server developers should be
to first document all internal protocols - (s2s and xdb
being fine examples), and then to worry about making
Jabber as portable as possible. I've got a pretty hefty
RS6K sitting next to my desk begging to run Jabber, but
even IBM's porting efforts have only been partially
successful.
 
 Yup, you are correct. St. Peter mentioned that this work is
 being done. Bring out the cat o' nine tails.
 
Which, in many ways - is a pretty strong argument for
much more platform-agnostic languages (perl, python,
java), but I think we need to look at Apache as a good
model.
 
 Are you skipping on your Lithium again?
 
Yes, I know that Apache is only a server (well not so
much these days) and Jabber is a set of related technologies, but
I feel that making the current Jabber server as fast/friendly/portable
as possible is the real key here, and maintaining a variety of
separate server implementations would be...
 
 Jabber = related technologies? That's not what I thought Jer had in mind.
 
On second thought - David Waite's right - we have to look at separating
protocol from server implementation.
 
 My point all along. Apache has the W3C. What does Jabber have? Do we
 need a separate jabber protocol effort separate from the server devel effort?
 
You know - I just contradicted myself.
 
 I'm getting used to it.
 
 --
 John Hebert
 System Engineer
 http://www.vedalabs.com
 Changing your state of mind through sound. 
 
 ___
 jdev mailing list
 [EMAIL PROTECTED]
 http://mailman.jabber.org/listinfo/jdev

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



Re: [JDEV] performance numbers.. questions

2001-05-09 Thread Oliver Jones

Hey, Dustin, congratulations on actually getting real-live 
numbers!  Getting a test harness working is a tremendous 
accomplishment!  Thanks!

At 02:52 PM 5/9/01 -0500, you wrote:
...here is how the test works:
active_jab basically connects 1..n users serially, and sends x messages
when each user connects. It does NOT send messages concurrently for each
connected user.

If I understand you, the sequence of events is this, for each user:

a. connect
b. log in.
c. send x messages as fast as possible.
d. stay connected, but stop sending messages.

When you run the test, you run these steps for each virtual user in 
turn.  Right?

Some questions about your test sequence:
--Does the log-in step also create an account for the virtual user?
--What kind of authentication are you using?
--To what user do the x messages get sent?
--Is the recipient online or are the messages getting stashed in jspool?
--Does the volume of the x messages sent cross the karma threshold?

You proposed this scenario:

for user 1..n do
   connect user to jabber
   send x messages and track delivery times
done

for user 1..n do
   disconnect user from jabber
done

I'd like to see tests that figure out the load that comes on when many 
users connect and authenticate at once.  The question to ask might be,

  -- when 500 users are already connected to jabber but not doing much,
 how many new user connections can jabber accept each second?

A subsidiary question might be how the choice of authentication method 
affects this, and how the choice of xdb_file or other jspool module affects it.

Another subsidiary question might be how many NEW user accounts can be 
created in a second.

I'd like to see tests that figure out the load that comes on when many 
connected users send lots of messages.  The question to ask might be,

   -- when 1000 users are already connected, how many messages a second
   can each user send to some other user -- what's the message throughput?

Memory
===
First of all, I assumed that Jabber would consume a lot of memory, which
turned out to be a wrong assumption.

This agrees with my observation.  Our jabber setup typically runs with 
several hundred users connected -- and neither jabberd nor the half-dozen 
jpollds we operate take much memory at all.

(Check out our jabber-enabled music community at http://dotclick.com.)

CPU===
Big surprise here. Jabber seems to *quickly* begin eating CPU cycles as
the number of connected users increases. Here is some data:

Our jabberd and jpollds take very little CPU time, but our users stay 
connected for long periods and typically don't send huge numbers of 
messages -- dozens a day.

Your high CPU usage may be due to overhead on new connections, or overhead 
on karma-throttling virtual users who are sending big bursts of data.

Great progress.

Ollie Jones

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



RE: [JDEV] RE: Implementing Jabber Server in other Languages (Was RE: [JDEV] Cus tomizing Jabber server)

2001-05-09 Thread Ted Rolle

All too true (your being right, of course).  But the elegance concept is a
philosphy, not based on any language.  Far too few who call themselves
programmers possess it.

-Original Message-
From: Max Metral [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 09, 2001 14:07
To: '[EMAIL PROTECTED]'
Subject: RE: [JDEV] RE: Implementing Jabber Server in other Languages
(Was RE: [JDEV] Cus tomizing Jabber server)
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



[JDEV] returning all spool directory members

2001-05-09 Thread Greg Wong

Can anyone tell me what the jabber protocol 
call is to return the users? I can't seem to 
find docs on it.

greg
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



Re: [JDEV] Re: Implementing Jabber Server in other Languages (Was RE: [JDEV]

2001-05-09 Thread Michael Rueger



Rahul Dave wrote:

 Java would be ideal from a portability standpoint, and jython or jpe
 means I can have my scripting too..

And then this almost forgotten but still very much alive language
Smalltalk, especially the open source variant Squeak (squeak.org). It
even runs on a Playstation II.

There are two partially complete Jabber clients written in Squeak, but
both at this time not really publicly available.

Just to add to the language war ;-)

Michael
___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev



[JDEV] Multithreading in XDB?

2001-05-09 Thread Alan.tan

Hi all!
I'm new to jabber server development,and I want to connect jabberd into my database.
The  xdb access seems to be single threading. Does it efficient enough to handle heavy 
traffic,e.g. thousands of clients online synchronously?

Regards

___
jdev mailing list
[EMAIL PROTECTED]
http://mailman.jabber.org/listinfo/jdev