2

I am using Spring 5 Webclient using Reactor netty to make an HTTP API POST request. My code looks something like this:

HttpClient httpClient = HttpClient.create()
                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, 5000)
                .option(ChannelOption.SO_KEEPALIVE, true)
                .option(EpollChannelOption.TCP_KEEPIDLE, 300)
                .option(EpollChannelOption.TCP_KEEPINTVL, 60)
                .option(EpollChannelOption.TCP_KEEPCNT, 8)
                .doOnConnected(
                        connection ->
                                connection
                                        .addHandler(
                                                new ReadTimeoutHandler(1000,
                                                        TimeUnit.SECONDS))
                                        .addHandler(
                                                new WriteTimeoutHandler(1000)));

WebClient.builder()
                .baseUrl("//some url")
                .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE)
                .defaultHeader(HttpHeaders.ACCEPT, MediaType.APPLICATION_JSON_VALUE)
                .clientConnector(new ReactorClientHttpConnector(httpClient))
                .build();   

I was trying to set the TCP configs like TCP_KEEPIDLE, TCP_KEEPINTERVAL etc, and was hence reading about the same in the project reactor document.

The document said(I'm summarizing):

//The options below are available only when NIO transport (Java 11) is used
    .option(NioChannelOption.of(ExtendedSocketOptions.TCP_KEEPIDLE), 300)
    .option(NioChannelOption.of(ExtendedSocketOptions.TCP_KEEPINTERVAL), 60)
    .option(NioChannelOption.of(ExtendedSocketOptions.TCP_KEEPCOUNT), 8);

//The options below are available only when Epoll transport is used
    .option(EpollChannelOption.TCP_KEEPIDLE, 300)        
    .option(EpollChannelOption.TCP_KEEPINTVL, 60)        
    .option(EpollChannelOption.TCP_KEEPCNT, 8);         

What I dont understand here is what is the difference between NIO and Epoll transport or to be more specific what is transport at all? I'm aware of Transport layer and other layers of the OSI stack, but could not understand in what context is Transport is being used here. Any answer explaining this would be appreciated.

DockYard
  • 989
  • 2
  • 12
  • 29
  • 1
    Look at this answer https://stackoverflow.com/questions/23465401/why-native-epoll-support-is-introduced-in-netty – Violeta Georgieva Jul 14 '22 at 07:19
  • @VioletaGeorgieva Thanks. Could you please tell me how does the Netty client decide which transport(NIO or Epoll) it'll use. Or is there a way to configure this. – DockYard Jul 20 '22 at 06:10
  • 1
    By default Reactor Netty will use Epoll/Kqueue if the native libraries are on the path, otherwise NIO. You can use `runOn` configuration to configure this behaviour by yourself https://projectreactor.io/docs/netty/release/reference/index.html#client-tcp-level-configurations-event-loop-group – Violeta Georgieva Jul 20 '22 at 06:17
  • @VioletaGeorgieva Thanks. Actually I had asked this because of another issue which I've explained here https://stackoverflow.com/questions/73069155/getting-warning-unknown-channel-option-io-netty-channel-epoll-epollchannelopti Could you please answer it there – DockYard Jul 21 '22 at 15:48

1 Answers1

1

The transport term is coming from Netty. You can find an explanation on what is it in the Manning Live book: Netty in Action

The data that flows through a network always has the same type: bytes. How these bytes are moved around depends mostly on what we refer to as the network transport, a concept that helps us to abstract away the underlying mechanics of data transfer. Users don’t care about the details; they just want to be certain that their bytes are reliably sent and received.

If you have experience with network programming in Java, you may have discovered at some point that you needed to support a great many more concurrent connections than expected. If you then tried to switch from a blocking to a non-blocking transport, you might have encountered problems because the two network APIs are quite different.

Netty, however, layers a common API over all its transport implementations, making such a conversion far simpler than you can achieve using the JDK directly. The resulting code will be uncontaminated by implementation details, and you won’t need to perform extensive refactoring of your entire code base. In short, you can spend your time doing something productive.

To answer your question, in Netty you can use different transport implementations under a common API which corresponds more or less to the transport layer of the OSI model.

Ortomala Lokni
  • 56,620
  • 24
  • 188
  • 240