This structure is created by the wrapper each time a channel is opened, and is maintained by the wrapper code. (The wrapper also maintains a dual, the channel-instance structure.)
This structure contains function pointers for the "inner" callbacks invoked by the wrapper.
channel A pointer to the associated channel-instance structure.
full_messages Indicates whether the profile-instance is using the frame-oriented or the message-oriented interface. In the latter case, if the receive buffer fills up before a complete message is received, then pro_window_full being invoked.
user_ptr1 A user-defined pointer.
user_ptr2 A user-defined pointer.
user_long1 A user-defined long-value.
user_long2 A user-defined long-value.
|struct CHANNEL_INSTANCE *||channel|
Confirms the final disposition of the close request.
This is invoked regardless of who asked to close the channel. (If invoked by the local peer, it's invoked after the close request callback has returned.) If the channel is now closed, the profile-instance structure is about to be deallocated, so the profile should release any instance-specific resources, e.g., referenced by user_ptr1 and user_ptr2.
|void(*||pro_close_confirmation )(struct PROFILE_INSTANCE *pi, char commit_or_rollback, struct diagnostic *error, char local_or_remote, char session_or_channel)|
Indicates that a <close>element has been received for the specified profile-instance, or that the local peer is asking to close this channel or the entire session.
|void(*||pro_close_indication )(struct PROFILE_INSTANCE *pi, struct diagnostic *status, char local_or_remote, char session_or_channel)|
|void(*||pro_frame_available )(struct PROFILE_INSTANCE *pi)|
Announces that a message has arrived and is ready to be read, if the profile is using the message-oriented interface.
The profile should call bpc_query_message to fetch a linked-list of the frames making up the message, followed by bpc_frame_destroy. It may also be convenient to call bpc_frame_aggregate to collapse the data from the linked-list into a character buffer.
|void(*||pro_message_available )(struct PROFILE_INSTANCE *pi)|
Confirms that the given channel has been started successfully.
This is invoked after the start request callback has returned. If the <start> is refused by the remote peer via the return of an <error> element, then this callback is not made, and only the start request callback is called. On a channel started by the local peer, this is the first function invoked on the new profile-instance.
|void(*||pro_start_confirmation )(void *client_data, struct PROFILE_INSTANCE *pi, struct profile *po)|
Indicates that a <start> element has been received for the specified profile-instance.
To determine the servername to use, the callback should first invoke bp_server_name. If NULL, then consult pi->channel->inbound->server_name instead.
|void(*||pro_start_indication )(struct PROFILE_INSTANCE *pi, struct profile *po)|
Confirms the final disposition of a tuning reset.
If a tuning reset actually occurred, the profile-instance structure is about to be deallocated, so the profile should release any instance-specific resources, e.g., referenced by user_ptr1 and user_ptr2.
|void(*||pro_tuning_reset_confirmation )(struct PROFILE_INSTANCE *pi, char commit_or_rollback)|
Indicates that a local profile is getting ready to perform a tuning reset, e.g., the TLS profile is getting ready to send the <ready> element.
This is a FYI for the profile-instance -- there isn't an opportunity to prevent the tuning reset from happening.
|void(*||pro_tuning_reset_indication )(struct PROFILE_INSTANCE *pi)|
Announces that the receive buffer for a profile has filled, but that a complete message has not yet been received.
The profile should do one of:
|void(*||pro_window_full )(struct PROFILE_INSTANCE *pi)|