]> oss.titaniummirror.com Git - tinyos-2.x.git/blobdiff - doc/txt/tep116.txt
Updated behavior and comments
[tinyos-2.x.git] / doc / txt / tep116.txt
index 2de57c1cc7ce6359c44ae8ad59fc5f5916498d36..6f0a6d1fd991397b45c086b6809abcc8b371482c 100644 (file)
@@ -138,7 +138,7 @@ parameter in their send call, this command is not required for
 sending, and so is never called in common use cases. Instead, 
 it is a way for queues and other packet buffering components
 to store the full state of a packet without requiring additional
-memory allocation.
+memory allocation. 
 
 The distinction between ``payloadLength`` and ``maxPayloadLength``
 comes from whether the packet is being received or sent. In the receive
@@ -221,7 +221,9 @@ has this signature::
   interface AMPacket {
     command am_addr_t address();
     command am_addr_t destination(message_t* amsg);
+    command am_addr_t source(message_t* amsg);
     command void setDestination(message_t* amsg, am_addr_t addr);
+    command void setSource(message_t* amsg, am_addr_t addr);
     command bool isForMe(message_t* amsg);
     command am_id_t type(message_t* amsg);
     command void setType(message_t* amsg, am_id_t t);
@@ -232,6 +234,12 @@ The command address() returns the local AM address of the
 node. AMPacket provides accessors for its two fields, destination and
 type. It also provides commands to set these fields, for the same
 reason that Packet allows a caller to set the payload length.
+Packet interfaces SHOULD provide accessors
+and mutators for all of their fields to enable queues and other
+buffering to store values in a packet buffer. Typically, a component
+stores these values in the packet buffer itself (where the field is),
+but when necessary it may use the metadata region of message_t or other
+locations.
 
 2.2 Sending interfaces
 --------------------------------------------------------------------
@@ -290,6 +298,14 @@ use a QueueC (found in tos/system) to store pending packet pointers
 and serialize them onto sending interface, or they can introduce
 a new sending interface that supports multiple pending transmissions.
 
+The cancel command allows a sender to cancel the current transmission.
+A call to cancel when there is no pending sendDone event MUST return FAIL.
+If there is a pending sendDone event and the cancel returns SUCCESS, then
+the packet layer MUST NOT transmit the packet and MUST signal sendDone
+with ECANCEL as its error code. If there is a pending sendDone event
+and cancel returns FAIL, then sendDone SHOULD occur as if the cancel
+was not called. 
+
 2.3 Receive interface
 --------------------------------------------------------------------