diff options
Diffstat (limited to 'docs/en/ranch/2.1/guide/listeners.asciidoc')
-rw-r--r-- | docs/en/ranch/2.1/guide/listeners.asciidoc | 479 |
1 files changed, 479 insertions, 0 deletions
diff --git a/docs/en/ranch/2.1/guide/listeners.asciidoc b/docs/en/ranch/2.1/guide/listeners.asciidoc new file mode 100644 index 00000000..9ee2d987 --- /dev/null +++ b/docs/en/ranch/2.1/guide/listeners.asciidoc @@ -0,0 +1,479 @@ +== Listeners + +A listener is a set of processes whose role is to listen on a port +for new connections. It manages a pool of acceptor processes, each +of them indefinitely accepting connections. When it does, it starts +a new process executing the protocol handler code. All the socket +programming is abstracted through the use of transport handlers. + +The listener takes care of supervising all the acceptor and connection +processes, allowing developers to focus on building their application. + +=== Starting a listener + +Ranch does nothing by default. It is up to the application developer +to request that Ranch listens for connections. + +A listener can be started and stopped at will. + +When starting a listener, a number of different settings are required: + +* A name to identify it locally and be able to interact with it. +* A transport handler and its associated options. +* A protocol handler and its associated options. + +Ranch includes both TCP and SSL transport handlers, respectively +`ranch_tcp` and `ranch_ssl`. + +A listener can be started by calling the `ranch:start_listener/5` +function. Before doing so however, you must ensure that the `ranch` +application is started. + +.Starting the Ranch application + +[source,erlang] +ok = application:start(ranch). + +You are then ready to start a listener. Let's call it `tcp_echo`. It will +have a pool of 100 acceptors, use a TCP transport and forward connections +to the `echo_protocol` handler. + +.Starting a listener for TCP connections on port 5555 + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{socket_opts => [{port, 5555}]}, + echo_protocol, [] +). + +You can try this out by compiling and running the `tcp_echo` example in the +examples directory. To do so, open a shell in the 'examples/tcp_echo/' +directory and run the following command: + +.Building and starting a Ranch example + +[source,bash] +$ make run + +You can then connect to it using telnet and see the echo server reply +everything you send to it. Then when you're done testing, you can use +the `Ctrl+]` key to escape to the telnet command line and type +`quit` to exit. + +.Connecting to the example listener with telnet + +[source,bash] +---- +$ telnet localhost 5555 +Trying 127.0.0.1... +Connected to localhost. +Escape character is '^]'. +Hello! +Hello! +It works! +It works! +^] + +telnet> quit +Connection closed. +---- + +=== Stopping a listener + +All you need to stop a Ranch listener is to call the +`ranch:stop_listener/1` function with the listener's name +as argument. In the previous section we started the listener +named `tcp_echo`. We can now stop it. + +.Stopping a listener + +[source,erlang] +ranch:stop_listener(tcp_echo). + +=== Suspending and resuming a listener + +Listeners can be suspended and resumed by calling +`ranch:suspend_listener/1` and `ranch:resume_listener/1`, +respectively, with the name of the listener as argument. + +Suspending a listener will cause it to stop listening and not accept +new connections, but existing connection processes will not be stopped. + +.Suspending a listener + +[source,erlang] +ranch:suspend_listener(tcp_echo). + +Resuming a listener will cause it to start listening and accept new +connections again. +It is worth mentioning, however, that if the listener is configured +to listen on a random port, it will listen on a different port than +before it was suspended. + +.Resuming a listener + +[source,erlang] +ranch:resume_listener(tcp_echo). + +Whether a listener is currently running or suspended can be queried +by calling `ranch:get_status/1` with the listener name as argument. + +=== Default transport options + +By default the socket will be set to return `binary` data, with the +options `{active, false}`, `{packet, raw}`, `{reuseaddr, true}` set. +These values can't be overridden when starting the listener, but +they can be overridden using `Transport:setopts/2` in the protocol. + +It will also set `{backlog, 1024}` and `{nodelay, true}`, which +can be overridden at listener startup. + +=== Listening on a random port + +You do not have to specify a specific port to listen on. If you give +the port number 0, or if you omit the port number entirely, Ranch will +start listening on a random port. + +You can retrieve this port number by calling `ranch:get_port/1`. The +argument is the name of the listener you gave in `ranch:start_listener/5`. + +.Starting a listener for TCP connections on a random port + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{socket_opts => [{port, 0}]}, + echo_protocol, [] +). +Port = ranch:get_port(tcp_echo). + +=== Listening on privileged ports + +Some systems limit access to ports below 1024 for security reasons. +This can easily be identified by an `{error, eacces}` error when trying +to open a listening socket on such a port. + +The methods for listening on privileged ports vary between systems, +please refer to your system's documentation for more information. + +We recommend the use of port rewriting for systems with a single server, +and load balancing for systems with multiple servers. Documenting these +solutions is however out of the scope of this guide. + +=== Listening on a UNIX Domain socket + +On UNIX systems, it is also possible to use Ranch to listen on a UNIX +domain socket by specifying `{local, SocketFile}` for the `ip` socket +option. In this case, the port must be set to 0 or omitted. The given +file must not exist: Ranch must be able to create it. + +.Starting a listener for TCP connections on a UNIX Domain socket + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{socket_opts => [ + {ip, {local, "/tmp/ranch_echo.sock"}}, + {port, 0} + ]}, echo_protocol, [] +). + +=== Performing additional setup steps on a listening socket + +If it is necessary to perform additional setup steps on the listening +socket, it is possible to specify a function with the transport option +`post_listen_callback`. This function will be called after the listening +socket has been created but before accepting connections on it, +with the socket as the single argument. + +The function must return either the atom `ok`, after which the listener +will start accepting connections on the socket, or a tuple +`{error, Reason}` which will cause the listener to fail starting with +`Reason`. + +.Setting permissions on a UNIX Domain socket file + +[source,erlang] +---- +PostListenCb = fun (Sock) -> + case ranch_tcp:sockname(Sock) of + {ok, {local, SockFile}} -> + file:change_mode(SockFile, 8#777); + {ok, _} -> + ok; + Error = {error, _} -> + Error + end +end, + +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{ + socket_opts => [ + {ip, {local, "/tmp/ranch_echo.sock"}}, + {port, 0}], + post_listen_callback => PostListenCb}, + echo_protocol, [] +). +---- + +=== Accepting connections on an existing socket + +If you want to accept connections on an existing socket, you can write +a custom `ranch_transport` implementation that fetches or otherwise +acquires a listening socket in the `listen/1` callback and returns it +in the form of `{ok, ListenSocket}`. + +The custom `listen/1` function must ensure that the listener process +(usually the process calling it) is also made the controlling process +of the socket it returns. Failing to do so will result in stop/start +and suspend/resume not working properly for that listener. + +=== Limiting the number of concurrent connections + +The `max_connections` transport option allows you to limit the number +of concurrent connections per connection supervisor (see below). +It defaults to 1024. Its purpose is to prevent your system from being +overloaded and ensuring all the connections are handled optimally. + +.Customizing the maximum number of concurrent connections + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{socket_opts => [{port, 5555}], max_connections => 100}, + echo_protocol, [] +). + +You can disable this limit by setting its value to the atom `infinity`. + +.Disabling the limit for the number of connections + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{socket_opts => [{port, 5555}], max_connections => infinity}, + echo_protocol, [] +). + +The maximum number of connections is a soft limit. In practice, it +can reach `max_connections` + the number of acceptors. + +When the maximum number of connections is reached, Ranch will stop +accepting connections. This will not result in further connections +being rejected, as the kernel option allows queueing incoming +connections. The size of this queue is determined by the `backlog` +option and defaults to 1024. Ranch does not know about the number +of connections that are in the backlog. + +You may not always want connections to be counted when checking for +`max_connections`. For example you might have a protocol where both +short-lived and long-lived connections are possible. If the long-lived +connections are mostly waiting for messages, then they don't consume +much resources and can safely be removed from the count. + +To remove the connection from the count, you must call the +`ranch:remove_connection/1` from within the connection process, +with the name of the listener as the only argument. + +.Removing a connection from the count of connections + +[source,erlang] +ranch:remove_connection(Ref). + +As seen in the chapter covering protocols, this reference is received +as the first argument of the protocol's `start_link/3` callback. + +You can modify the `max_connections` value on a running listener by +using the `ranch:set_max_connections/2` function, with the name of the +listener as first argument and the new value as the second. + +.Upgrading the maximum number of connections + +[source,erlang] +ranch:set_max_connections(tcp_echo, MaxConns). + +The change will occur immediately. + +=== Customizing the number of acceptor processes + +By default Ranch will use 10 acceptor processes. Their role is +to accept connections and spawn a connection process for every +new connection. + +This number can be tweaked to improve performance. A good +number is typically between 10 or 100 acceptors. You must +measure to find the best value for your application. + +.Specifying a custom number of acceptor processes + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{socket_opts => [{port, 5555}], num_acceptors => 42}, + echo_protocol, [] +). + +=== Customizing the number of connection supervisors + +By default Ranch will use one connection supervisor for each +acceptor process (but not vice versa). Their task is to +supervise the connection processes started by an acceptor. +The number of connection supervisors can be tweaked. + +Note that the association between the individual acceptors and +connection supervisors is fixed, meaning that acceptors will +always use the same connection supervisor to start connection +processes. + +.Specifying a custom number of connection supervisors + +[source,erlang] +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{socket_opts => [{port, 5555}], num_conns_sups => 42}, + echo_protocol, [] +). + +=== Setting connection count alarms + +The `alarms` transport option allows you to configure alarms +which will be triggered when the number of connections tracked +by one connection supervisor reaches or exceeds the defined treshold. + +The `alarms` transport option takes a map with alarm names as keys and alarm +options as values. + +Any term is allowed as an alarm name. + +Alarm options include the alarm type and a treshold that, when reached, +triggers the given callback. A cooldown prevents the alarm from being +triggered too often. + +.Log warnings when the number of connections exceeds 100 + +[source,erlang] +---- +Alarms = #{ + my_alarm => #{ + type => num_connections, + treshold => 100, + callback => fun(Ref, Name, ConnSup, ConnPids]) -> + logger:warning("Warning (~s): " + "Supervisor ~s of listener ~s " + "has ~b connections", + [Name, Ref, ConnSup, length(ConnPids)]) + end + } +}, +{ok, _} = ranch:start_listener(tcp_echo, + ranch_tcp, #{alarms => Alarms, socket_opts => [{port, 5555}]}, + echo_protocol, [] +). +---- + +In the example code, an alarm named `my_alarm` is defined, which will +call the given function when the number of connections tracked +by the connection supervisor reaches or exceeds 100. When the number of +connections is still (or again) above 100 after the default cooldown +period of 5 seconds, the alarm will trigger again. + +=== When running out of file descriptors + +Operating systems have limits on the number of sockets +which can be opened by applications. When this maximum is +reached the listener can no longer accept new connections. The +accept rate of the listener will be automatically reduced, and a +warning message will be logged. + +---- +=ERROR REPORT==== 13-Jan-2016::12:24:38 === +Ranch acceptor reducing accept rate: out of file descriptors +---- + +If you notice messages like this you should increase the number +of file-descriptors which can be opened by your application. How +this should be done is operating-system dependent. Please consult +the documentation of your operating system. + +=== Using a supervisor for connection processes + +Ranch allows you to define the type of process that will be used +for the connection processes. By default it expects a `worker`. +When the `connection_type` configuration value is set to `supervisor`, +Ranch will consider that the connection process it manages is a +supervisor and will reflect that in its supervision tree. + +Connection processes of type `supervisor` can either handle the +socket directly or through one of their children. In the latter +case the start function for the connection process must return +two pids: the pid of the supervisor you created (that will be +supervised) and the pid of the protocol handling process (that +will receive the socket). + +Instead of returning `{ok, ConnPid}`, simply return +`{ok, SupPid, ConnPid}`. + +It is very important that the connection process be created +under the supervisor process so that everything works as intended. +If not, you will most likely experience issues when the supervised +process is stopped. + +=== Upgrading + +Ranch allows you to upgrade the protocol options. This takes effect +immediately and for all subsequent connections. + +To upgrade the protocol options, call `ranch:set_protocol_options/2` +with the name of the listener as first argument and the new options +as the second. + +.Upgrading the protocol options + +[source,erlang] +ranch:set_protocol_options(tcp_echo, NewOpts). + +All future connections will use the new options. + +You can also retrieve the current options similarly by +calling `ranch:get_protocol_options/1`. + +.Retrieving the current protocol options + +[source,erlang] +Opts = ranch:get_protocol_options(tcp_echo). + +=== Changing transport options + +Ranch allows you to change the transport options of a listener with +the `ranch:set_transport_options/2` function, for example to change the +number of acceptors or to make it listen on a different port. + +.Changing the transport options + +[source,erlang] +ranch:set_transport_options(tcp_echo, NewOpts). + +You can retrieve the current transport options by calling +`ranch:get_transport_options/1`. + +.Retrieving the current transport options + +[source,erlang] +Opts = ranch:get_transport_options(tcp_echo). + +=== Obtaining information about listeners + +Ranch provides two functions for retrieving information about the +listeners, for reporting and diagnostic purposes. + +The `ranch:info/0` function will return detailed information +about all listeners. + +.Retrieving detailed information +[source,erlang] +ranch:info(). + +The `ranch:procs/2` function will return all acceptor or listener +processes for a given listener. + +.Get all acceptor processes +[source,erlang] +ranch:procs(tcp_echo, acceptors). + +.Get all connection processes +[source,erlang] +ranch:procs(tcp_echo, connections). |