[Dundi] Core Members?

[Kirk Wolff]

Hello Florian,

Perhaps we should think about modifying the DUNDi protocol to resolve
the problems that have been uncovered through implementation.  I know
the guys at messinet have similar problems but the purpose of the
network is to resolve them as they arise.  Below are some of my
thoughts:


The first problem is the GPA; it prevents mapping of the system.  There
should be a means of testing each node and have it return its exposed
dialplan so we know what numbers a person is presenting to the rest of
the peers.  Also, a person should be able to perform this same action
locally so they can see what they are exposing.  

A second addition that seems to be evolving out of usage is the need for
a blacklist.  Perhaps there should also be a means of detecting invalid
dialplans.  I'm not sure how to do this as I don't know what the
definition of an 'invalid dialplan' is and am not sure if there is such
a definition.  Its possible that failed connections to a lookup-response
could be reported back to the originating node through the dundi chain
and each node in the chain could store that failed connection message.
If a node doesn't fix its failed connections in a reasonable number of
failed attempt reports or number of days then that node would be
blacklisted automatically.  It would be more fair if the maintainer were
notified of failed connections through email.

Thirdly, it seems to me that DUNDi requires too much structure.  Its
apparent that it must be organized in a top-down methodology.  One
should be able to attach to a cloud by way of a key or password, but not
be constrained to a single node.  At present each connection requires
hard-coded configuration changes on both ends of the DUNDi link.  If a
'hub' node goes down, all peers connected to that node will lose their
connection to the cloud.  I believe DUNDi should be more 'gnutella' or
'torrent' like where requests can go out into the cloud, but the path
isn't fixed and each node in the cloud should prevent query loops by
caching results passing through that node.  The cloud should also
self-organize by balancing their available (or configured allowable)
bandwidth and their activity.  Each node in the cloud should be able to
attach dynamically to any other node in the cloud and a configurable
number of 'maximum active connections' should be maintained.  

For security, the shared key method can be used, but the key should be
cloud-wide.  I'm not sure how to accomplish this method of security,
perhaps a simple 'network password' could be defined so only peers that
have been accepted would be given the cloud password.  A public password
has its disadvantages so a system could be devised to automatically
change it.

Another possible method of security is to have a system of automatically
sharing the 'allowable public keys' amongst all the nodes in the cloud.
if an existing node adds a new node to the cloud, it will push that new
node's public key to all other nodes in the cloud.  Then the new node
can connect to any of the participating nodes.  It could be configurable
on a particular node whether you accept new node keys automatically or
if they have to be manually installed.  If a node on the network is
misbehaving, that node's key or node ID could be blacklisted and that
blacklist could be pushed to all nodes in the same way as the keys are
shared.  This way, it only takes one node to approve a new node the
cloud, but any node in the cloud could blacklist any other node.  

Any thoughts?

- Kirk



-----Original Message-----
From: Florian Overkamp <florian at speakup.nl>
Reply-to: Distributed Universal Number Discovery
<dundi at lists.digium.com>
To: Distributed Universal Number Discovery <dundi at lists.digium.com>
Subject: Re: [Dundi] Core Members?
Date: Tue, 24 Aug 2010 17:36:36 +0200

Hello,

On 08/24/2010 05:16 PM, Kirk Wolff wrote:
> Hi all, I'm trying to join your DUNDi cloud.  I'm already a member of
> messinet.
>
> I've tried contacting all of the 'core members' listed on your
website,
> all of their websites no longer exist with exception to voicepulse.

I think you will find our website also still really works :)

> I appears there is no DAHDI cloud other than a few very private ones.

The actual usage of DUNDI peering using the GPA'ed e164 context is 
indeed very thin. The biggest downside of this technology as we can see 
it, is the fact that there is no easy and verifyable means to block 
faulty routes for remote members. For telco's to put their trust into 
such a system requires this, because hunting after customer complaints 
is fun once, but a nasty drag the second time around. I must admit our 
usage of DUNDI has been fairly limited these last few years, mainly 
because I see no movement on the problematic field mentioned above.

In the meantime, DUNDI has indeed been put to very good use in building 
privately controlled clusters. So I think DUNDI can continue to be
used, 
but not in the sense that Mark envisioned it years ago....

-- 
Met vriendelijke groet,

Florian Overkamp
SpeakUp BV
T: 088-SPEAKUP (088-7732587)
T: 053-4305842

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/dundi/attachments/20100824/fa1b7434/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://lists.digium.com/pipermail/dundi/attachments/20100824/fa1b7434/attachment.pgp