Configuring Netty Server Backend

Default Configuration💻

Play uses the following as the default configuration: 

play.server {

  #  server provide class name
  provider = "play.core.server.NettyServerProvider"

  netty {

    #  Default value of the `Server` header for producr if no explicit `Server`-header included in a response.
    # Suppose this value is the null and no header included in the request, no `Server` header to be rendered at all.

    server-header = null
    server-header = ${?play.server.server-header}

    # Event loop threads numbers. Netty decides when it is 0, which by default will select 2 times the number of
    # available processors.

    eventLoopThreads = 0
@*
 *Max length of the initial line. Effectively restricts maximum length of the URL that  * the server will
* accept, the initial line consist of the method (3-7 characters),  the HTTP version (8 *characters), and  the URL, 
*having typical whitespace, the max URL length will be number - 18.
*@
    maxInitialLineLength = 4096

    # The max length of body bytes that Netty read into memory at a time.
    # This is used in many ways. Note this setting has no relation to HTTP chunked transfer encoding - Netty will
    @*
* read "chunks", that is, byte buffers worth of content at a time and pass to Play, *regardless of whether the body
 * using HTTP chunked transfer encoding. One HTTP chunk could span multiple *Netty chunks if exceeds this.
 *@
@*
*A body which is not HTTP chunked will span multiple Netty chunks if exceeds this *or no content length is
 *specified. Only controls the maximum length of Netty chunk byte buffers.
*@
    maxChunkSize = 8192

    # Whether Netty wire should be logged
    log.wire = false

    # The transport to be use, either jdk or native.
    # Native socket transport have higher performance and produces less garbage but are only available on linux 
    transport = "jdk"

    # Netty options. Possible keys defined by:
    #
    # http://netty.io/4.1/api/io/netty/channel/ChannelOption.html
    #  native socket transport:
    # https://netty.io/4.1/api/io/netty/channel/unix/UnixChannelOption.html
    # https://netty.io/4.1/api/io/netty/channel/epoll/EpollChannelOption.html
    #
    # Options pertain to the listening server socket defined at the top level, options for sockets associated
    # with received client connections prefixed with child.*
    option {

      # Set size of the backlog of TCP connections. The default, exact meaning of this one parameter JDK specific
      # SO_BACKLOG = 100

      child {
        # Set whether connections to use TCP keep alive
        # SO_KEEPALIVE = false

        # Set whether TCP no delay flag is set
        # TCP_NODELAY = false

        # Example to set native socket transport options
        # (Full qualified class name + "#" + option)
        # "io.netty.channel.unix.UnixChannelOption#SO_REUSEPORT" = true
        # "io.netty.channel.epoll.EpollChannelOption#TCP_FASTOPEN" = 1
      }
    }

  }
}

