“这是不是就说明了客户端在确认接收以后服务器才执行handle_write_stream,然后循环发余下的内容。”
不是，服务端accept连接后就开始发文件，不论收不收，客户端收走就继续发，不收就阻塞等。客户端对话框的逻辑与这个无关。
我奇怪你为什么还是要new那个membuf？
那分配的那个message block是干什么用的？
传递mb的指针不久可以了吗。
[ 本帖最后由 wishel 于 2009-10-28 14:26 编辑 ]
原帖由 wishel 于 2009-10-28 14:21 发表 http://www.acejoy.com/bbs/images/common/back.gif
“这是不是就说明了客户端在确认接收以后服务器才执行handle_write_stream,然后循环发余下的内容。”
不是，服务端accept连接后就开始发文件，不论收不收，客户端收走就继续发，不收就阻塞等。客户端对话框的逻辑与这个无关 ...
那我就真郁闷了...越改问题越多。
原帖由 wishel 于 2009-10-28 14:23 发表 http://www.acejoy.com/bbs/images/common/back.gif
我奇怪你为什么还是要new那个membuf？
那分配的那个message block是干什么用的？
我当时发送三种信息：文字信息，文件名，文件内容。我用menbuf后面加了标志来区分，而没有用长度+内容的格式来发送。
我把文件的内容读到了menbuf中，然后发送时多拷贝了一次。但这不是根本问题的所在啊
[ 本帖最后由 psycheqiqi 于 2009-10-28 14:28 编辑 ]
原帖由 psycheqiqi 于 2009-10-28 14:24 发表 http://www.acejoy.com/bbs/images/common/back.gif
那我就真郁闷了...越改问题越多。
我说的是我的例子程序的逻辑，你可以根据情况修改到你的程序里。修改逻辑也可以。
原帖由 wishel 于 2009-10-28 14:27 发表 http://www.acejoy.com/bbs/images/common/back.gif
我说的是我的例子程序的逻辑，你可以根据情况修改到你的程序里。修改逻辑也可以。
你那例子的程序逻辑就是发一段文件，然后等待message_block.reset()后再继续发送。
我把程序也改成这种逻辑了（我在上面贴的代码），但在多连接处理文件结束时有点问题，正在修改。
这样能发送300M的文件肯定能解决资源耗尽的问题？
原帖由 psycheqiqi 于 2009-10-28 14:26 发表 http://www.acejoy.com/bbs/images/common/back.gif
我当时发送三种信息：文字信息，文件名，文件内容。我用menbuf后面加了标志来区分，而没有用长度+内容的格式来发送。
我把文件的内容读到了menbuf中，然后发送时多拷贝了一次。但这不是根本问题的所在啊 ...
为什么不把信息append到message block中呢？
控制内存分配的关键在只new这一个mb。问题在于你new membuf的时候没有做控制。
我的程序简单测过，同时传4个800m的文件没问题。
server的内存占用一直不到4m。
你可以看看你运行你的服务端程序的时候内存会不会一直增长。
原帖由 wishel 于 2009-10-27 16:21 发表 http://www.acejoy.com/bbs/images/common/back.gif
static int
parse_args (int argc, ACE_TCHAR *argv[])
{
ACE_Get_Opt get_opt (argc, argv, ACE_TEXT("h:p:f:d:"));
int c;
while ((c = get_opt ()) != EOF)
switch (c)
{
case 'h':
host = get_opt.opt_arg ();
break;
case 'p':
port = ACE_OS::atoi (get_opt.opt_arg ());
break;
case 'f':
file = get_opt.opt_arg ();
break;
case 'd':
dump_file = get_opt.opt_arg ();
break;
default:
ACE_ERROR ((LM_ERROR, "%p.\n",
"usage :\n"
"-h <host>\n"
"-p <port>\n"
"-f <file>\n"));
return -1;
}
return 0;
}
服务器和客户端运行的时候参数怎么设置？
原帖由 psycheqiqi 于 2009-10-29 12:33 发表 http://acejoy.com/bbs/images/common/back.gif
static int
parse_args (int argc, ACE_TCHAR *argv[])
{
ACE_Get_Opt get_opt (argc, argv, ACE_TEXT("h:p:f:d:"));
int c;
while ((c = get_opt ()) != EOF)
switch (c)
{
case 'h':
...
假设server ip 为192.168.1.2
服务端：
server
客户端:
client -h "192.168.1.2" -d 1
就会把服务端aaa.aa文件传到客户端，写入文件1
可以同时开别的客户端：
client -h "192.168.1.2" -d 2
源文件名，端口号等都可以类似设置。
把server改成用TransmitFile测了下。同时开2个连接（2个client），每连接传350m的同一文件。client和server都在在本机，利用loopback接口。TransmitFile模式NumberOfBytesPerSend设置为64k，完成端口模式（win下proactor默认）MessageBlockSize也设置为64k。结果：
在TransmitFile模式下，server进程cpu的利用率一直是0，在普通异步io模式下，server进程cpu的利用率大概是16%左右。两种模式下每个client进程的cpu利用率都差不多10%左右。（估值，通过任务管理器看的，抖动比较厉害）
加了TransmitFile的server程序：