server chat with erlang

Joe Armstrong (TN/EAB) joe.armstrong@REDACTED
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

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
		with Ip address IPi

		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


		M fails.

		All clients notice this and try to re-connect


		cache the server lists etc.


		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:joelr1@REDACTED] 
> 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
> --

More information about the erlang-questions mailing list