由于socket是以数据流的形式发送数据,接收方不知道对方一次性发送了多少数据,也能保证对方一次性发送的数据能在同一刻接收到,所以Receive方法是这么工作的:
接受一个byye[]类型的参数作为缓冲区,在经过一定的时间后把接收到的数据填充到这个缓冲区里面,并且返回实际接收到数据的长度,这个实际接收到的数据长度有可能为0(没有接收到数据)、大于0小于缓冲区的长度(接收到数据,但是没有我们预期的多)、等于缓冲区的长度(说明接收到的数据大于等于我们预期的长度)。
每次接收缓冲区都用同一个byte[] byteMessage,并且你没有检查接收到的数据长度,所以第一次你接收到的数据是123456,第二次你只接收到了8,但是缓冲区里面还有23456,所以加起来就是823456了。
socket接收缓冲区的大小有讲究,设置大了接收起来慢,因为它要等尽可能多的数据接收到了再返回;设置小了需要重复多次调用接收方法才能把数据接收完,socket有个属性,标识了系统默认的接收缓冲区大小,可以参考这个!
还有就是用recv读取,但是由于不知道缓存里有多少数据,如果是阻塞模式,到最后必然等到超时才知道数据已经读取完毕,这是个问题。
另一个是用fgetc,通过返回判断是否是feof:
whlie (1) { a=fgetc(f);if (feof(f)) break;//…
b=fgetc(f);if (feof(f)) break;//…}当然,我不知道读取完毕后最后一次调用fgetc会不会堵塞,需要测试。
在非阻塞模式下,我们用recv就可以轻松搞定了,但是阻塞模式下,由于我们不知道缓冲区有多少数据,不能直接调用recv尝试清除。
使用一个小小的技巧,利用select函数,我们可以轻松搞定这个问题:
select函数用于监视一个文件描述符集合,如果集合中的描述符没有变化,则一直阻塞在这里,直到超时时间到达;在超时时间内,一旦某个描述符触发了你所关心的事件,select立即返回,通过检索文件描述符集合处理相应事件;select函数出错则返回小于零的值,如果有事件触发,则返回触发事件的描述符个数;如果超时,返回0,即没有数据可读。
重点在于:我们可以用select的超时特性,将超时时间设置为0,通过检测select的返回值,就可以判断缓冲是否被清空。通过这个技巧,使一个阻塞的socket成了‘非阻塞’socket.
现在就可以得出解决方案了:使用select函数来监视要清空的socket描述符,并把超时时间设置为0,每次读取一个字节然后丢弃(或者按照业务需要进行处理,随你便了),一旦select返回0,说明缓冲区没数据了(“超时”了)。
NodeJs的优势:现在的很多的服务器端的语言(PHP,JAVA,ASP.net),有什么问题呢,现在的服务器端的语言在用户访问服务器时,为每个用户链接创建了一个线程,但每个线程大约要耗费2M的内存,如果一个8G内存的服务器,也就能链接4000个左右的用户,如果用户的链接数较大,就必须增加服务器的数量,而且现在用户的链接方式有很多(如app,网页同时访问),这就又涉及到服务器共享的问题,所以服务器怎么支持最大的同时链接用户量就成了一个问题;
NodeJS修改了客户端到服务器端的链接方法,解决了这个问题,他不在为每个客户端创建一个新的线程,而是为每个客户端链接出发一个NodeJs内部进行处理的事件,所以NodeJS具备同时处理多达几万个用户的客户端链接的能力;
NodeJS适合开发的应用程序:
当应用程序需要处理大量并发的输入/输出,而在向客户端发出响应之前,应用程序内部并不需要进行非常复杂的处理的时候,我们应该考虑使用NodeJs来进行应用程序的开发,例如:
1、聊天服务器:如果聊天的人很多,用户的与服务器之间的并发链接量很大,但是服务器端的数据处理并不复杂;
2、综合类服务网站和电子商务网站的服务器:在这类网站中的服务器端,往往可能每秒存内可以接受多达上千条的数据并且需要将这些数据写入数据库中,NodeJs可以通过其队列机制将这些数据迅速写入缓存区中,然后再通过每一个单独的处理从缓存区中取出这些数据并将其写入数据库中,如果是其他的服务器(如Apache服务器或Tomcat服务器)的话,由于这些服务器采用的是阻塞型I/O机制,因此每条数据写入到数据库中都要等待一段时间(等上一条写完,才能写下一条),但是NodeJs使用的是非阻塞的I/O机制,因此可以实现这些数据到数据库中的写入,而不必再为每条数据的写入而等待一段时间;
总结:
一个规模稍微大点的系统都不是一种开发语言可以搞定的,往往是几种混杂一起,比如c、c++做服务器端开发,java做业务逻辑,php等做前端展示,此外还需要消息中间件等等。
nodejs可以很快地在服务器端做原型(原来只有c系和java等能做的事情,性能还很高),而且代码量相对会少很多;另一点是它的语法优势,js闭包等。但它不太适合做cpu密集型处理的工作,只能绕着弯去解决,据说这次QCon会有人分享这方面的研究成果,可以关注下。
每种语言都有它适合的领域,没必要强求一门语言可以解决所有事情,拥有其它语言的特性,只有不断的tradeoff把系统做出来才是目标。这些都是丛书上看到总结的,还望指正
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)