。。。。。。。。。。 (100分)

  • 主题发起人 主题发起人 陈一蛟
  • 开始时间 开始时间

陈一蛟

Unregistered / Unconfirmed
GUEST, unregistred user!
。。。。。。。。。。。。。。。。。。。。。。。
 
。。。。。。。。。。。
 
对于不熟悉写线程的人来说,阻塞的还是比非阻塞的好用。
 
>>对于不熟悉写线程的人来说,阻塞的还是比非阻塞的好用。

不熟悉线程,还用阻塞?

另外,客户端当然还是用非阻塞比较好了,服务器端最好用阻塞方式。 我用TClientSocket
和Indy做过测试。
 
同意 阿西喊佛。
 
哦,失误,说错了:)
不过我还是个人认为,时间不是个大的问题,主要是看你的方法和你传送的文件大小还有就是网络
的质量。
流传输比文件在效率上传要强,但流却比文件难操作。
我只是打比方,鱼和熊掌不可兼得,要做什么,要实现什么还是要看你自己的目的如何:)

说错之处还请斧正:)
 
。。。。。。。。。。。
 
如果你线程做的好,可以把socket做的很出色,关键问题就是线程该如何做的做优化的问题

我也在做一个东西,短期内要交货,所以我只有选择非阻塞。
 
。。。。。。。。。。。。。。
 
那大哥,我们还讨论什么:)

我觉得我们想的是同一件事:)

不过既然有阻塞,就一定有阻塞的好处。在劣质网络时,就明显可以体现出阻塞的优点出来。
所以我还是那句话,你要考虑你的目的,然后选择你的路……
 
本来就是这样,非组塞模式速度快的多,就是逻辑处理复杂,如果加上
重叠I/O,不用该死的消息模式就更是不得了了~~~~
 
。。。。。。。。。。。。
 
个人认为: 阻塞和非阻塞性能是一致的
原因主要如下:
众所周知CPU和外设通讯,一般都是CPU的速度高于外设响应速度,因此才会出现中断技术
故当应用程序提出一个传递数据的请求,操作系统可以有两种方式供选择:
a. 直到操作系统将要求的数据传送完毕,才返回应用程序
b. 直接返回应用程序,当操作系统将数据传送完毕后通知应用程序传输完成

针对第一种情况,操作系统不可能设计得什么都不做专门等着传送数据,而是将所
有数据准备成一个个队列,传送给驱动程序,挂起应用程序,等待数据传输完毕,
而在驱动程序这个级别是采用中断方式传送数据(也就是说操作系统还能完成其他任务)
,如果数据传送完毕后,通知操作系统,操作系统此时返回应用程序,这就是第一种
(也就是阻塞方式传输)。

第二种情况下:操作系统仅将传来的数据拷贝一份,然后传递给驱动程序后就返回
应用程序,因此在应用程序中定位传送完成的条件就显得有点困难,但用阻塞方式和
线程相结合就很完美了。

操作系统实现线程的方法是时分复用,也就是说某种CPU要想实现多道程序共同运行
硬件电路必须提供一个固定频率的时钟脉冲,这个时钟脉冲起到定时唤醒操作系统的目
的,唤醒后的操作系统决定下一步进行什么样的操作(是挂起一个程序,运行另外的程
序,还是....)

 
从网上Copy来的 :)

非阻塞技术即通过非阻塞I/O实现在单进程空间内对多个客户端的并发请求分时处理。
比多线程、多进程技术有更好的并发性和性能,多线程、多进程技术由于每个进程需要复制多个进程空间,
因此需要更大的系统开销。由于非阻塞技术在单进程空间处理,可以更好的现实访问控制。由于是单进程实现,
可以不受操作系统(OS)对进程总数的限制,可以单机实现数千个并发连结。
由于非阻塞技术实现非常复杂,难度很高,所以只有少数著名的大型服务系统(例如IRC服务器、IGS等)可以实现。
 
。。。。。。。。。。。。
 
当然是非阻塞模式要远远好于阻塞模式!非阻塞模式和线程的结合才是最完美的!!UNIX
装神秘呢!微软的能力可是有目共睹的,相信微软,没错的!!!
UNIX也在一些应用中开始使用非阻塞模式了!
 
TTCPBlockSocket 2.804
TWSocket 0.401
TClientSocket 0.401

差异不可能这么大吧,楼主要好好验证一下,不要这么快下结论
 
在windows9x,nt、2000、XP下异步要比组塞快很多,这是MS都承认的
在MS的一本网络编程书里,实验过多用户下的并发连接发送数据,
结果组塞最多到了1008个连接就挂了,而完成端口到了,49998个连接
事实如此,空想是没用的!
 
其实非组塞就是处理逻辑有点麻烦,不过如果你用重叠以后就又不一样了,和
组塞的运行规则是一样的,但是效率比组塞要高不少。
 
后退
顶部