View Source ssh_server_channel behaviour (ssh v5.2)

-behaviour(ssh_server_channel). (Replaces ssh_daemon_channel)

Note

This module replaces ssh_daemon_channel.

The old module is still available for compatibility, but should not be used for new programs. The old module will not be maintained except for some error corrections

SSH services (clients and servers) are implemented as channels that are multiplexed over an SSH connection and communicates over the SSH Connection Protocol. This module provides a callback API that takes care of generic channel aspects for daemons, such as flow control and close messages. It lets the callback functions take care of the service (application) specific parts. This behavior also ensures that the channel process honors the principal of an OTP-process so that it can be part of a supervisor tree. This is a requirement of channel processes implementing a subsystem that will be added to the ssh applications supervisor tree.

Note

When implementing a client subsystem handler, use -behaviour(ssh_client_channel) instead.

Summary

Callbacks

Handles other messages than SSH Connection Protocol, call, or cast messages sent to the channel.

Handles SSH Connection Protocol messages that may need service-specific attention. For details, see ssh_connection:event/0.

Makes necessary initializations and returns the initial channel state if the initializations succeed.

This function is called by a channel process when it is about to terminate. Before this function is called, ssh_connection:close/2 is called, if it has not been called earlier. This function does any necessary cleaning up. When it returns, the channel process terminates with reason Reason. The return value is ignored.

Callbacks

Link to this callback

handle_msg(Msg, State)

View Source (since OTP 21.0)
-callback handle_msg(Msg :: term(), State :: term()) ->
              {ok, State :: term()} | {stop, ChannelId :: ssh:channel_id(), State :: term()}.

Handles other messages than SSH Connection Protocol, call, or cast messages sent to the channel.

Possible Erlang 'EXIT' messages is to be handled by this function and all channels are to handle the following message.

  • {ssh_channel_up, ``t:ssh:channel_id/0``, ``t:ssh:connection_ref/0``} - This is the first message that the channel receives. This is especially useful if the server wants to send a message to the client without first receiving a message from it. If the message is not useful for your particular scenario, ignore it by immediately returning {ok, State}.
Link to this callback

handle_ssh_msg/2

View Source (since OTP 21.0)
-callback handle_ssh_msg(ssh_connection:event(), State :: term()) ->
                  {ok, State :: term()} | {stop, ChannelId :: ssh:channel_id(), State :: term()}.

Handles SSH Connection Protocol messages that may need service-specific attention. For details, see ssh_connection:event/0.

The following message is taken care of by the ssh_server_channel behavior.

  • {closed, ``t:ssh:channel_id/0``} - The channel behavior sends a close message to the other side, if such a message has not already been sent. Then it terminates the channel with reason normal.
Link to this callback

init(Args)

View Source (since OTP 21.0)
-callback init(Args :: term()) ->
        {ok, State :: term()} |
        {ok, State :: term(), timeout() | hibernate} |
        {stop, Reason :: term()} |
        ignore.

Makes necessary initializations and returns the initial channel state if the initializations succeed.

The time-out values that can be returned have the same semantics as in a gen_server. If the time-out occurs, handle_msg/2 is called as handle_msg(timeout, State).

Link to this callback

terminate(Reason, State)

View Source (since OTP 21.0)
-callback terminate(Reason :: normal | shutdown | {shutdown, term()} | term(), State :: term()) -> term().

This function is called by a channel process when it is about to terminate. Before this function is called, ssh_connection:close/2 is called, if it has not been called earlier. This function does any necessary cleaning up. When it returns, the channel process terminates with reason Reason. The return value is ignored.