阻塞和非阻塞的困惑 (100分)

  • 主题发起人 主题发起人 jarm
  • 开始时间 开始时间
J

jarm

Unregistered / Unconfirmed
GUEST, unregistred user!
我在编一个程序,采用三层结构,客户端发socket请求到应用服务器端,服务器接收后
对数据库进行处理,然后通过socket返回结果。这时的客户端TClientSocket应采用阻塞型
还是非阻塞型(客户端不能用多线程)。
使用非阻塞型是在请求包发送后且结果还没返回时可以处理其他事情,跟平常程序访问
数据库时不同。
 
怎么没人回答我啊?
 
为什么不用MIDAS组件?
 
可以采用非阻塞方式,等到返回结果,就处理事件!服务器端必须采用阻塞,多线程!
 
to dcsdcs
如果在结果还没有返回的时候呢,用户是不是可以进行其他操作,譬如新开一个子窗体
 
尽量非阻塞方式
 
我的想法是这样:采用阻塞型,就是在一个事件中实现代码,譬如是一个查询按钮,
点击后发送socket包,然后程序等待,直到有结果返回时才进行下一步操作。
这样就和一般的程序访问数据库一样了,要有了结果才能进行其他操作。
不知各位大侠有什么好的想法
 
采用阻塞型,如果你的数据不是马上可以返回的话,程序就好象死了一样,没有响应。
在第一次连接的时候效果特别明显!
 
to honestman:
一般的程序访问数据库也一样,第一次连接也会比较长时间。而且
我的应用服务器一开始已和数据库连接,客户端访问时不用考虑
与数据库的连接时间
 
我正在做类似的程序
Server:阻塞
Client:非阻塞
 
客户端TClientSocket应采用非阻塞型。
原因很简单:数据发出后丢掉了,这是你的客户端TClientSocket应采用阻塞型,你的
客户端程序起步“死了”——永远的等待不会返回的返回。

为什么不能用多进程能?!
 
to ChinaYA:
我可以在客户端设置超时啊,在一定时间内不返回就作异常处理。
我担心的是如果用非阻塞型,用户发送请求包后,还没等返回结果就把子窗体关了,
当返回结果时触发了接收事件,原来的子窗体又被关掉了,这时该怎么办
 
1.客户端应该使用非阻塞模式(异步模式),关于用户的其他动作比如关闭窗口等,通过
设置状态来处理,比如你不希望用户在等待数据时关闭窗口,则判断socket是否在等待数据
状态,或者在关闭窗体是对Socket进行Abort处理。
2.从提高效率的角度来说,服务器端最好采用“覆盖选择模型”或“事件模型”,但这样的
化delphime没有提高相应的控件,采用“消息模型”的话当然应该采用非阻塞模式,尽管处
理起来比较复杂,但效率比较高,占用的资源比较少
3.不管是客户端还是服务器端,采用阻塞模式时,其必须等待,等待的处理不管采用哪一种
方法,都大量占用CPU时间,对于服务器端来说,这是最要命的。
 
听君一言,茅塞顿开。
谢谢各位的参与
 
后退
顶部