Originally we attempted to solve the first problem as follows. When a message is sent, BLAST would return a ticket to CHAN which would uniquely identify the storage associated with that message. BLAST supported a free resources operation which would free the message fragments associated with a valid ticket. When CHAN received an acknowledgment for a message it would invoke the BLAST free resource operation with the ticket. Unfortunately the only hint that CHAN had about the location of the BLAST protocol was that it was located below CHAN in the protocol graph. Thus the free resources control operation had to be inherited up the protocol graph. This is expensive and unfortunately will not work if there are two instances of BLAST configured below CHAN.
What is required is for some form of temporary communications link be set up between CHAN and whatever lower level protocol was used to send the current message. Hence the path of the message in question determines which lower level protocol needs to communicate with CHAN. Given that in the x-kernel messages traverse the graph using a series of successive xPush operations, the transport protocol could return any required information to CHAN as the return value for the xPush operation.
CHAN requires three pieces of information to resolve its action at a distance problems: an object pointer to the transport protocol it should invoke a free resource operation on, a ticket which allows the transport protocol to uniquely identify the message in question, and a reliability flag. By default CHAN assumes that there is no need to free resources and the underlying protocol is unreliable. Thus in the graph, ETH and IP do not have to return any information. BLAST must return a pointer to itself and a ticket. TCP need only return the information that it is reliable.