免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
123
最近访问板块 发新帖
楼主: iunknown
打印 上一主题 下一主题

[C] 集成 IOCP 到 Libevent [复制链接]

论坛徽章:
0
21 [报告]
发表于 2008-06-08 11:18 |只看该作者
原帖由 benjiam 于 2008-6-7 23:04 发表
可以吗?  

可以指定一个长度为 0 的 buffer ,这样当 GetQueuedCompletionStatus 返回的时候,
才再次调用 WSASend/WSARecv 真正来发送数据。

那么新送出的数据可以有多长?
wsasend 是同步还是异步完成。 异步完成何时通知呢? 需要第二次GetQueuedCompletionStatus ?


无论是 send ,还是 recv ,都可以用 zero byte buffer 。
当 GetQueuedCompletionStatus 返回的时候,调用 WSASend/WSARecv 来处理数据,这个时候是用 non-blocking 的方式来处理的。
是 non-blocking ,而不是 overlapped 的方式,因此是立即知道结果的,不再需要通过 GetQueuedCompletionStatus 来得到结果。

这个 zero byte buffer 的策略,是结合 non-blocking 来用的。这个 non-blocking 正是 event-driven 的基本要求。

论坛徽章:
0
22 [报告]
发表于 2008-06-08 15:09 |只看该作者
这个时候是用 non-blocking 的方式来处理的。
是 non-blocking ,而不是 overlapped 的方式,因此是立即知道结果的,不再需要通过 GetQueuedCompletionStatus 来得到结果。


??? 好像不对吧。这个时候应该是blocking 方式才能立刻知道结果。
如果是non-block 的话, 应该是立刻返回,而不知道是否真正完成,由后面的事件来通知完成。



如果是send 的话, 我认为 是否block 的问题并不是很多, 而recv 的是否block 才是提高系统响应的关键。

论坛徽章:
0
23 [报告]
发表于 2008-06-08 15:12 |只看该作者
能否画个 过程图

包括epoll 和iocp的。

论坛徽章:
0
24 [报告]
发表于 2008-06-08 18:31 |只看该作者
原帖由 benjiam 于 2008-6-8 15:09 发表
??? 好像不对吧。这个时候应该是blocking 方式才能立刻知道结果。
如果是non-block 的话, 应该是立刻返回,而不知道是否真正完成,由后面的事件来通知完成。



如果是send 的话, 我认为 是否block 的问题并不是很多, 而recv 的是否block 才是提高系统响应的关键。


不知道有没看过 <Network Programming for Microsoft Windows, Second Edition> 这本书?
里面有一段
Maximizing Connections
Maximizing the number of concurrent client connections is the more difficult of the two strategies. Handling the I/O on each connection becomes difficult. A server cannot simply post one or more sends or receives on each connection because the amount of memory (both in terms of locked pages and non-paged pool) is great. In this scenario, the server is interested in handling many connections at the expense of throughput on each connection. An example of this would be an instant messenger server. The server would handle many thousands of connections but would need to send or receive only a small number of bytes at a time.

For this strategy, the server does not necessarily want to post an overlapped receive on each connection because this would involve locking many pages for each of the receive buffers. Instead, the server can post an overlapped zero-byte receive. Once the receive completes, the server would perform a non-blocking receive until WSAEWOUDLBLOCK is returned. This allows the server to immediately receive all buffered data received on that connection. Because this model is geared toward clients that send data intermittently, it minimizes the number of locked pages but still allows processing of data on each connection.


通常用 epoll 的时候,也是用 non-blocking 的方式的吧? non-blocking 是可以立即知道操作结果的,和 blocking 的差别在于当没有数据可读的时候,non-blocking 会返回 -1 ,并设置 errno 为 EWOUDLBLOCK ,blocking 则会阻塞调用者。

[ 本帖最后由 iunknown 于 2008-6-8 21:10 编辑 ]

论坛徽章:
0
25 [报告]
发表于 2008-06-09 08:49 |只看该作者
楼主,最好自己先试试,我从-1到-2都试过了,根本不能编译。
dsw和dsp都是unix格式,vc6不能打开。

论坛徽章:
0
26 [报告]
发表于 2008-06-09 08:54 |只看该作者
--------------------Configuration: event_test - Win32 Debug--------------------
Compiling...
event-test.c
Linking...
libevent.lib(event.obj) : error LNK2001: unresolved external symbol _win32iocpops
libevent.lib(event.obj) : error LNK2001: unresolved external symbol _evutil_gettimeofday
libevent.lib(event.obj) : error LNK2001: unresolved external symbol _evsignal_base
Debug/event_test.exe : fatal error LNK1120: 3 unresolved externals
Error executing link.exe.

event_test.exe - 4 error(s), 5 warning(s)

论坛徽章:
0
27 [报告]
发表于 2008-06-09 09:06 |只看该作者
原帖由 mymmsc 于 2008-6-9 08:49 发表
楼主,最好自己先试试,我从-1到-2都试过了,根本不能编译。
dsw和dsp都是unix格式,vc6不能打开。



sorry ,没有说清楚。你试的是  libevent-1.4.4-iocp/WIN32-Prj 目录里面的 dsw 和 dsp 吧?这个是官方的版本,是有问题的。
请试试 libevent-1.4.4-iocp/libevent-iocp 里面的,是用 vc6 的。

[ 本帖最后由 iunknown 于 2008-6-9 09:09 编辑 ]

论坛徽章:
0
28 [报告]
发表于 2008-06-09 12:04 |只看该作者
原帖由 iunknown 于 2008-6-8 18:31 发表


不知道有没看过  这本书?
里面有一段


通常用 epoll 的时候,也是用 non-blocking 的方式的吧? non-blocking 是可以立即知道操作结果的,和 blocking 的差别在于当没有数据可读的时候,non-blocking ...



哦 是的 是的。 我当然有读过的。

但问题 正在这里。普通情况下, non-blocking 是可以立刻知道操作结果的,但是没有数据可读返回 -1. 然后 看错误原因。

你使用了zero data buff, 也就是保证 每次读 都可以知道结果 而不会返回 -1? 而 no-blocking 的recv 另一个特性的
需要不断的recv 直到 读到-1 然后重新再进行下一次投递。 也就是说 你的recv 也是会读到-1 这种情况的。

论坛徽章:
0
29 [报告]
发表于 2008-06-09 13:51 |只看该作者
原帖由 benjiam 于 2008-6-9 12:04 发表

哦 是的 是的。 我当然有读过的。

但问题 正在这里。普通情况下, non-blocking 是可以立刻知道操作结果的,但是没有数据可读返回 -1. 然后 看错误原因。

你使用了zero data buff, 也就是保证 每次读 都可以知道结果 而不会返回 -1? 而 no-blocking 的recv 另一个特性的
需要不断的recv 直到 读到-1 然后重新再进行下一次投递。 也就是说 你的recv 也是会读到-1 这种情况的。


这样说吧,在 overlapped IO 的时候,用 zero byte buffer 。然后 GQCS 得到结果的时候,用 recv 用 non-blocking 方式读取。
non-blocking 读取的时候,当然不能再 zero byte buffer 了。这个也就是 Network Programming for Microsoft Windows 书上说的意思。

论坛徽章:
0
30 [报告]
发表于 2008-08-23 15:36 |只看该作者

增加 non-blocking connect 的支持

http://spserver.googlecode.com/f ... 5-stable-iocp-2.zip

最新的版本使用类似于解决 non-blocking accept 的方法实现了 non-blocking connect.
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP