The ECM exports a subset of a socket-like API. All applications are assumed to have well-known ports. In the current protocol 256 ports are supported based on a byte in the message header. We do not support dynamic application-to-port binding. This is because in our target platform, namely, Berkeley's MICA motes running TinyOS, applications are structured as a graph of permanently wired modules. The ECM demultiplexes incoming messages as upcalls to different application modules depending on their port number. The association of port numbers and upper layer modules is defined in a compile-time configuration. At run-time an application can call listen() to notify the ECM that it is ready to receive messages on its assigned port. Subsequently, the ECM propagates messages on this port to the application. If a message arrives for a port on which no application is listening, the message is dropped.
Connections are identified by a 
Entity ID, Port Num
pair.
When an entity is spawned, entity registration is invoked by the ECM.
This registration utilizes a directory service similar to the
indirection infrastructure described in [35]. Namely, each entity
maintains replicated pointers to its current location in a region of the
sensor network determined by a hash function. The hash key is the
signature identifier associated with the entity. By hashing this key,
the ECM can determine the location of the directory region associated
with a particular type of environmental event, then query the directory
for all entities that are currently following events of that
type. Queries to this directory service supply entity leader information
pertinent to establishing mobile connections.
When connecting with an entity, the ECM looks up the last known entity
leader based on the Entity ID, Port Num pair provided in the
application call. If this information is older than a specified
threshold the directory service is contacted for updated information.
The returned last-known leader is used as a connection point for
communication. Upon receiving a message, an endpoint updates its table
of last-known leaders with that contained in the header. The more
traffic exchanged between the endpoints, the more up-to-date the leader
information is.
Leadership information is retained in the ECM in a limited-size table. When the table is full, replacement is done on a least-recently-used basis. The ECM of an entity periodically refreshes the directory region, at an interval called the directory refresh rate to ensure that its information remains up to date. In addition, past followers of an entity remember the location of the last known leader for a time interval that exceeds the directory refresh rate. Hence, messages sent to the old location of an entity are forwarded to the current location when they intercept the entity's trail.