|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object | +--net.captp.tables.NearGiftTable
Untamed: Rendezvous point for 3-vat live Granovetter introductions of Resolved remote references (FarRefs).
Where we normally speak of Alice giving Bob a reference to Carol, we here speak of the Donor (VatA) giving to the Recipient (VatB) a reference to the Gift (Carol) residing on the Host (VatC). There is one NearGiftTable in the Host per Donor. The Donor associates the gift with a Nonce, the Recipient's ID, and the SwissHash of the gift. She then tells the Nonce and swissHash to the Recipient. The Recipient asks the Host "What gift has Donor (identified by DonorID) deposited for me at this Nonce and swissHash?".
A Nonce is a use-once unique number. It only needs to be "impossible" to collide under benevolent assumptions; it doesn't need to be unguessable, so perhaps a 64 bit number could have been used instead. For now, we just use our normal unguessable numbers (given by 'entropy nextSwiss()').
When the donor registers the gift, the swissHash should be verified (by the NearGiftTable's immediate client, the NonceLocator) to correspond to the gift, which should be Near. The key under which the gift is stored is the triple [recipient ID, nonce, swissHash]. The corresponding loopup must match on all three, and must be satisfied immediately. To Allow services with Near arguments the recipient's Far reference must be made to correspond to a local Near reference, or it must become a DisconnectedRef. In order to guarantee that the loopup can be satisfied immediately, we must ensure that the corresponding registration arrives first. For this, we expect to use the unimplemented Wormhole technique, documented at the above URL. Until then, the first case must be avoided. This avoidance results in the Lost Resolution bug.
An interesting complexity: A partition could prevent the operation from completing, in which case the Recipient cannot be left hanging, and the association must be cleaned up.
Field Summary | |
private FlexMap |
myStuff
Maps from [recipID, Nonce, swissHash] to gift |
Constructor Summary | |
NearGiftTable()
Enabled: @param nonceLocatorPromise A RemotePromise for the Donor's NonceLocator. |
Method Summary | |
Object |
acceptFor(String recipID,
BigInteger nonce,
BigInteger swissHash)
Enabled: Lookup the gift. |
void |
drop(String recipID,
BigInteger nonce,
BigInteger swissHash)
Enabled: Automagically called when the vine is dropped. |
Vine |
provideFor(Object gift,
String recipID,
BigInteger nonce,
BigInteger swissHash)
Enabled: Make the gift available to the recipient so long as the Vine is held onto (isn't garbage). |
void |
smash(Throwable problem)
Enabled: Disable this table. |
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Field Detail |
private FlexMap myStuff
Constructor Detail |
public NearGiftTable()
Method Detail |
public void smash(Throwable problem)
public Vine provideFor(Object gift, String recipID, BigInteger nonce, BigInteger swissHash)
public Object acceptFor(String recipID, BigInteger nonce, BigInteger swissHash)
Note that this message is named "acceptFor" whereas the corresponding NonceLocator message is names "acceptFrom". In acceptFor, the recipient is explicit and the donor implicit. In acceptFrom, the donor is explicit and the recipient implicit.
recipID
- The vatID of the vat (Bob, the gift recipient) that the
gift is being picked up for.nonce
- Identifies (together with the recipID) the gift.public void drop(String recipID, BigInteger nonce, BigInteger swissHash)
The Donor is able to call this as well, which isn't appropriate, but isn't dangerous, so what the hell.
|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |