|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object | +--dd.api.DDRouteMsg | +--dd.api.DDMacRouteMsg
Messages sent from one OceanStore machine to any other, which are guarenteed to have come from the listed sender. To send a message from one OceanStore machine to any other, one simply inherits from this class, filling in the proper serialization code for the inherited class's data. (The DD stage will take care of the fields in this class itself.)
Implementation-wise, this is simply a route-to-root operation, with a MAC concatenated to the message.
Messages with MACs that do not verify correctly will not be dispatched within the machine. The old DD interface allowed messages with failing MACs to be dispatched, on the assumption that they might still contain useful information. I have since come to believe that such an interface will invariably lead to security holes; it is simply too easy to forget to check whether the MAC was correctly verified before reading the message. If the same functionality is still desired, we can add a new event to the API for it--something like DDUnVerifiedRouteMsg.
For the same reason, this message is an different type than DDRouteMsg. I do not want to give clients of this interface the opportunity to fail to check whether each message included a MAC or not. It is generally the case that a certain message type must always be MAC'ed, or it should never be. I have yet to see a case where either option fit a single message.
DDRouteMsg
Field Summary |
---|
Fields inherited from class dd.api.DDRouteMsg |
---|
dd_intermediate_upcall, hopCount, inbound, one_hop, peer, recursive_route, TTL |
Constructor Summary | |
---|---|
protected |
DDMacRouteMsg()
Empty constructor. |
protected |
DDMacRouteMsg(InputBuffer buffer)
Constructs a DDMacRouteMsg from its
serialized form. |
|
DDMacRouteMsg(SecureHash peer,
boolean recursive_route,
boolean dd_intermediate_upcall,
boolean one_hop)
Constructor: Creates a new DDMacRouteMsg .
|
Methods inherited from class dd.api.DDRouteMsg |
---|
serialize |
Methods inherited from class java.lang.Object |
---|
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Constructor Detail |
public DDMacRouteMsg(SecureHash peer, boolean recursive_route, boolean dd_intermediate_upcall, boolean one_hop)
DDMacRouteMsg
.
Use for new outbound messages.
An example parameter setting to account for DDRouteMsg.hopCount
and DDRouteMsg.TTL
:
Another example parameter setting to route as quickly as possible where
for DDRouteMsg.hopCount
and DDRouteMsg.TTL
do not matter:
peer
- target destination node guid
.recursive_route
- If true
recursive
route
between src and dest; otherwise, iterative
route. See
DDRouteMsg.recursive_route
for more details.dd_intermediate_upcall
- If true
, the underlying DHT
will generate an upcall event to the DD on each intermediate node
in the path. Otherwise, the underlying DHT will send the message
directly to the dest. dd_intermediate_upcall==true
is
necessary for DDRouteMsg.hopCount
and
DDRouteMsg.TTL
to be accounted for correctly;
otherwise, the values are undefined.one_hop
- One hop is a (possible) optimization. Since the DD
maintains a host
db
, it is possible to look up
the DDRouteMsg.peer
entry in the the
db
. If an entry exists, the
can forward the message directly to the DDRouteMsg.peer
in one hop.protected DDMacRouteMsg()
protected DDMacRouteMsg(InputBuffer buffer)
DDMacRouteMsg
from its
serialized
form.
buffer
- serialized
form of object.
|
|||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | ||||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |