]> oss.titaniummirror.com Git - tinyos-2.x.git/commitdiff
more fixes
authorgnawali <gnawali>
Thu, 4 Sep 2008 22:05:00 +0000 (22:05 +0000)
committergnawali <gnawali>
Thu, 4 Sep 2008 22:05:00 +0000 (22:05 +0000)
doc/txt/tep119.txt

index b7157e90eb3f779f21a2e72cad5e3fec264e0ef5..53a3cf6a5172835b29328efe1e80c0d90c6ac01f 100644 (file)
@@ -23,15 +23,15 @@ Abstract
 ====================================================================
 
 The memo documents the interfaces, components, and semantics used by
-collection protocol in TinyOS 2.x. Collection provides best-effort,
-multihop delivery of packets to one of a set of collection points.
-There may be multiple collection points in a network, and in this
-case the semantics are *anycast* delivery to at least one of the
-collection points. A node sending a packet does not specify which of
-the collection points the packet is destined to.  The union of the
-paths from each node to one or more of the collection points forms a
-set of trees, and in this document assume that collection points are
-the roots of these trees.
+the collection protocols in TinyOS 2.x. Collection provides
+best-effort, multihop delivery of packets to one of a set of
+collection points.  There may be multiple collection points in a
+network, and in this case the semantics are *anycast* delivery to at
+least one of the collection points. A node sending a packet does not
+specify which of the collection points the packet is destined to.  The
+union of the paths from each node to one or more of the collection
+points forms a set of trees, and in this document we assume that
+collection points are the roots of these trees.
  
 
 1. Introduction
@@ -90,9 +90,11 @@ root). Depending on their role, the nodes use different interfaces to
 interact with the collection component.
 
 The collection infrastructure can be multiplexed among independent
-applications, by means of a collection identifier. While data traffic
-in the protocol is multiplexed through these identifiers, control
-traffic is not: all data traffic uses the same routing topology.
+applications, by means of a collection identifier. The collection
+identifier is used to identify different data traffic at the sender,
+intermediate-nodes, or the receiver, much like port number in TCP. All
+data traffic, regardless of the collection identifier, use the same
+routing topology.
 
 The nodes that generate data to be sent to the root are *senders*.
 Senders use the Send interface [1_] to send data to the root of
@@ -130,11 +132,11 @@ use the Receive interface [1_] to receive a message delivered by
 collection. The collection identifier is specified as a parameter to
 Receive during instantiation.
 
-The set of all roots and the paths that
-lead to them form the collection routing infrastructure in the network.
-For any connected set of nodes implementing the collection protocol 
-there is only one collection infrastructure, *i.e.*, all roots in this 
-set active at the same time are part of the same infrastructure.
+The set of all roots and the paths that lead to them form the
+collection routing infrastructure in the network.  For any connected
+set of nodes implementing the collection protocol there is only one
+collection infrastructure, *i.e.*, all roots in this set active at the
+same time are part of the same infrastructure.
 
 The RootControl interface configures whether a node is a
 root::
@@ -175,10 +177,10 @@ which has the following signature::
   }
 
 
-CollectionC MAY have additional interfaces. These additional
-interfaces MUST have default functions on all outgoing invocations
-(commands for uses, events for provides) of those interfaces so that
-it can operate properly if they are not wired.
+CollectionC MAY have additional interfaces. All outgoing invocations
+(commands for uses, events for provides) of those interfaces MUST have
+default functions. Those default functions enable CollectionC to
+operate properly even when the additional interfaces are not wired.
 
 Components SHOULD NOT wire to CollectionC.Send. The generic
 component CollectionSenderC (described in section 3.1) provides
@@ -189,7 +191,7 @@ collection_id_t. Each collection_id_t corresponds to a different
 protocol operating on top of collection, in the same way that
 different am_id_t values represent different protocols operating on
 top of active messages. All packets sent with a particular
-collection_id_t generally have the same payload format, so that
+collection_id_t generally SHOULD have the same payload format, so that
 snoopers, intercepters, and receivers can parse them properly.
 
 ColletionC MUST NOT signal Receive.receive on non-root