# server chat with erlang

Joe Armstrong (TN/EAB) <>
Tue Aug 15 09:28:55 CEST 2006

```Yes - actually a hybrid architecture is probably best - pure P2P is
difficult - a fast central server can help a lot.

Imagine a 3-tire architecture

a - servers (say 3 of these)
b - super nodes
c - clients

a) keeps an updated list of all known super-nodes
clients can query servers for a list of all known super nodes

b) super nodes - are on-lien for a long time and accept incoming
connections

c) nodes are behind firewalls

Suppose we have an irc group called #erlang

A client wishes to join #erlang

1) it fetches the list of supernodes from the server
suppose this is IP1, IP2, IP3

2) it finds out which of these machines IP1, .. IPn is
"responsible" for the #erlang group

How, we compuer the "closest# machine

Compute K1 = md5(IP1) mod 2^32
K2 = md5(IP2) mod 2^32 etc.

Imagine these as points in a circle mod^32.

Compute J = md5(#erlang) mod 2^32

This also lies on this circle.

Now find the closest point.

Compute abs(Ki - J) = Di forall i in 1..n

The value of i which minimises Di is the required
machine

call the closest machine M

3)  Client sends a "join #erlang" message to M

M will now either:

- create a new process to represent #erlang
- of connect the incoming client to a #erlang group

From now on M is the master machine for #erlang

Failures

M fails.

All clients notice this and try to re-connect

Optimisations

cache the server lists etc.

Notes

Partitioning might occur - if a new super node joins at
a point
near to a super node for some group, then existing group members
an new
member might arrive at different super nodes.

To avoid this the super nodes should periodically check that
they are in-fact the responsible node for the groups that they
think they
are controlling.

> -----Original Message-----
> From: Joel Reymont [mailto:]
> Sent: den 14 augusti 2006 17:33
> To: Joe Armstrong (TN/EAB)
> Cc: Erlang Questions
> Subject: Re: server chat with erlang
>
> I don't think you can completely eliminate the server. You
> need one for clients to discover each other, keep track of
> chat rooms, etc.
> Once clients connect they can proceed to communicate directly.
>
> On Aug 14, 2006, at 4:04 PM, Joe Armstrong ((TN/EAB)) wrote:
>
> > The challenge is to elimiate the servers, making the clients
> > collectivly behaving as a server.
> >
> > /Joe
>
> --
> http://wagerlabs.com/
>
>
>
>
>
>

```