directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar L├╝thi <kas...@humantools.com>
Subject Re: [MINA] Short or long messages for IoSession method write(...) ?
Date Tue, 03 Jan 2006 20:59:03 GMT
hi allesandro

>It looks like you know what I'm speaking of...I didn't spoke of $NickList
<nick1>$$... do you program in DC protocol ?

no i don't work with the DC protocol, sorry i gave you the wrong impression :)
i just used google and searched "Direct Connect Protocol".

you're speaking of $myinfos

"$MyINFO (Client to Server)
Shortly after logging in, the client must send,
    $MyINFO $ALL <nick> <interest>$ $<speed>$<e-mail>$<sharesize>$
The server must pass this message to all users of the hub, including the sender."

i see. it's not as scary as "sending all messages to all users" (exponential
growth of messages), but with many connections (> 1000) this can be a problem
for performance anyway, i think.

with 10000 users connected to the hub, you probably have like 2 logins per
second, which get translated to 2x10000 messages per second, just for $MyINFO.

in my case we had a peak of 650 users, thats like 20000 small out-messages per
*minute*, easy. so your challenges ("problems") don't apply here.


>I send the list containing all connected users (all myinfos) to each
connected user, I don't send a single myInfo to each connected user, so I
think here I'm ok.

i am a bit confused by your description. i think you have 2 cases with $MyINFO:

1. a user connects to the hub. he should receive a complete liste of the users
and ther properties, $MyINFO. -> one big message with all $MyINFO

2. the other, already connected users, need a notification of the new user.
since they already have the current userlist from their logon-process, they
only need the $MyINFO of the new user as an incremental update.

case 1: problem is to maintain the user list and sending it as fast as possible.
but since this only happens once in a users session, it's not #1 priority.

case 2: problem is the number of messages you have to send all the time.
i recommend following: don't send every new $MyINFO to all users. collect them
instead (eventually per user) and send them out in regular intervals. this
could dramatically lower the amount of messages being sent.

you could even make the interval dependent on the numbers of connected users,
many users big interval, few users, small interval.


>I'm here on the HSQLDB...

i still wonder what you store in the DB. does a DC hub needs persistent data
(except blacklists maybe)? if you don't need a persistent storage, don't use
it :) plus you should not spend too much time optimizing the database layer,
if the performance problem happens somewhere else. what makes you sure that
the database is the bottleneck?


>When you write: i maintain user-lists in memory and have them "cached" as a
ByteBuffer. You would mean direct connect hub userlists ?

no just something similar.


>P.S. I use ConcurrentHashMap because I had a lot of
>ConcurrentModificationException or something similar...this is really
thread- safe

i managed to avoid threading on the application level alltogether (after
switching to mina). it was really a relief and simplified the code a lot. i do
threads for some slower tasks, like sending out emails.

if you can give me a look at your code, i might better understand what you
have done and see, if you eventually can get rid of the need for additional
synchronization. i'm just curious. you can contact to me direcly off-list, if
you want.

kaspar


Mime
View raw message