address

In our model of a conference, applications are associated with a machine and possibly a user at a particular machine. Thus we use a representation of the user or the machine as a field in the tuple, to allow us to specify applications by location.. The <#1948#> address<#1948#> field will normally be registered as one of the following:

<#1950#> hostname<#1950#>
<#1951#> username@hostname<#1951#>

When the application is associated with a user, such as a shared whiteboard, the <#1953#> username@hostname<#1953#> form is used, whereas applications which are not associated with a particular user, such as a video switch controller register simply as <#1954#> hostname<#1954#>. For simplicity, we use the domain naming scheme in our current implementation, although this does not preclude other identifiable naming schemes. Note that the hostname is actually shorthand for <#1955#>no-user@hostname<#1955#>, so that when When other applications wish to send a message to a destination group (a single application is a group of size 1), they can specify the <#1956#> address<#1956#> field as one of the following:

<#1958#> username@hostname<#1958#>
<#1959#> hostname<#1959#>
<#1960#> *@hostname<#1960#> - Note that the hostname is actually shorthand for <#1961#>no-user@hostname<#1961#>, so that this matches all applications on the given host.
<#1962#> *<#1962#> - this is used to address applications regardless of location.

The CCC library is responsible for ensuring a suitable multicast group (or other means) is chosen to ensure that all possible matching applications are potentially reachable (though depending on the reliability mode, it does not necessarily ensure the message got to them all). It should be noted that in any tuple containing a wildcard (<#1964#> *<#1964#>) in the address, specifying the instantiation (as described below) does not guarantee a unique receiver, and so normally the instantiation should be wildcarded too.