回帖：_onoff域设为非零，参见2.4，4.1.7和4.1.21各节），并设置了零超时间隔，则closesocket()不被阻塞立即执行，不论是否有排队数据未发送或未被确认。这种关闭方式称为“强制”或“失效”关闭，因为套接口的虚电路立即被复位，且丢失了未发送的数据。在远端的recv()调用将以WSAECONNRESET出错。





若设置了SO_LINGER并确定了非零的超时间隔，则closesocket()调用阻塞进程，直到所剩数据发送完毕或超时。这种关闭称为“优雅的”关闭。请注意如果套接口置为非阻塞且SO_LINGER设为非零超时，则closesocket()调用将以WSAEWOULDBLOCK错误返回。





若在一个流类套接口上设置了SO_DONTLINGER（也就是说将linger结构的l_onoff域设为零；参见2.4，4.1.7，4.1.21节），则closesocket()调用立即返回。但是，如果可能，排队的数据将在套接口关闭前发送。请注意，在这种情况下WINDOWS套接口实现将在一段不确定的时间内保留套接口以及其他资源，这对于想用所以套接口的应用程序来说有一定影响。





这是网上的解释


主要是影响close socket时的动作


知道了问题的原因，我们就动手修改一下试试


0012F80C 0096D367 /CALL 到 setsockopt 来自 0096D362


0012F810 00000078 |Socket = 78


0012F814 0000FFFF |Level = SOL_SOCKET


0012F818 00000080 |Option = SO_LINGER


0012F81C 0012F84C |Data = 0012F84C


0012F820 00000004 \DataSize = 4


0012F824 0000FFFF


0012F828 0012F848


0012F82C /0012F850


0012F830 |00965419 返回到 00965419 来自 0096D340


0012F834 |00000080


0012F838 |0012F84C


0012F83C |00000004


0012F840 |0012F864


0012F844 |0012F870


0012F848 |00000078


0012F84C |00010100 //原来的00010001表示延时256秒，将延时改为1秒


F9运行，用客户端连接，连上后再断开，察看服务端连线，发现以前总是显示为TIME_WAIT的连接，现在马上消失了，至此问题解决:)


3、Radmin修改


Radmin的保护措施做的还是很不错的，它的真正的执行程序是一个RES资源，主程序只负责将其解压缩到内存中并执行，如果要修改就需要自己解压缩，修改后再自己压缩了放回去，具体怎么做我就不说了：）


提示：如果要重复我一样步骤，直接下setsocketopt是断不下来的，先下jmp eax ，断下来后F8一次，再下setsoketopt断点，好了，就提示这么多了。