Address in use::::WIN32 error 10048 svrSocket errMessage = WIN32 error 10055

 Address in use::::WIN32 error 10048  通常每个套接字地址(协议/网络地址/端口)只允许使用一次。


WIN32 error 10055   由于系统缓冲区空间不足或列队已满，不能执行套接字上的操作。 




(转)
TIME_WAIT状态
根据TCP协议定义的4次握手断开连接规定,发起socket主动关闭的一方socket将进入TIME_WAIT状态,TIME_WAIT状态将持续2个MSL(Max Segment Lifetime),在Windows下默认为4分钟,即240秒,TIME_WAIT状态下的socket不能被回收使用. 具体现象是对于一个处理大量短连接的服务器,如果是由服务器主动关闭客户端的连接,将导致服务器端存在大量的处于TIME_WAIT状态的socket,甚至比处于Established状态下的socket多的多,严重影响服务器的处理能力,甚至耗尽可用的socket,停止服务. TIME_WAIT是TCP协议用以保证被重新分配的socket不会受到之前残留的延迟重发报文影响的机制,是必要的逻辑保证.
可以用如下代码尝试关闭TIME_WAIT,但这样作是很危险的,违背TCP协议的,也不一定有效果.
linger InternalLinger = { 1, 0 };
::setsockopt(socket, SOL_SOCKET, SO_LINGER, (const char*)&InternalLinger, sizeof(linger));


中庸的做法是,可在HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters,添加名为TcpTimedWaitDelay的
DWORD键,设置为30-240,以缩短TIME_WAIT的等待时间,这也是对IIS服务器的优化手段之一.编程上,除非必要,应尽量让客户端发起断开操作. 








进入了TIME_WAIT状态。用SO_REUSEADDR选项。


呵呵,   fierygnu(va_list)   的方法就可以了,我以前不知道的 
时候,还给BIND()自己写了一个bind()失败的话,sleep(5000) 
再bind()一次,呵呵,好搞笑


int   optval   =   1; 


setsockopt(SOCKET s,int level, int optName,const char* optval, int optlen);


setsockopt(sd,   SOL_SOCKET,   SO_REUSEADDR,   &optval,   sizeof(optval));


svr.Socket.SetOption(int option,int value,int level = Sol_socket);








在程序关闭或异常退出后你要做收尾工作， 
1.shutdown() 
2.close() 
3.sock   =   0; 
这样就没有问题了（异常推出要捕捉系统信号）


SO_REUSEADDR 
选项有关



描述:


Windows 无法访问文件 C:"WINDOWS"system32"winhttp.dll，可能是下列原因之一: 网络连接，存储文件的磁盘或此计算机上 安装的存储驱动器有故障；或找不到磁盘。 由于该错误，Windows 关闭了程序 Windows HTTP Services。


     


除开这些操作系统记录的错误日志，程序也有运行错误提示，主要有如下：


一：Read Error 64 指定的网络名不再可用。


二：Write Error 1450 系统资源不足，无法完成请求的服务


三：out of memory


四：由于系统缓冲区空间不足或队列已满，不能执行套接字上操作


 


二：错误解决


NOD32软件：排除主要通过卸载后测试


在BAIDU资料时，发现了有可能会因为杀毒软件在排查病毒的时候，引发操作系统崩溃，但随后的卸载测试排除了这种可能。


    内存泄露：排除，主要通过测试观察。


由于系统进程比较多，模拟终端数量超过了100，初步怀疑是系统内存泄露。但经过一次测试确认，程序没有发生内存泄露。在超过10个小时的运行中，并没有发现非常明显的内存增加现象，但错误依然出现。


操作系统：主要通过多次测试，观察错误出现的时机。


由于系统本机的TCP通讯非常频繁，怀疑是由于操作系统压力过大导致。通过几次测试，发现系统错误出现的时机总在运行超过一定的时间，虽然不是非常精确，但如果是压力过大，系统出现宕机的情况应当是随机的，不会出现10多个小时运行每次都不出现问题。由此排除操作系统压力原因！


线程操作异常：主要通过多次测试观察，检查运行中程序的线程数量是否稳定，以及日志异常记录文件辅助。


在多次测试中，有测试观察记录，里面包含了程序线程的数量与异常日志的查看，并没有发现有线程日志，以及在运行中，线程数量变化异常的情况。由此排除不当的线程操作导致程序异常，进而引发操作系统异常。


句柄资源耗尽：通过观察程序运行时的句柄数量确认模拟终端有句柄资源没有释放的现象。


句柄资源与内存泄露本来是有些关联的，但这次测试中，并没有出现内存泄露的问题。


“Write Error 1450 系统资源不足，无法完成请求的服务”，这个错误的排查过程中，在BAIDU资料时，发现有可能是和操作系统的句柄资源有关。通过测试观察，模拟终端程序，在运行时，的确会不断增加句柄数量，但内存没有增长。由此确定，模拟终端的代码有问题，经过检查，的确发现了一个资源：“pstream : TWinSocketStream“；这个网络通讯变量没有释放，使用Try fillaly的结构释放后，解决了句柄释放问题。通过连续超过48个小时的测试，


以及结果观察，到今天早上，通讯量已经超过1000万，基本解决了中间件程序测试的问题。


 


Windows操作系统的句柄按照理论来是，应该是个非常庞大的数量，但WINDOWS下面就象一个黑盒，只有经过实际检验才能得出真理。