its buffer.

(0,0) circle \[radius=1.25\]; at (0,0) [A]{}; (6,0) circle \[radius=1.25\]; at (6,0) [B]{}; (.9,1.0) – (5.1,1.0); at (3,1.25) [`BEACON`]{}; (1.25,0.33) – (4.75,0.33); at (3,0.58) [`REPLY`]{}; (1.25,-0.33) – (4.75,-0.33); at (3,-0.08) [`REPLY_BACK`]{}; (.9,-1.0) – (5.1,-1.0); at (3,-0.75) [Messages]{};

Message Identification and Limits
---------------------------------

Since our implementation manages messages instead of packets, we use a different `EpidemicHeader` than PacketEpidemic [@Alenazi:2015:ERP:2756509.2756523]. Figure \[fig:EpidemicDTNEpcHdr\] illustrates the `EpidemicHeader`. First, the 64-bit Message Identification Number from Section \[sec:MessageGeneration\] replaced the 32-bit packet identification number. Since the Message Identification Number includes the source node and timestamp of message generation, we do not use a separate timestamp field.

[32]{}\
\
\

The uses hop limits and message to reduce network resource consumption. The lower 48-bit portion of the Message Identification Number permits the routing protocol to remove expired messages from a node’s buffer. When a node receives a message, the node checks the timestamp against the maximum age of a message. If the timestamp exceeds the amount of time a message can live, then the node discards the message. The `EpidemicHeader` 32-bit hop count field is used limit the number of hops that a message can traverse. When nodes generate a message, they initialize the hop count 