The following guidelines describe when out of band connection and disconnection messages are received, and how this interacts with the framework provided to IAF adapters:

Transports and codecs will not be sent events until after their start function has been called and completed. Transports should not start generating events until their start function has been called. The first event that is delivered after the start function is called will be a SenderConnected or ReceiverConnected event, if the semantic mapper is configured to pass them through. An adapter will always receive the SenderConnected before it begins to receive any other events, but the ordering of the ReceiverConnected and SenderConnected events is not guaranteed.

If a correlator (or other component) disconnects or terminates while the adapter is running, the adapter will receive both ReceiverDisconnected and SenderDisconnected events. Again, the ordering of these events is not guaranteed. Once a SenderDisconnected event is received, no further events from that correlator will be received until a SenderConnected event is received. When a ReceiverDisconnected event is received, no more events will be sent to that correlator until a ReceiverConnected event is received. Note that in this situation, some previously sent events may not yet have reached that correlator. The events will be discarded (or sent to other receivers, if other receivers are connected).

On a reload of an adapter, the adapter will be stopped, new configuration loaded, and the adapter restarted. During this period, the IAF will not drop its connection unless the configuration of which components to connect to has changed. As such, if prior to stopping for a reload the correlator was connected, it is safe to assume that it remains connected unless, on reload, the adapters receive SenderDisconnected or ReceiverDisconnected events.

During a reload, the IAF can also load new adapters. In this event, as the IAF may already have a connection open, no ReceiverConnected or ReceiverDisconnected event may be received by the new adapters. It is thus recommended to not change transports and codecs when reconfiguring the IAF if the adapters depend on receiving the out of band events. In practice, it is unusual to change the loaded transports or codecs.

Once an adapter has entered a stopped state, it will not receive any further events (unless it later re-enters a started state). Since the shutdown order of the IAF is to move all adapters to their 'stopped' state, then disconnect from downstream processes, adapters will not receive a final 'disconnected' event. Therefore, the adapter may need to notify external systems on the stop function being called, as well as on disconnected events.

The following topics describe the ordering the transport will see of calls to start, stop and the transport receiving out of band and normal events.