作者回复: 全部读下来，没找到你的问题，也没发现哪里不对，所以:正解！

作者回复: option和childoption是设置不同socket channel的，分别服务于ServerSocketChannel和SocketChannel。 之所以用了child前缀作为区分，是因为服务的channel有父子关系（前者产生后者: SocketChannel = serverSocketChannel.accept();）。 他们都在channel初始化时使用，具体而言。前者是在启动服务时，后者是在创建连接时，但是这里有个问题是，就是可以设置的option是共享的，这就导致，一些参数（例如io.netty.channel.ChannelOption#SO_BACKLOG， ）仅仅对serversocketchannel有效，但是可能会不小心设置给socketchannel。例如本应该是.option(ChannelOption.SO_BACKLOG, 100)，却不小心写成了.childOption(ChannelOption.SO_BACKLOG, 100)，这样的话，会发生什么？实际上并没有报错，只是后期使用时，可能无法生效，可以说是一个隐蔽的坑。这里要注意下。 所以你的问题，总结下就是：设置的参数服务目标不同，且应该根据不同的目标选择参数，当然这些参数有一些是都可以设置的，有一些却是专有的。上面的例子也说了。

作者回复: 配合方式有很多种，你这种是可以的，而且很多也这么做，然后不管哪种，只要收发消息都需要编解码，所以才是统一的(不然不就不是消息的一种了么？)，你在案例中可能没有看到显示编解码，而是直接写出了消息。那是因为这个写的过程经过了之前写的二对编解码器了，所以都会做的，也应该做的。

作者回复: 问题1：对的；问题2：也对，但是问题2的（1）你写反了吧？observeOutput = true。这里补充说下，这么大的文件，应该用chunk的方式那写了，否则容易OOM的。

作者回复: 这个在第六章的dubbo那节都会讲到，这里先简单说下: 1 dubbo用了二个版本，有二个文件夹 2 是的，它的客户端用idle来触发keepalive了，server端的idle直接断连，两个配合一起用

作者回复: 会的，如果你设置idle监测的时间低于你的keepalive时间，然后没数据，就会监测到空闲后就关闭连接，就是你说的情况，所以一般把空闲监测的时间设置的比keepalive大，这样就好了。当然这里说的都是应用层keepalive.你说的那个tcp层的keepalive对应用层的idle监测并没用，idle监测是应用层在做，它看的是应用层有没有数据，而不是tcp层的，另外idle监测主要是保护系统的，优化系统的，所以连接正常也可能触发的

作者回复: 因为应用层的keeplive属于应用层，而且每个协议，除了那些流行的外，大多是我们自己的内部写的应用，都不同，所以他不知道我们怎么定义我们的keepalive，所以他不好提供通用的实现什么的，所以我们自己要去实现keepalive.

作者回复: 一般就特别简单的数据。比如ping pong字符这种都可以，原则就是简单数据量小。对端一般都要处理下，但比如只想服务器看看有没有请求过来，不考虑客户端，那也可以不处理，但是作为完整性，最好还是要处理的，这样所有消息定义都是一来一回清晰

作者回复: 但是原文前面是no data.意思没有读，也没有写，用你说的表达肯定也行，就要换句表达了，二个本质都是一个意思，类似 双重否定等于肯定