First host implementation.

Hosts consist of two internal processes: monitor_outgoing_packets and monitor_incoming_packets. These follow a passivate/reactivate framework through the events send_packet and receive_packet, respectively. Note that the host class itself performs the reactivations of its two internal processes. Flows and links indirectly reactivate the internal host processes through the send_packet and receive_packet API, respectively.

Is this a suitable framework for process interaction? I like this better than interruptions since one cannot pass objects through interruptions (I think). If this looks good, let's commit to this model for future process interactions.

Tests to follow upon implementation of environment, flows, and links.
I might not have understood your question fully, but here's my rationale on the monitor_incoming_packets() method. For definitions, a "sending_flow" sends data packets and receives acknowledgements, while a "receiving_flow" receives data packets and sends acknowledgements.

The key is that a sending_flow and its corresponding receiving_flow share the same flow_id. That way, a host can simply look at the flow_id parameter on an incoming packet and forward it to the appropriate flow regardless of the packet type. For example, if the host gets an acknowledgement packet, it will just check the flow_id of the packet and pass it off to the sending_flow with the matching parameter. There is never any telepathy going on between sending_flows and receiving_flows.