增加Server Timeout支持，以避免不必要的response造成带宽占用 about sofa-pbrpc HOT 5 CLOSED

这个issue解决了不必要的response，是否能再加个功能，避免不必要的request，即：
用户的service可能是同步实现，因为过载而导致堵塞。server端收到request后，要排队调用用户的service，在真正调用用户service前，请求可能已经超时，这时候继续调用用户的service，产生response，再丢弃，其实也是很浪费的。

from sofa-pbrpc.

GREAT WORK!

from sofa-pbrpc.

@bluebore ，我明白你的意思，我要说几点：

• server端其实是没有队列的，我们的server端线程模型是work线程既负责处理网络IO也负责处理服务，因此是没有显式的等待队列的；如果有work线程空闲，它就会从socket中读取request数据（通过epoll的方式），然后立即处理它；
• 但并不是说server端request就不会等待，实际上，work线程从socket中有可能一次性读取到多个request，这取决于epoll一次返回多少数据，有可能多个request合并成一个数据块返回。如果一次获取了多个request，目前做发是逐个串行执行，参见RpcServerMessageStream::on_read_some()函数：

... ...
        // process messages
        while (!is_closed() && !received_messages.empty())
        {
            on_received(received_messages.front());
            received_messages.pop_front();
        }
... ...

• 因此从work线程读取到request到真正开始执行request之间确实是可能有一段时间延迟的，这个延迟就是在其之前执行的同一批request的执行时间之和。
• 目前RpcControllerImpl中针对server端记录了这三个时间点：_request_received_time、_start_process_time、_finish_process_time。通过计算 server_wait_time = _start_process_time - _request_received_time 可以得到在server端的等待时间。如果server_wait_time >= server_timeout，那么就可以放弃执行了。
• 另外在client端，从开始计时到开始发送之间也可能在pending buffer中排队，这段时间记为client_wait_time，那么client传递给server的server_timeout实际上要减去这段时间才更准确，即server_timeout = client_timeout - client_wait_time。现在没有减去client_wait_time，是因为server_timeout是存放在RpcMeta中，而RpcMeta在放入pending buffer之前就需要序列化到buffer中，在后面发送时很难修改。除非我们的序列化操作推迟到发送时再做。

from sofa-pbrpc.

赞这个主题！
可以考虑把用户最初掉用rpc的start_time和time_out附带上，在真正发送rpc时判断一下超时；
对端收到请求时记录一下receive_time，处理过程中或者response时都可判断一下是否已经超时

from sofa-pbrpc.

参见#86 ，目前已经考虑了server_wait_time，现在就差client_wait_time需要考虑了

from sofa-pbrpc.