On 08/24/2010 12:43 PM, Kirk Wolff wrote: > 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.
What you are describing has a great deal of overlap with the P2PSIP work being done in the IETF already, which unfortunately is a long way from being usable, and also infringes on a number of patents based on IPR claims that have been published. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: [email protected] Check us out at www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Dundi mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/dundi
