继续上一章的内容，客户端请求是一个流对象，服务端响应一个集合
客服端流式请求，服务端响应一个集合：
具体方法分析：
onNext()：这里面和之前的方法有点不同，在之前onNext()是用来返回给客户端响应的数据，而在现在是客户端发送流式请求之后，onNext()方法是接收客户端发送过来的流式请求；每接收一个数据，它就会被调用一次。
onError()：返回错误信息；
onCompleted()：这个和之前不同，在之前两个信息传递的时候，该方法只是一个起到通知的作用，而在这里它是返回给客户端响应数据的方法。
客户端相比服务端，其编写难度更大。
客户端接收服务端的响应：
我们仔细看一下，我们想获取getStudentWrapper()方法对象，发现根本就没有。
因为客户端向服务端发送请求，在这里你会发现我们无法使用blockingStub的获取相关方法，因为我们客户端发送流式请求的时候，gRPC不支持使用同步方式获得对象，要求使用异步获取相应对象
在gRPC中存在一个方法，使用异步的方式来发送流式请求
现在你在写的时候，发现异步的stub竟然三种方式都可以；
总结来讲就是，客户端不管是不是以流式的方式发送请求，都可以采用异步来获取对象；
但是如果是流式的方式发送请求，都只能用异步来获取对象。
发送请求信息；
这里和之前又有点不同，之前请求信息发送完之后，就没有然后了。而异步不同， 你不行调用onCompleted()方法通知。
注释掉之前那个打印调用：
启动服务器（服务器使用的是上一章提到的）：
启动客户端（发现没有结果）：
原因主要是因为异步的原因：
数据还没来的急发送出去，就已经执行了Oncompleted()方法；
我们让程序休眠一段时间
启动服务器
启动客户端
还有最后一种形式：两端都是以流式方法发送请求和响应
定义两个流式请求参数
编译器生成代码
拷贝代码：
gRPC服务代码：
服务端代码编写：
客户端代码编写：
注释掉之前的代码
打印服务端发送过来的信息
客户端向服务端发送流式请求：
运行之后
到现在为止gRPC的四种方式以及基本上写完了，对于gRPC也基本上学完了，大家注意是要理解它的四种方法以及使用场景，然后跟thrift进行对比。
