Place User IDs contain several fields which allow to retrieve interesting information about the Place User and its creation.
|
Deprecation warning The definition of Place User IDs may change in the upcoming AMETAS 2.7 release, in the next major release (AMETAS 3) at the very latest. This is in line with the deprecation of multicasting and the application of new security structures. Furthermore, the name/group addressing is obsolete and will be consistently replaced by the type system mechanisms. Please avoid to use Place User ID in the way as described below. The information is included for informational purposes, especially to migrate applications from earlier versions. |
Two of the fields create a unique ID: AMETASPlaceUserID is
subclassed from AMETASUniqueID which contributes the fields IP address and Timestamp. This would already allow to address a
single Place User, but if you want to address a group of Place Users,
you will need further data.

Figure 4: Internals of a Place User ID
There are two fields, name and group which allow
name should be a narrow group of agents; it could be the class name of the main agent class,
but this is not mandatory. The group declares a wider, secondary scope. You can use it to group all Place Users of one application.
Using name and group, you can structure your applications, based on a two-layer naming scheme.
Names and groups are declared as strings. The defaults are "NO_NAME" and "NO_GROUP". Such an agent is running perfectly. You can also choose other group criteria; this is totally up to the application designer.
Starter identity
The starter ID contains information about the identity (instance of AMETAS.data.AMETASIdentityID) which started this Place User, the owner of the Place User. You can use this information to send messages to Place Users belonging to the same identity.
Masks
It seems straightforward to use the ID to address single Place Users, but this restricts our addressing possibilities. On the one hand, we must know the precise Place User ID; on the other hand, we can only address one single Place User. In AMETAS, we introduced the Place User ID mask which is an instance of AMETASPlaceUserIDMask. A Place User ID mask can specify a group of Place Users by applying wildcards.
The Place User ID mask has the same field as the Place User ID, but it allows its fields to be set to
For a better understanding, we give you some examples.
| Name | Group | IP address | Timestamp | Starter ID | Meaning |
|---|---|---|---|---|---|
| Peter_1 | The Peters | 192.168.0.1 | 864204880510 | Peter | Exactly this agent instance. |
|
|
The Peters |
|
ANYTIME |
|
Describes the set of Place Users belonging to the group The Peters. |
| Peter_1 |
|
|
ANYTIME | Otto | Describes the set of Place Users with name Peter_1, started by a user (symbolically) referred to as Otto. |
|
|
|
|
ANYTIME |
|
Describes the set of all Place Users. This mask is also called broadcast mask. You may build this mask also by using the parameterless constructor of AMETASPlaceUserIDMask.
|
| Peter_1 |
|
192.168.0.1 | ANYTIME |
|
Describes the set of Place Users with name Peter_1, started on a host with address 192.168.0.1. This is a subset of the set of example 3. |
Table 1: Examples of Place User ID masks
The first example is called unicast mask. It only addresses exactly one instance.| The user name ("Peter") as the starter ID is only used symbolically, it is not a simple string. In the Place User ID as well as in a Place User ID mask, the user is represented by an instance of AMETASIdentityID. This object uniquely determines which user sent this agent. In an agent system, several people could be named as "Peter". Therefore, you must use such an instance for the user ID, not just the string. |
Setting just the IP address and timestamp already yields a unicast mask because this tuple is considered to be unique in the agent system.
Now we have all we need to find out how the communication between Place Users looks like.