AgentOS Meeting Minutes

August 4, 1997.

Had a long discussion about how to implement AgentGroups. The primary concern was with joinGroup(AgentGroup) Problem #1: The system would have to locate the group dynamically every time, possibly incurring a huge overhead. Problem #2: It is probably impossible to prevent creation of two groups with duplicate names without a centralized group management authority. We want to avoid having a centralized group server, for fault tolerance reasons. However, we're open to the possibility of complementing a distributed group management system with a centralized server. If the centralized server goes down, the system can rely on the distributed algorithm alone.

The proposed solution to these problems is to change the joinGroup mechanism to joinGroup(AgentGroup, AgentOSNode) or joinGroup(AgentGroup, AgentInstanceID), so that the prospective group participant specifies a node or an agent which is known to be in the group. This means that two groups with the same name can be created at the same time on two different nodes. Any prospective participant must specify with group to join by specifying a node with is already a part of the group. The listGroups() function will still list all groups in the network through a distributed search, but it is possible for groups to have the same user-defined name. Of course, each group still has a globally unique ID, like each agent does.

Discussed possibility of using Petri Nets instead of FSMs for representing agent algorithms. FSMs seem limited and cannot represent multiple simultaneous events. Will bring materials about Petri Nets and possibly start learning about them.

Albert is looking into reliable multicast algorithms, how to use the MulticastSocket, and how to use MBONE.

Ranjit is continuing with the plan of improving the agent launch and transport mechanisms.

Calvin is working on FSM representations for his mail agents.

An is working on FSM representations for his bulletin board agents.