Mike said,
I assume that a 'conversation' would include all nodes interested in the discussion, and that when new nodes join they would be brought up to date and could then contribute resources. Exactly, I would employ Jabber, a low bandwidth, client/server instant messaging protocol to initiate this process. But because I desire a partitioned, distributed, and locally-cached knowledge base, there will be a need for agent peers to frequently exchange knowledge chunks with other peers. Its for this latter low-latency, high bandwidth P2P communication that I am considering NAT hole punching. Is there already an existing framework for this kind of communication? Not that I have found that fits close enough for my purpose. Please if anyone has suggestions, let me know. I want to reuse existing solutions as much as possible. By the way, the N2N software provides TCP connectivity, not UDP and the former is closer to the needs of the Texai software application. If you're going to build it, do you intend to keep the mechanism open enough that it could transport other kinds of data, or keep it tightly coupled to your application? N2N is very open in that it establishes a VPN that any application can then use. Texai by design will be a friendly system. Among the useful behaviors that users teach it may be the transport of non-knowledge data from one peer to another. There will eventually be a policy mechanism throughout the Texai agents that would ensure that Texai agents behave in a legal manner, that should prevent the transport of materials that Texai knows the user cannot legally distribute. Cheers. -Steve Stephen L. Reed Artificial Intelligence Researcher http://texai.org/blog http://texai.org 3008 Oak Crest Ave. Austin, Texas, USA 78704 512.791.7860 ----- Original Message ---- From: Mike Dougherty <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, May 5, 2008 12:26:43 AM Subject: Re: [agi] organising parallel processes On Sun, May 4, 2008 at 11:28 PM, Stephen Reed <[EMAIL PROTECTED]> wrote: > be like Skype, the popular non-scum Internet phone service that also > performs NAT hole punching (a.k.a. NAT traversal). I was not aware Skype worked like that- thanks for the info. If you are using a similar form of UDP-listener to allow the client to make a connection out where the firewall then allows responses in, you wouldn't be violating existing protocol. (and admins could turn off the feature that auto-whitelists UDP responce) > services. Relays could become performance bottlenecks too. For an initial > deployment I would like to try direct P2P unless you have a better > objection, or maybe you could just clarify the remarks you already made, > given my own clarification herein. Of course a test network can be direct P2P. I can configure my firewall (both dedicated hardware and per-machine software) to allow whatever I want. I was suggesting that a dynamic network could allow nodes to advertise their capability and perform relay services to clients that do not have direct access. From the article you posted above, it seems that the auto-whitelisting of ports for UDP response ( my firewall calls them triggered ports - if I send out port X, expect legitimate return replies on X+1 through X+Y) - your client application would only need to access any public node in the cloud to become an active server. > Thanks for the great comment. I do really do not want to waste time with the > wrong P2P design decision. I like to brainstorm. I know a little bit about computer networking. I know a little more about programming. I don't know much about artificial intelligence design, so I've mostly just been lurking here. I think if the nodes in your graph were to reinforce the existence of their connections simply by using them, it would facilitate new connections forming and becoming available for other nodes according to whatever propagation rules you devise. As the developer, you would only need to understand the mechanism on a theoretical level- there would be too much dynamic state to micromanage (or hand-code) a snapshot of the network graph at any given moment. I assume that a 'conversation' would include all nodes interested in the discussion, and that when new nodes join they would be brought up to date and could then contribute resources. Is there already an existing framework for this kind of communication? If you're going to build it, do you intend to keep the mechanism open enough that it could transport other kinds of data, or keep it tightly coupled to your application? I'm on a tangent now... it's difficult to think about this kind of thing via email. ttyl. ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?&; Powered by Listbox: http://www.listbox.com ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ------------------------------------------- agi Archives: http://www.listbox.com/member/archive/303/=now RSS Feed: http://www.listbox.com/member/archive/rss/303/ Modify Your Subscription: http://www.listbox.com/member/?member_id=8660244&id_secret=101455710-f059c4 Powered by Listbox: http://www.listbox.com
