dd.api
Class DDMacRouteMsg

java.lang.Object
  |
  +--dd.api.DDRouteMsg
        |
        +--dd.api.DDMacRouteMsg
All Implemented Interfaces:
QueueElementIF, QuickSerializable
Direct Known Subclasses:
RequestDisseminationSetResponseMsg

public abstract class DDMacRouteMsg
extends DDRouteMsg

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.

Version:
$Id: DDMacRouteMsg.java,v 1.3 2004/05/04 23:21:08 hweather Exp $
Author:
Sean Rhea
See Also:
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

DDMacRouteMsg

public DDMacRouteMsg(SecureHash peer,
                     boolean recursive_route,
                     boolean dd_intermediate_upcall,
                     boolean one_hop)
Constructor: Creates a new 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:

Parameters:
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.

DDMacRouteMsg

protected DDMacRouteMsg()
Empty constructor. For use by derived types when reconstructing themselves from a byte array.


DDMacRouteMsg

protected DDMacRouteMsg(InputBuffer buffer)
Constructs a DDMacRouteMsg from its serialized form.

Parameters:
buffer - serialized form of object.