2020-01-07老师，你好！我在dubug的时候，发现服务端断点还停留在处理新连接接入；客户端addListener(future -> {
if (future.isSuccess()) {
System.out.println("连接成功!");
} else {
System.err.println("连接失败，开始重连");
}
});这个时候客户端已经打印出”连接成功了”展开作者回复: 这个问题很好，说明你看的很细致还动手实践了。这里涉及到一些细节了：
首先连接（说白了，就是TCP的三次握手）在服务器端写完下面这句话的时候：
ServerSocket serverSocket = new ServerSocket(8091);（注意这里没有accept）
就已经可以连接上去了，而不是必须有accept（）的执行，那accept是做什么的？
相当于快递的签入。如果你不签入，这个快递还是已经到了（连接已经建立好了），但是你无法对他进行后续处理（最起码，在服务器端你拿不到对应的socket channel来执行调用，更不用谈注册读写事件）。另外一个方面，如果你不accept，那中间的缓存区会满（取决于backlog大小），那很快，就无法建立新的连接了，和快递签入一个道理。你不签入，那快递都堆那个地方，最终还是存不下。
所以总结起来就是，accept准确的说应该说是对连接的后续处理（签入），（但是经常在表述上包括本课程都是直接说处理连接，所以可能会让你误解，以为只有accept调用，连接才能建），至于连接本身（TCP）三次握手并不是accept这个方法做的事情。
你可以写一些简单的例子验证下。很简单，几行代码，抛开netty来看，其实更容易把这些问题搞清楚，如果还有别的疑惑，欢迎继续提问，我应该说清楚这个问题了，哈哈
谢谢！
2019-12-20老师，你这还不是开头说的第一种发送响应模式吗，客户端还是不能异步发送啊，future get的时候还是会阻色啊作者回复: future本身就代表是异步的，而get是为了获取结果，相当于异步执行但是结果获取是阻塞同步，这两个不矛盾。
改进的核心点在于：第一个请求和第二个请求可以异步并发了，原来的不行，因为如果并发，无法把结果一一对应起来。
2019-12-11老师，在ClientV1版本中我们将new RequestMessage的工作抽出去到Encoder里去实现了，但是在ClientV2版本中为了添加RequestPendingCenter我们又不得不每次都new RequestMessage，这里有没有什么办法将RequestPendingCenter#add的工作也放到Encoder里去？作者回复: 不适合，因为那是encoder，从encoder里获取结果？另外，你怎么来获取响应结果？所以不适合。
2019-11-15说点题外话，kafka client 发送请求给 broker，如果 client 没有收到对应的响应，会 pending，新的请求发不出去，但 kafka 吞吐还是很大的作者回复: 但是如果他的信息传输结构定义成带关键id的，能做到的更好，就像http为什么要搞新版本一样的道理，当然原来的旧版本，现在一直在用，因为能满足需求，不够就加机器。