This above-given configuration is specific to the Netty server backend
play {

  server {
    @*
*The root directory of the play server instance. This value could
*be set by providing path as the first argument to the Play server
*launcher script. See `ServerConfig.loadConfiguration`.
*@
    dir = ${?user.dir}

    # HTTP configuration
    http {
      # The HTTP port of the server. Use a value of "disabled" if the server
      # shouldn't bind an HTTP port.
      port = 9000
      port = ${?PLAY_HTTP_PORT}
      port = ${?http.port}

      # The interface address to bind to.
      address = "0.0.0.0"
      address = ${?PLAY_HTTP_ADDRESS}
      address = ${?http.address}
@*
      *The idle timeout for open connection after which it will be closed
      * Set to null or "infinite" to disable the timeout, but notice this
      * is not encouraged since timeout is an important mechanism to protect your
      * servers from malicious attacks or programming mistakes.
*@
      idleTimeout = 75 seconds
    }

    # HTTPS configuration
    https {

      # The HTTPS port of the server.
      port = ${?PLAY_HTTPS_PORT}
      port = ${?https.port}

      # The interface address to bind to
      address = "0.0.0.0"
      address = ${?PLAY_HTTPS_ADDRESS}
      address = ${?https.address}

      # The idle timeout for open connection after which it will be closed
@*
      * Set to null or "infinite" to disable the timeout, but notice that this
      * is not encouraged since timeout is important mechanisms to protect your
      * servers from malicious attacks or programming mistakes.
*@
      idleTimeout = ${play.server.http.idleTimeout}

      # The SSL engine provider
      engineProvider = "play.core.server.ssl.DefaultSSLEngineProvider"
      engineProvider = ${?play.http.sslengineprovider}

      # HTTPS keystore configuration, use the default SSL engine provider
      keyStore {
        # The path to the keystore
        path = ${?https.keyStore}

        # The type of the keystore
        type = "JKS"
        type = ${?https.keyStoreType}

        # The password for the keystore
        password = ""
        password = ${?https.keyStorePassword}


        # The algorithm to use. If not set, use the platform default algorithm.
        algorithm = ${?https.keyStoreAlgorithm}
      }

      # HTTPS truststore configuration
      trustStore {


        # If true, does not CA verification on client side certificates
        noCaVerification = false
      }

      # Whether JSSE want client authentication mode should be used. This means, the server
      # will request client certificate, but will not fail if one is not provided.
      wantClientAuth = false

      # Whether JSSE need client auth mode must be used. This means, the server
      # will request client certificate, and will fail and terminate the session
      # if one isn't provide.
      needClientAuth = false
    }

    # The path the process id file created by the server when it runs.
    # If set to "/dev/null" then no pid file will be created.
    pidfile.path = ${play.server.dir}/RUNNING_PID
    pidfile.path = ${?pidfile.path}

    websocket {
      # Maximum allowed frame payload length. Setting this value to your application's
      # requirement may reduce denial service attacks using long data- frames.
      frame.maxLength = 64k
      frame.maxLength = ${?websocket.frame.maxLength}
    }

    debug {
      # If set true this will attach an attribute to each request containing debug-information. If the application
      # fails to load (example- due to a compile issue in dev mode), then this configuration value ignored and the debug
      # information always attached.
      #
      # Note: This configuration option not part of Play's public API and is subject to change without usual
      # deprecation cycle.
      addDebugInfoToRequests = false
    }

    # The maximum length of HTTP headers. The most common effect of this is restriction in cookie length, including
    # number of cookies and size of the cookie values.
    max-header-size = 8k

    # If a request contains Content-Length header it will be checked against this maximum value.
    # If the value of given Content-Length header exceeds this configured value, request will not be processed
    # further but instead the error handler will call with Http status code 413 "Entity too large".
    # If set to infinite or no Content-Length header exists then no check will take place at all
    # and the request will continue to processed.
    # Play uses the concept of `BodyParser` to enforce this limit, so we set it to infinite.
    max-content-length = infinite
  }

  editor = ${?PLAY_EDITOR}

Configuring Transport Socket🙄

Native socket transport has higher performance & produces less garbage but is only available on Linux. We can configure the transport socket type in application.conf:

play.server {
  netty {
    transport = "native"
  }
} 

The available options are defined in Netty-channel option documentation. If we are using native socket transport, you can set Unix channel option and Epoll channel option additional options. The options listed above are particular to the Netty server backend, although there are other more general setups available.

Frequently Asked Questions

What is Netty?

Netty is a network application framework that is asynchronous and event-driven.

What is pro and con of native transport socket?

Native socket transport has higher performance & produces less garbage but is only available on Linux.

Netty is which type of framework?

An NIO(Non-Blockin I/O) client server framework that allows for the rapid and simple building of network applications such as protocol servers and clients. 

Which protocols have been used to design Netty?

A lot of protocols such as HTTP, SMTP, FTP, binary and text-based legacy protocols have been used to get the data and then Netty has been designed.

How is Netty a good tool to use?

Netty has found a method to provide performance, ease of development, flexibility, and stability without sacrificing quality.

Conclusion

In this article, we extensively discussed the netty server backend configuration. We started with the introduction of the netty server. Then we saw the default configuration of the netty server. Then we learnt about the configuration of the transport socket of the netty server. In the end, we saw the frequently asked questions. 

Now you must be curious after knowing about web2py and how simple it is to learn. You can visit Basics of Python with Data Structures and Algorithms and Free Python Foundation with DS and Algo and start your journey.

Nevertheless, you may consider our paid courses to give your career an edge over others!

You can refer to other similar articles as well

• Configuring Logging
• Configuring Akka Http Server Backend
• Configuring Play Thread Pools
• Key Concepts of Cloud Logging
• Viewing Logs in Cloud logging
   

Happy Learning Ninja! 🥷