Support for Native Applications

So far we have assumed that each end-host is free to choose its triggers independently. The natural question is how does an end-host learn about the trigger of another end-host? To answer this question, $i3$introduces the concept of public and private triggers [6]. Private triggers are secretly chosen by the application end-points. Public triggers can be computed by all end-hosts in the system and are used to establish initial contact with the desired end-host. For example, the public trigger of the ``New York Times'' web server can be the hash of its name.

Consider the application in Figure 5 where a client $A$ accesses a web server $B$. The web server $B$ maintains a public trigger with identifier $id_p$ in $i3$(step 1). The control path operations are as follows. Client $A$ inserts a private trigger with identifier $id_a$ into $i3$(step 2), and sends $id_a$ to web server $B$ via $B$'s public trigger $id_p$ (step 3). $B$ receives $id_a$ from $i3$(step 4) and inserts a private trigger with identifier $id_b$ into $i3$(step 5). $B$ then sends $id_b$ to $A$ via $A$'s private trigger $id_a$ (step 6), and $A$ receives it from $i3$(step 7). Finally, data packets from $A$ to $B$ flow through $B$'s private trigger $id_b$, and through $A$'s private trigger $id_a$ in the reverse direction. The important point to note here is that end-hosts have full control on selecting their private triggers.