第10讲 提高数据报套接字编程的可靠性.pptVIP

* 具体来说，UDP协议的不可靠性问题主要体现在以下几个方面： 问题1：这是使用UDP协议通信的客户与服务器进程，当客户发送请求报文后，就会等待服务器的应答；当客户进程收到一个应答时，就会将其存放到套接字的接收缓冲区中；此时，如果刚好有其他进程给该客户的这个端口发送了一个数据报，则客户的套接字会误以为是服务器的应答，因此也会将其存放到这个接收缓冲区中；所以在客户的接收缓冲区中也可能会出现噪音数据；此时客户端应该如何分辨哪些是噪音数据，哪些是非噪音数据呢？ 问题2：当客户发送完服务请求数据报后就等待服务器的应答，服务器发回的应答报文中途可能会丢失，此时客户端该如何处理？同理，客户发送的请求报文也可能丢失，但它自己也不知道，此时客户该如何处理？ 问题3：由于通信前没有事先建立连接，就可能导致出现这样的现象，当客户向服务器发送数据报时，这个服务器还没有启动，因此根本无法收到服务器的应答；为了避免这种情况的发生，客户端该如何处理？ 我们在编写数据报套接字的应用程序时，如果想要保证一定的可靠性，则必须考虑的这几个问题该如何解决。 * 客户端之所以会收到噪音数据的根本原因是，由于通信前没有建立连接，任何非服务器进程都可以向客户的套接字发送数据报； 在前面曾分析过，客户接收服务器的响应时，调用recvfrom函数来接收应答；其中的第5个和第6个参数设置为空指针，这样就无法判断接收到的数据报的源地址； 因此要排除噪音数据，可以增加对应答数据报的源地址的判断功能； 具体方法是： 在recvfrom函数接收应答报文时，利用第5和第6g参数记录应答数据报的源地址； 然后将这个地址与发送函数sendto中的目的地址进行比较，如果二者相同说明这个应答数据报来自服务器；否则，说明这个应答报文是噪音数据，将其丢弃即可； * 对于第二个问题，服务器的应答报文丢失了该如何处理？ 由于UDP协议是一个无连接的、不可靠的协议，当客户发送的请求报文丢失，或者服务器发回的应答报文丢失时，客户和服务器并不知道，客户进程的接收函数recvfrom会一直处于等待状态； 要想让recvfrom函数不至于无限期地等待下去，可以对接收函数recvfrom设置一个超时判断； 具体方法：通过setsockopt函数来对套接字进行相应的设置； 在创建一个套接字后，先调用setsockopt函数，为该套接字设置一个接收超时，设置接收超时的选项是SO_RCV TIMEO，所设置的超时时限是nTimeOver，定义为1000毫秒； 注意：利用setsockopt函数还可以对套接字的其他选项进行设置，该函数在编写网络程序时非常有用； * 这样改进后，客户端就不会一直盲目地接收了，当接收超时时限到了，即使没有接收到应答，recvfrom函数也会返回的； 但这样并不能判断出客户接收超时的真正原因：是由于客户的请求报文丢失，服务器根本就没有作出应答；还是由于服务器收到请求报文后，所发回的应答报文丢失； 而这两种报文的丢失在有些应用中所造成的影响是完全不同的： 例如在银行系统中的一个常见情况，客户A向银行的服务器B发送一个请求报文，希望将1万美金转到A的帐户上；如果这个请求报文丢失了不会对客户和银行造成任何损失；但如果服务器B在收到这个请求报文后，并且处理了这个请求，将1万美金转到了A的帐户上，当它向客户A发回应答报文时丢失了，则这样就会带来严重的问题，客户A可以否认自己没有收到1万美金，而服务器却已将1万美金转到A的帐户上了； 对于这样的问题，可以通过带确认的数据报服务来解决。 即在客户收到服务器的应答报文后，必须向服务器发送一个确认报文，以告知服务器，客户收到了服务器的应答报文；这样就可以解决刚才的问题，如果服务器B发回应答后，在一定的时间内没有收到客户A的确认报文，则服务器B会向客户重发应答报文； 1、序列号：客户为每个请求附加一个序列号，服务器必须在返送给客户的应答中回射这个序列号，这样客户就可以验证某个给定的应答是否匹配早先发出的请求。 2、超时和重传：处理超时重传的老式方法是 先发送一个请求并等待N秒钟，如果期间没有收到应答，那就重新发送同一个请求并再等待N秒钟，如果发生一定次数后放弃发送。这是线性重传的一个例子，这个方法的问题在于数据报在网络上往返时间可以从局域网的远不到1秒变化到广域网的好几秒。往返时间（RTT）的影响因素包括距离网络速度和拥塞。另外客户和服务器之间的RTT会因网络条件的变化而随着时间迅速变化，在设计超时和重传算法时 必须要把实测到的RTT及其随时间变化的现象考虑在内。这在实际设计时需要考虑客户服务器的时钟同步、RTT值的动态更新等问题。 一个更精妙的解决办法来自TCP用于应对“长胖管道（或有较高带宽或有较长RTT亦或两者都有的网络）的扩展。本办法出了为每个