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/?member_id=8660244&id_secret=101455710-f059c4 Powered by Listbox: http://www.listbox.com
