Nodejs的WebSocket模块怎么设置连接超时时间

在建立socket连接时可以很容易设置socket通信的发送和接收超时时间，但是在建立socket通信时，如果是Win98系统，则如果连接失败，则程序会一直等待在哪里，Windows2000默认超时时间是30秒，当然，这个超时时间不算长，但是加入我们要循环扫描一系列端口并且建立连接的话，总的等待时间就会让人忍受不了，下面就以delphi为例进行说明，如何在建立socket的时候设置其超时时间：

//连接，发送和接收时间都设为2秒

SctTimeOut := 2000

//设置接收数据通信超时

setsockopt(hSock,SOL_SOCKET,SO_RCVTIMEO,@SctTimeOut,SizeOf(Integer))

//设置发送数据通信超时

setsockopt(hSock,SOL_SOCKET,SO_SNDTIMEO,@SctTimeOut,SizeOf(Integer))

//首先，设置通讯为非阻塞模式

dwArg := 1

RecvLen := ioctlsocket(hSock,FIONBIO,dwArg)

//其次，连接服务器

ZeroMemory(@addr, sizeof(addr))

addr.sin_family := AF_INET

addr.sin_addr.S_addr := inet_addr(pchar(SvrIP))

addr.sin_port := htons(Strtoint(SvrPort))

RecvLen := 0

RecvLen := connect(hSock, addr, sizeof(addr))

//再次，设置连接超时时间为2秒

tmOut.tv_sec := 2

tmOut.tv_usec := 0

FD_ZERO(recvSet)

FD_SET(hSock, recvSet)

RecvLen := select(0, @recvSet, @recvSet, nil, @tmOut)

//连接失败，报错误信息

if (RecvLen = 0) or (RecvLen = SOCKET_ERROR) then

begin

ErrMsg := '连接服务器失败！'

exit

end

//最后，设置通讯为阻塞模式

dwArg := 0

RecvLen := ioctlsocket(hSock,FIONBIO,dwArg)

//end modify

1.后台统计方法执行时间，显示为秒级别longstartTime=System.currentTimeMillis()//执行方法longendTime=System.currentTimeMillis()floatexcTime=(float)(endTime-startTime)/1000System.out.println("执行时间："+excTime+"s")2.前台统计时间，显示为秒级别varst=newDate()//执行方法varet=newDate()varexecTime=(et-st)/1000varet=document.getElementById("time")et.innerHTML="执行时间："+execTime+"s"不过从Firefox的firebug调试工具统计时间来看，前台统计时间比真实时间短，调试工具统计的时间跟后台统计的时间相近，且稍长，合情理，所以前台统计数据直接从后台取。3.得出查询速度的方法是：在各个select语句前加：declare@ddatetimeset@d=getdate()并在select语句后加：select[语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())

脱离带宽内存与计算量来讨论并发是没有意义的。

因为并发数受带宽及其它很多因素影响，不能单就node.js来说并发多高。

如果无限带宽，无限计算力，无限存……你可以认为node.js并发数也是无限的，但这没有意义，在同样的情况下，就算是IIS，并发数也可以认为是无限的。

node.js的优势严格来说不是并发而是“非阻塞”。

它是通过非阻塞来达到高并发的目标的，我们用node.js也是用它的非阻塞这个特点。

在优化线程池，以及端口复用等技术的基础上，对于简单的业务处，使用其它的模型也可以达到高并发的目标，但在面临业务逻辑耗时长的问题时，node.js的优势就比较明显。

如果一个事务请求涉及三个业务逻辑，比如登录(login)这个事务，假设我们定义它有三个业务逻辑：

verify：验证用户是否合法（用户名，密码什么的）；

user:获取身份信息（权限什么的）；

modules:返回他可用的业务接口列表(商品管理，用户管理，订单审核等）

我们假设：只有1完成了才可以进行2，2完成了才可以进行3，上述每个业务逻辑都需要1秒去完成（客户的登录请求这个事务需要3秒才能完成）。

同时，我们也假设，这三个业务逻辑服务都是在其它的服务器上，它们的并发数无上限。

然后，我们在“一瞬间”我向这个服务发出1000个login请求

那么，我们来看看node.js与纯java的不同。

nodejs调用它们来完成,因为它是非阻塞的，它调了verify后，不再等待它返回结果，就可以处理另一个事务请求了，当verify请求有返回结果时，它再来处理结果，决定是否调用user……，整个过程，只在一个进程中就完成了。

它收到这1000个请求后，在这个进程中向verify发出了1000个请求，过了一秒，收到回应又有900个验证成功，它返回了100个登录失败的信息，并向user发出了900个请求，又过了一秒，返回了900个modules的结果。

这样的结果，在客户端看来，发出请求后1秒，收到了100个登录失败，又过了两秒，收到了900个可用功能列表（因为异步机制，它还会稍微长一点点，假设是3.003秒吧）

现在，在带宽与计算力不受限的情况下，同样的内存，看看纯Java是怎么个情况。如果使用纯java来做这个事，java不使用异步模式的话，一个线程响应一个请求。

java同样“一瞬间”收到了1000个请求，java开启了1000个线程去响应它们,然后这1000个线程在第一秒里都在等待verify，第一秒结束时，返回100个登录失败，关闭了100个线程，又过了两秒，900个线程得到了各自的modules结果，并返回给客户端。

对于客户端来说，感觉就是3秒，没有那个0.003。

好，至此，node.js与纯java的区别已经很明显了。纯java在不使用非阻塞机制的情况下，它需要开启1000个线程（或者进程，这个成本更高）而node.js则需要更多的时间。

在内存受限的情况下，node.js就有优势了。

假设一个进程需要1M内存，为了能同时开1000进程，你需要额外的1G内存来给它。而对于node.js，它可能只需要20M来完成这个事，代价就是每个客户端都需要多等那么一小会。

严格来说，并不提倡在node.js中实现业务逻辑，node.js最好是只用于以非阻塞模式连接多个阻塞模式的业务逻辑。

---