1  |   Order by index

Aug 3, 2000, 5:11pm

This is a multi-part message in MIME format.

------=_NextPart_000_012C_01BFFD5B.191F5BC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

No only on signon. After the signon both clients would be aware of each =
other and any change could be sent via a datagram relayed to the other =
client via aw. This way all that would be required would be a "ping" =
every 120 seconds or so. AW wouldn't even have to use the same server to =
deliver the datagrams. In any event, AW will have to remove this contact =
limit somehow if they want to grow as a company. All the major =
communicators (ICQ,AIM etc) don't have these limits despite incredible =
traffic. ICQ uses a less centralized system but AW could do this if =
Yahoo did it. I would suspect they could easily handle all aw's contact =
info on a 486 FreeBSD box with even a cable connection. I'm sure they =
have T-3 at least.
To get back to the hypothetical 600 connected clients with 100 contacts =
each, correct me if I am wrong but isn't the full list pushed from the =
aw server every 60 seconds or so now?
that would be in this case 60,000 lookups causing an update of all 600 =
clients every 60 seconds. A rewriting of the list I believe. This is a =
costly solution as in 99% of the push updates the list being updated is =
unchanged. If all that was needed was a pass through ping =
client>server>client>server>client then any disc usage (lookups) would =
be kept to a minimum as they wouldn't be needed in most cases. Without =
so many disc lookups the system overhead would be drastically reduced =
and a contact limit could be set to a ridiculously high 5-10 thousand =
and that just to fend off hacker overload attempts. The overhead would =
be reduced on the client side as well.
The solution you have in Bone seems interesting but seems to me that the =
server overhead would be immense in that it is looking up several lists =
(and authentication too I'm sure) before pushing an update to several =
clients. (please correct me if this is inaccurate)
I think a lot of this redundancy is not needed.=20
PC

[View Quote] I don't see "only a fitgh of the computing overhead" here, while the =
contact list would be much less accurate.=20

AFAIK contacts should be using a "push" method, and the 100 slots =
maintained on the server do just that.

I agree that it is quite a load if the server has to browse through =
all the 100 slots on all conntected contacts, and i would not be =
surprized if there was some optimizaiton in place.

In bone i have a similar approach to contacts, and my optimization is =
to not only keep the clients contacts on the server using the "slots =
technique" (which is a list in the bone case), but also maintain a =
reverse-lookup list on each session saying who is interested in contact =
updates originating from that session.. the former is more for contact =
list maintainance and the latter for the actual determination of where =
to send contact updates. This puts more load on the processing of the =
contact list that a client send, however.=20

AFAIR bone does not have a contacts limit :)

Faber



"pc" <pcat at blackrosesoftware.com> schrieb im Newsbeitrag =
news:3988781e$1 at server1.Activeworlds.com...
I don't understand the logic in keeping a full list of a clients =
contacts on the server at all. Why couldn't the server just
maintain 5 data fields per citizen, those being citizen name, a =
field indicating online or offline or disabled, a "handshake flag" and 2 =

others for future use. A client on signon could update field 2 IF =
that client wasn't marked invisible. The handshake flag could=20
contain a field that would be a default zero lets say and if a =
citizen had anyone blocked that would change to a 1 to indicate that an
online request should poll his client for an "ignore list" so to =
speak. when client 2 signed on it would poll the aw server for the
status of the contacts on his list. the AW server would react based =
on field 3 and either return the status or look up the ignore
list on the client requested. In this way AW could still middleman =
the transaction without the ridiculous overhead of searching
through 100 or more lists per client. This is a simplistic solution =
that could be refined by adding different options to the third
value in the server side array.
Another side effect would be an increased privacy to the client as =
their own contact lists wouldn't have to be stored on aw central. You =
could have unlimited contacts at a fifth of the computing overhead.

PC


[View Quote] The contacts are stored in the server, that means, the server =
maintains a field of 100 contact "slots" for each aw citizen currently =
connected. Then whenever another citizen connects or disconnects, the =
server has to browse all those contact arrays and check if anyone is =
interested in the presence or absence of the citizen that just =
(dis-)connected. If so, the notice about the presence state change is =
properly sent.

Now, if 600 People are connected, and each have 100 people on =
their contacts, the server would have 60000 citizen number comparisons =
to make just because of a single connect. This is the current state, =
which means the server can cope with it, but imagine the contact list =
would have 200 (which i belive is still a limit people would complain =
about) or even more slots.=20

So there has to be a limit to the size of the contact list.

The other approach, maintaining the contacts on the client side, =
would cause every connect to be broadcasted to the clients, and then =
discarded by most :). And this method would also break any hopes of =
being able to to opt-out of another guys contact list, since the weak =
security model here would invite people to "spy" on contact updates and =
break the rules.=20

Faber

"pc" <pcat at blackrosesoftware.com> schrieb im Newsbeitrag =
news:39884f52$1 at server1.Activeworlds.com...
The bandwidth overhead of an unlimited contact list to aw should =
be minimal. Think about it...there are sites out there getting http hits =
at the rate of over 500 hits per second and handling it. Its beyond me =
how anyone can have more that 100 contacts on their list but it should =
be allowed for those who would.
PC

[View Quote] ------=_NextPart_000_012C_01BFFD5B.191F5BC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4134.600" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>No only on signon. After the signon =
both clients=20
would be aware of each other and any change could be sent via a datagram =
relayed=20
to the other client via aw. This way all that would be required would be =
a=20
"ping" every 120 seconds or so. AW wouldn't even have to use the same =
server to=20
deliver the datagrams. In any event, AW will have to remove this contact =
limit=20
somehow&nbsp;if they want to grow as a company. All the major =
communicators=20
(ICQ,AIM etc) don't have these limits despite incredible traffic. ICQ =
uses a=20
less centralized system but AW could do this if Yahoo did it. I would =
suspect=20
they could easily handle all aw's contact info on a 486 FreeBSD box with =
even a=20
cable connection. I'm sure they have T-3 at least.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To get back to the hypothetical 600 =
connected=20
clients with 100 contacts each, correct me if I am wrong but isn't the =
full list=20
pushed from the aw server every 60 seconds or so now?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>that would be in this case 60,000 =
lookups causing=20
an update of all 600 clients every 60 seconds. A rewriting of the list I =

believe. This is a costly solution as in 99% of the push updates the =
list being=20
updated is unchanged. If all that was needed was a pass through ping=20
client&gt;server&gt;client&gt;server&gt;client then any disc usage =
(lookups)=20
would be kept to a minimum as they wouldn't be needed in most cases. =
Without so=20
many disc lookups the system overhead would be drastically reduced and a =
contact=20
limit could be set to a ridiculously high 5-10 thousand and that just to =
fend=20
off hacker overload attempts. The overhead would be reduced on the =
client side=20
as well.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The solution you have in Bone seems =
interesting but=20
seems to me that the server overhead would be immense in that it is =
looking up=20
several lists (and authentication too I'm sure) before pushing an update =
to=20
several clients. (please correct me if this is inaccurate)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>I think a lot of this redundancy is not =
needed.=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>PC</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"faber" &lt;<A =
href=3D"mailto:Walter at Knupe.de">Walter at Knupe.de</A>&gt;=20
[View Quote] compressed of course, and your contacts will filter it out, I =
have=20
attached an example file the AW server would send you, the =
numbers I=20
wrote at complete random, so if you see your number here, I =
didn't do=20
it on purpose=20
=
:)</FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOC=
KQUOTE></BODY></HTML>

------=_NextPart_000_012C_01BFFD5B.191F5BC0--

1  |   Order by index