User:Carrd
From LagoonWiki
Contents |
Current Work
07.21.06
Today Juan and I finished implementing a system that seperates the behavior guis from the behaviors themselves, so that they can be instantiated seperately on the server and clients. It hasn't been tested much yet, but right now it seems that the gui on the server looks and feels just like it did before, but it controls the behaviors on the clients.
Doing this required reimplementing the networking message system to use tnl rpc's and changing the api a little so that messages can be sent to a specific client. It also meant adding a behaviorParams module in cat that holds all of the parameters for behaviors and can be accessed by either the guis or the behaviors without the other one there, and uses the messaging system to keep a synchronized copy of behavior parameters for all behaviors on the server to be used by the gui.
07.11.06
I've been working for the last couple days on getting a solid cluster system set up. I put the code (except for the code that uses it in entity.py and entitySet.py) in common/cluster.py. At this point it will use a network of client computers (still with gfx and gui) to run behaviors and networks. All important rmenu, behavior creation, and network manipulation messages are sent around the network and consumed by clients using an intuitive api. Here are some details about each part:
Network Management
This is implemented in the class ClusterServer in cluster.py as well as several functions in ntnl and nconnection. This class registers all clients with the server and gives them unique ids and keeps a list of clients, entities, and a map between them on the server. On the server side, EntitySet registers and unregisters entities with clusterServer as they are created and destroyed, and clusterServer assigns the entities to available clients. On the client side, the client checks if a given entity belongs to it with a simple call to ClusterServer.entityBelongsToMe(ent) and uses that information to tell if it should process (or create) the behaviors for this entity. The system is robust to clients coming on and off and also to not having any clients available by saving entities until a client comes online.
Message System
The message system is implemented in cluster.py as two functions. The first, registerClusterMessageFunction, registers a callback function to a message name. Whenever a message is posted under any entity in the eva tree, the registered function is called with the entity and the message. The second function, postClusterMessage, puts a message into a given named message slot in a specified entity that is in turn passed around the network through the eva tree. This system seems good right now, but there are two problems. The first is that when entities are created they have to pass their EVAPath to initEntityForCluster so that the appropriate values can be initialized in the eva tree. The second problem is that in order for the values to get sent around the network, they have to be added to boat.xml.
Finally, I have some images I took of the cluster running with one client.
This image shows the system running with 25 entities using route in san diego at 15fps (and between 0-4 on the client).
This Image shows the system running around 25 entities using the move network (under group command) out in open water at around 15fps.
07.07.06
For at least the next couple weeks or so, I'm going to be working with Juan on making Lagoon work on a cluster. The main challenge for doing this is keeping copies of behaviors on cluster nodes. This means copying behavior events and behavior parameters across the network. The part that I will be working on is copying events across the network, to do this I will be looking at adding functionality to EntitySet to send and recieve rmenu events through the eva tree, and propagate the events to the proper handlers when they are recieved. This should allow things like behavior creation and execution to be spread across the network.
