Once a FADA node is set up it can be used to store service proxies. Service providers will offer a service proxy for their service/s. This proxy must be written in Java, but the service provider can use whatever implementation for its service (either Java RMI, HTTP, JNI and some other language, JXTA, etc), always keeping in mind that those proxies will be downloaded by clients and will execute from the clients' Java Virtual Machines (JVM from now on). This means that clients might be computationally poor machines, and the service proxy is expected to work even under those conditions. Also, the network connection of the client might be of low performance. This must also be taken into account. The service proxies should be simple and small.
If the service provider uses the FADA Toolkit class FADAHelper it is very easy to register a service proxy. The lease housekeeping is done by this class, so the service provider need not to fiddle with it.
The flooding algorithm consists in the following:
A node starts a broadcast: it sends the broadcast message through all the known connections.
A node receives a broadcast message by any connection: it keeps the message identifier, then sends the message to all known connections except the one the message came from.
A node receives a broadcast message whose identifier is already in the list of identifiers: the message is dropped silently, because receiving an already received message means there is a cycle in the structure. By dropping the message we make sure we avoid infinite loops.
Service searches will be triggered by a client in a known node. This node will do local lookup, and will also extend the search to all known neighbors, using the flooding algorithm. To allow fast response, the lookup results from every node are NOT sent back in the same way that lookup requests came by (called routing). Instead they are directly reported to the interested node. Also, the local node lookup and the lookup extension is done in parallel by the use of threads.
To avoid overloading the FADA node that started the lookup with responses, there are some ways to limit the number of responses sent to a node. The first one is the distance limit. A lookup request will only be sent to nodes that are as much a predefined number of hops away from the origin of the lookup request. This limits the radius of the area where the lookup request is sent.
The second one is time. Once a maximum number of milliseconds have passed since the starting of the results recovery the results structure will be returned and destroyed. Any additional response from a remote node will be discarded. This doesn't avoid incoming connections, but avoids memory flooding in the origin node. A virtual global time is used by every FADA node. FADA nodes use ntp servers to synchronize their virtual clocks.
The third one is space. Once a maximum number of responses have been received the results structrure will be returned and destroyed. Any additional response from a remote node will be discarded. This doesn't stop the broadcast mechanism nor avoids incoming connections, but avoids memory flooding in the origin node.
Project hosted by