RPC超时重传机制浅析

SUN RPC是对socket的封装，其底层适用TCP或是UDP协议来传输数据，本文讨论SUN RPC使用的超时和重传策略。

 

1.       总超时值：一个客户端等待其服务器的应答的总时间量。TCP和UDP都是用该值；

2.       重试超时：只用于UDP, 是一个客户等待其服务器的应答期间每次重传请求的间隔时间；

 

注：因TCP是可靠的面向连接的协议，有自己的一套机制来保证端到端的传输可靠性，故使用TCP建立的应用不需要考虑超时重传等问题。

 

默认的超时时间可以通过clnt_control函数获取，

clnt = clnt_create (host, square_prog, square_vers, "udp");

 

struct timeval tv;

 

clnt_control(clnt, CLGET_TIMEOUT, (char *)&tv);

printf("timeout = %d : timout = %d\n", tv.tv_sec, tv.tv_usec);

 

clnt_control(clnt, CLGET_RETRY_TIMEOUT, (char *)&tv);

printf("timeout = %d : timeout = %d\n", tv.tv_sec, tv.tv_usec);

 

其中，UDP的默认总超时值为-1，重传超时值为5s（unp书上说是15s）;

      TCP的默认总超时值为0（unp书上说是30s）；

      跟书上不同的地方应该是由于RPC的版本不同吧。

 

为了对这些数据进行验证，以square程序为例，通过改变clnt_call传递的TIMEOUT值及服务器端处理请求前的睡眠时间值，我做了几个实验：（超时值还可以通过clnt_control来指定，此时rpc_call忽略参数timeout）

 

1.       TIMEOUT = {2，0}，服务器端睡眠10s，使用tcp协议；

现象：客户端2s后提示call failed: rpc: time out，服务器接收到一次请求。

   分析： 与期望相吻合，应用请求超过总的超时值时返回。

  

2.       TIMEOUT = {2, 0}, 服务器端睡眠10s，使用udp协议；

现象：客户端5s后提示call failed: rpc: time out，服务器接收到一次请求。

分析：不明白，不是2s就提示超时么。

 

于是，我猜测是不是使用udp时，总的超时值不能小于重传时间呢? 

做如下试验：通过clnt_control将UDP的重试时间改成10s，TIMEOUT值不变，仍为2s。

现象：客户端10s后提示call failed: rpc: time out，服务器接收到一次请求。 

分析：我的猜测可能是正确的，RPC在实现时将总的超时值设为重传值和TIMEOUT中的较大值，不过这仅仅是猜测，没有看过SUN RPC实现的代码，不敢往下断言。

  

3.       TIMEOUT = {25, 0}, 服务器睡眠10s，使用tcp协议；

现象：客户端10s后收到应答，服务器收到一次请求。

分析：与期望相符合，整个请求没有超出总的超时值。

 

4.       TIMEOUT = {25, 0}, 服务器睡眠10s，使用udp协议；

现象：客户端在快到11s时收到一个回复，而服务器收到三次请求。

分析：

l  0s时，客户端启动后发送请求，服务器端接受该请求，处理时睡眠10s；

l   5s时，客户端重发请求，服务器端接受该请求，等待第一个请求处理完后。      

l  10s时，客户端再次发送请求，服务器端接受该请求，等待前两次请求处理完.

不到1s后，客户端收到回复，这是服务器对第一个请求的应答，程序结束。

l  20s后，服务器端处理完第二个请求；

l  20s后，服务器端处理完第三个请求；

       

服务器睡眠10s就返回结果，为什么客户端会发出第三次请求？

 

因为网络延时，服务器从收到第一个请求，到睡眠10s，处理数据，返回结果时已经是10s之后的事情了，而客户端在10s时就发送了第三次请求，并马上收到了服务器对第一次请求的应答数据。

     

以上是我对SUN RPC超时和重传机制的一点理解，望不吝赐教！