It's an application network, not a file sharing network.
On the application level, you are presented with nodes and endpoints within nodes. You can send data to a node:endpoint combination, or tell the local node to invoke a certain handler when data arrives for the local node and a certain endpoint. Nodes are very much like TCP/IP hosts; endpoints are comparable to sockets.
Just like TCP/IP, there are 'well-known endpoints'. Endpoint numbers 0 to 16r0100 are reserved as well-known endpoints - peer list exchange, presence information exchange, etcetera are all handled through well-known endpoints. At the moment, there's no official registry of well-known endpoints; furthermore, services can be announced by name through presence which largely eliminates the use of well-known endpoints for applications on top of AWG. Like TCP/IP, a handler can be registered for a well-known endpoint or a dynamic endpoint. Handlers are simple code blocks that are called with two arguments: the data received and the node that sent the data. This extremely generic interface should give application designers a lot of flexibility (although it is likely that patterns will emerge that will be captured in additional AWG
classes).
Applications
The package currently sports two sample applications in the 'Tric-P2P' package on SqueakSource (DGV project):
However, the main application built with it is Kolibri
Nodes vs Peers
In these pages, I try to be careful with a distinction between my definitions of nodes and peers:
a node is any node on the network.
a peer, in the context of a node, is a member of the limited set of nodes that the node directly attempts to exchange information with.
Technically, each node knows the id of each other node on the network (in principle, and implicitely). Each node knows the UDP host:port of each of its peers. Data can be exchanged only directly with peers; to reach nodes that are not peers, the data needs to be sent off to one or more peers and they have to attempt to route it on.
