Notes

=Implementation Notes=

This section describes some of the details of the current VAST implementation, for those interested to investigate further or to play around.

Main Components
VAST now consists of several major components, each responsible for a different task:
 * **VASTVerse:** Factory class for generating and destroying VAST nodes.
 * **VASTClient:** Functionality exposed to a simple VAST client node.
 * **VASTMatcher**: A super-node that handles publish / subscribe requests, maintains subscription-client mapping, and forms a VON.
 * **VASTRelay:** A forwarding super-node that provides extra out-going bandwidth for matcher to deliver messages to clients.
 * **VONPeer:** Full implementation of the VON mechanism, without ID assignment.
 * **VSOPeer:** Full implementation of the VSO mechanism.
 * **VASTnet:** Network layer that provides cross-platform socket connection capability
 * **VASTsim:** A simulation component that takes care of VAST node generation, time-step evolution, and moving entities on simulated paths.

Unique ID Assignment
Note that in the original VON design, ID assignment is handled by the VON gateway. Now we consider that ID assignment can in fact be independent from VON's proper operations, and thus is removed as part of the VON functionality. VON now simply assume some external mechanism exists for the ID assignment.

Unique ID assignment now is done by the VASTnet component (run on the Gateway), but note that other assignment mechanisms are possible.

**Initialization Procedure**
VAST initiates the following components (in order) when VASTVerse::createVASTNode is called:


 * 1) VASTnet: establish socket connection capability and obtains unique ID for the VAST node from the Gateway's VASTnet component.
 * 2) VASTRelay: determine physical coordinate by pinging a few known hosts, so a joining VAST node may connect with the closest Relay, if it does not have a public IP. If public IP exists, then the VAST node considers itself as a valid Relay and connects to itself.
 * 3) VASTMatcher: if the VAST node has public IP, it can be a potential Matcher and will register itself with the Gateway.

When VASTnet, VASTRelay, and VASTMatcher are all initialized, a VAST node is considered to be //initialized//.

VAST Operations
For executing the VAST operations, a VAST client would do the following (as defined in /include/VAST.h and implemented by VASTClient class):
 * join : send out JOIN request to the Gateway, with the world_id to join.
 * leave : send LEAVE request to current Matcher, also some statistics to the Gateway
 * subscribe : send SUBSCRIBE request to current Matcher, with the AOI, layer, current Host ID, current Relay info.
 * publish : send PUBLISH request to current Matcher, with the publication area, message, layer info.
 * move : send MOVE request to current Matcher if only updating the AOI's center position, and MOVE_F if updating AOI radius as well.
 * send : send SEND request to current Matcher with custom message type, message, and a list of target receiver's IDs.
 * list : return a list of other currently known clients.