Hi,

In the MC rep at http://kilana.unibe.ch:8888/DGV there's a version of  
AardWorks-Gossip that we just
tested with a couple of people on IRC. The code can form spontaneous  
networks and is able to traverse multiple NAT's. So what is there actually  
works, at least if you do not put your expectations of 'works' too high  
;). There's a reasonable chance that actually trying to exchange data with  
other peers through the AWGPeer interface to the network will work, but  
you'd be the first to try.

The next step will be a demo app. I am thinking of a chat application  
because it has a nice mix of searching and direct-routing. The idea is  
that you get a button or world menu entry or whatever that says you're  
available for chat. Registration is of course under your developer  
initials :). Then, when something wants to chat with CdG, the p2p network  
hunts for the location of CdG, and starts a chat session.

Sounds neat and doable and the correct scope for a test app. But if anyone  
has a better idea for a killer app, shout.

(other idea: point to a local MC directory and declare that a publicly  
readable directory on the network. Presto, your code can now be found by  
package name by anyone on the network. V2 will add caching by intermediate  
nodes ;))

For those who want to sniff around, I'll leave a test server running on a  
publicly accessible box until it crashes or runs out of memory or goes off  
to make coffee. After loading the latest package from MC, do:

| peer |
peer _ AWGPeer newOnUDPPort: 16rCA01.
peer addPeer: UUID new
     host: (NetNameResolver addressForName: 'uk-1.aardworks.nl')
     port: 16rCA99.
peer explore

This should connect you to the bootstrap peer (note that this is just *a*  
introducer - you need to start somewhere but when the network is larger  
and especially when someone cobbles up a mechanism to export peer lists  
through out-of-band mechanisms like HTTP it can go away). If it is still  
running, root->peerId will hold your dynamically assigned peer id.  
root->peerList->entries should fill up with up to 30 addresses of other  
peers, most of them with very low hopCount.

There's documentation in the code in classes that are named after their  
packages. If you itch to play with this, look at the sending-receiving  
protocol of AWGPeer. That is normally the only protocol you need for  
interaction with the network - it has methods to send data to an endpoint  
on a certain peer, and to register code blocks that are triggered when  
data comes in for a certain endpoint on the local peer (endpoints are very  
much like TCP or UDP ports). Of course, this currently all operates with  
ByteArrays, a neat higher protocol layer is one of the things next on the  
to-do list.

Happy hacking,

Cees