apue和unp的学习之旅07——多种边界条件的讨论

了解一些边界条件，通过观察这些情形，弄清在网络层次发生什么以及它们怎样反映到套接字api，这将很多其它地理解这些层次的工作原理，体会怎样编写应用程序来处理这些情形。

//--------------------------------1.刚连接立即断开----------------------------------

当三TCP路握手完毕从而连接建立之后。客户TCP却发送了RST，在server端看来，就在该连接已由TCP排队，等着server进程调用accept的时候RST到达。

怎样处理这样的中止的连接依赖于不同的实现，源自Berkley的实现全然在内核中处理中止的连接，server进程根本看不到。大多数SVR4实现则返回一个错误给server进程。作为accept的返回结果。

//--------------------------------2.server进程终止----------------------------------

验证一切正常后，找到server子进程的进程id，运行kill杀死子进程id，作为进程终止处理的部分工作，子进程中全部打开着的描写叙述符都被关闭，这就导致向客户发送一个FIN。而客户TCP则响应以一个ACK，这就是TCP连接终止的工作的前半部分。

而客户堵塞在fgets调用上。等待从终端接收一行文本。于是键入另外一行文本，客户TCP接着把数据发送给server。TCP同意这么做。由于客户TCP接收到FIN仅仅是表示server进程已经关闭了连接的server端，从而进程不再往当中发送不论什么数据而已（而非并不是告知客户TCPserver进程已经终止）。

当serverTCP接收到来自客户的数据时，既然先前打开那个套接字的进程已经终止。于是响应一个RST（可通过tcpdump命令验证）。

接着的情况分为2种，得看时序了

1.由于客户在刚刚调用writen后。马上调用readline，而且由于之前TCP接收到的FIN(RST还没到)，所以readline马上返回0。即受到未预期的EOF，于是以出错信息（server terminated prematurely。服务器过早终止）。

2.假设readline发生在收到RST之后，这时候客户既收到了FIN，又收到了RST，则readline返回一个ECONNRESET，即connection rest by peer，对方复位连接的错误。

//--------------------------------------3.SIGPIPE-------------------------------------------

当进程向某个已收到RST的套接字运行写操作时，内核该进程发送一个SIGPIPE信号，该信号的默认行为是终止进程，因此进程必须捕获它以免不情愿地被终止，但不管该进程是捕获该信号并从其信号处理函数返回还是简单忽略该信号，写操作都将返回EPIPE错误。

第一次写操作引发收到RST。第二次引发SIGPIPE信号，写一个已经接收到FIN的套接字不成问题，可是写一个已经接收到RST的套接字则是个错误。

假设SIGPIPE信号出现时须要採取特殊措施，可能须要在日志文件里登记，那么就必须捕获该信号。

//------------------------------------4.server主机崩溃---------------------------------------

当server和client确认正常后，然后从网络上断开server主机。并在客户键入另外一行文本，这样也模拟了当客户发送数据时server主机不可达的情形，即建立连接后某些中间路由器不工作的情形。

客户writen后，随后堵塞于readline的调用，假设用tcpdump观察网络就会发现，客户TCP持续重传数据分节，试图从server上接收一个ACK。

源自Berkley的实现重传该数据分节12次，共等待约9分钟才放弃重传。当客户TCP最后最终放弃时，给客户进程返回一个错误。

既然客户堵塞在readline函数调用上。那么该调用将返回一个错误。假设server追已崩溃，从而对客户的数据分节根本没有响应，那么所返回的错误时是ETIMEDOUT，然后假设某个中间路由器判定server主机已不可达。从而响应一个destination
unreachable的ICMP消息，那么所返回的错误是EHOSTUNREACH或ENETUNREACH。

虽然我们客户终于还是能够发现对端主机已经崩溃或者不可达。只是有时候我们须要比不得不等待9分钟更快地检測出这样的情况。所用的方法就是对readline调用设置一个超时。

//------------------------------------5.server崩溃后重新启动----------------------------------------

如上的情况下，假设在server主机崩溃时客户不主动给server发送数据，那么客户将不会知道服务里主机已经崩溃（没使用KEEP_ALIVE套接字心跳包选项）。

连接建立正常后。server主机崩溃并重新启动，接着在客户上键入一行文本，它将作为一个TCP数据分节发送到server主机。

当server主机崩溃后重新启动时。它的TCP丢失了崩溃前的全部连接信息，因此serverTCP对于所收到的来自客户的数据分节响应以一个RST，当客户TCP收到该RST时，客户正堵塞于readline调用。导致该调用返回ECONNRESET错误。

//----------------------------------6.server主机关机----------------------------------------

当server进程正在执行时，server主机被操作员关机时将会发生什么呢。Unix 系统关机时，init进程通常先给全部进程发送SIGTERM信号（该信号可被捕获），等待一段固定时间（往往是5~20秒之间），然后给全部仍在执行的进程发送SIGKILL信号（该信号不能被捕获）。这么做留给全部执行的进程一小段的时间来清除和终止。假设我们不捕获SIGTERM信号并终止，我们的server将由SIGKILL信号终止。接下来和第2条一样了。