2004年08月02日 星期一 08:54
同意,UDP更加合适,只是不知道那个所谓的twisted是不是根本没有UDP相关的组件。.^_^。 -----邮件原件----- 发件人: python-chinese-bounces at lists.python.cn [mailto:python-chinese-bounces at lists.python.cn] 代表 info at xichen.com 发送时间: 2004年8月2日 8:44 收件人: python-chinese at lists.python.cn 主题: Re: Re:_Re:_[python-chinese]_Re:_ 涓 璁ㄨ 轰 姝e HD,您好! 不能和cmpp一样吗?先发resp消息,再发内容报告,也就是状态报告了。 因为 如果服务器查询文件简介需要花费很长时间,那么请求端就需要很大量的维持这个消息包和缓冲没有收到resp的请求加重了客户机负担。当一定时间没有返回,客户端只能再次发送查询包,服务器将出现恶性循环,直到瘫痪。 我一直没弄明白uss现阶段的目标是什么,可能和我没仔细看信件和资料有关系。 如果现在只查询地址信息,就是类似dns查询。那么和现在的代码目标不相符合啊,而且可以借鉴dns服务的包处理机制。 对于查询地址来讲udp包更适合。因为它不关心连接的状态。 ======= 2004-08-01 21:38:35 您在来信中写道:======= >想起了你的代码了,给你一个非常特殊但是也会非常容易出现的情况,a这个报文是查询一个用户存储中的所有文件的简介,这个数据库查询的时间会较长,这种 >情况下,如何处理? > >On Sun, 01 Aug 2004 19:19:25 +0800, "info" <info at xichen.com> ><info at xichen.com> wrote: >> 周一上班了才能仔细看列表里面的邮件.再学习一下各位的先进经验. >> >> 关于短连接如果是用udp协议的话,我有几点建议. >> 1、对于短连接来讲,滑动窗口存在的意义不大。因为是无连接的连接协议,保存发送的 >> 数据包的状态并做正确处理(比如缓冲等)更需要良好的处理。 >> 2、针对与不同的路由方式(有建立连接后端口不变和端口变化)需要不同的处理方式。 >> (也就是最头疼的udp穿越路由的问题) >> 3、解决后包先到,数据包重新组合的问题。 >> >> 还有,我觉得我写的版本好象比你们快些哦,窗口定为40后,单机运行在32秒左右发完 >> 所有包。配置p4 2.4 +512RAM+2k >> >> HD的信件内容: >> >> > 呵呵.在我本机做的测试.数据量为0xfffff >> > 测试数据. 1048575 条 >> > 收到 1048575 条 >> > 最后收到uid为.1048574 >> > 用时.500.64 秒 >> > 每秒.2094.466528条 >> > 已经基本达到的预期.下面就看短连接的情况了. :) >> > >> > On Sat, 31 Jul 2004 13:33:54 +0800, Zoom.Quiet <zoomq at infopro.cn> wrote: >> >> Hollo HD: >> >> >> >> 神. >> >> Server at Win2k3; PIV2.8GHz;2Gb; >> >> Client from Win2k3; C2.5Gb;512Mb; >> >> [g:\zdevelop\zpython\@python-chinese\@uss\040731-hoxide\benchmarks >> >> ]python ussc.py Connect successfully Connection lost >> >> 测试数据. 65535 条 >> >> 收到 65535 条 >> >> 最后收到uid为.65534 >> >> 用时.48.37 秒 >> >> 每秒.1354.951168条 >> >> >> >> +++++++++++++++ >> >> Server at Win2k3; C2.5Gb;512Mb; >> >> Client from Win2k3; PIV2.8GHz;2Gb; >> >> F:\ZqTEMP\040731-hoxide\benchmarks>python ussc.py Connect >> >> successfully Connection lost >> >> 测试数据. 65535 条 >> >> 收到 65535 条 >> >> 最后收到uid为.65534 >> >> 用时.38.96 秒 >> >> 每秒.1681.915314条 >> >> >> >> 看来将压力放到了客户端..... >> >> >> >> /******** [2004-07-31]13:31:16 ; HD wrote: >> >> >> >> HD> 这是我和hoxide优化后的banchmarks.数据量达到0xffff时还能保持到每秒2300的. :) >> >> HD> 大家试试罢.今天晚上将细说banchmarks的优化过程. >> >> >> >> HD> On Sat, 31 Jul 2004 10:29:32 +0800, HD <hdcola at gmail.com> wrote: >> >> >> 今天晚上.7月31日..月黑风高之时.20时点整..有一大驼人.pythoner.pyuss参与者.twisteder们..将 >> >> >> 在uc.http://www.51uc.com可以下到.中的窝点.团体号4070424.开音乐会.twisted精讲会.ope >> >> >> n >> >> >> gns讨论会. >> >> >> 欢迎大家前来参与.有任何问题请与火.就是HD乐..天成.qq号2251744.联系.或请至电qq群1073669向在线的gg.jj.dd.mm们询问. >> >> >> >> >> >> -- >> >> >> HD.燃烧中的火. >> >> >> 我工作我快乐.我勤奋我收获.请与我一起快乐.与我一起收获. >> >> >> >> >> >> >> >> >> >> >> ********************************************/ >> >> >> >> -- >> >> Free as in Freedom >> >> >> >> Zoom.Quiet >> >> >> >> #=========================================# >> >> ]Time is unimportant, only life important![ >> >> #=========================================# >> >> >> >> sender is the Bat!2.12.00 >> >> >> >> _______________________________________________ >> >> python-chinese list >> >> python-chinese at lists.python.cn >> >> http://python.cn/mailman/listinfo/python-chinese >> >> >> > >> > >> > -- >> > HD.燃烧中的火. >> > 我工作我快乐.我勤奋我收获.请与我一起快乐.与我一起收获. >> > _______________________________________________ >> > python-chinese list >> > python-chinese at lists.python.cn >> > http://python.cn/mailman/listinfo/python-chinese >> >> _______________________________________________ >> python-chinese list >> python-chinese at lists.python.cn >> http://python.cn/mailman/listinfo/python-chinese >> > > >-- >HD(燃烧中的火) >我工作我快乐,我勤奋我收获。请与我一起快乐,与我一起收获。 >_______________________________________________ >python-chinese list >python-chinese at lists.python.cn >http://python.cn/mailman/listinfo/python-chinese = = = = = = = = = = = = = = = = = = = = 致 礼! info info at xichen.com 2004-08-02
2004年08月02日 星期一 08:54
info,您好, 谢谢,正在下载ing…… -----原始邮件----- 发件人: python-chinese-bounces at lists.python.cn [mailto:python-chinese-bounces at lists.python.cn]代表 info at xichen.com 发送时间: 2004年8月2日 8:46 收件人: python-chinese at lists.python.cn 主题: Re: Re: 答复: [python-chinese]第二次网上教程之录音文件 info"http://219.140.78.7/py-tut2.r http://219.140.78.7/py-tut2.mp3 ======= 2004-08-01 19:11:51 您在来信中写道:======= >我周一上班后帮你们传上去. > >Liming_Do的信件内容: > >> info,您好, >> 能不能再麻烦传到上次的地址,http://219.140.78.7/py-tut1.r >> 这个地址超快,而且应该有一些人象我一样不能访问FTP >> 或者Yanbo有没有Http的空间? >> >> -----原始邮件----- >> 发件人: python-chinese-bounces at lists.python.cn >> [mailto:python-chinese-bounces at lists.python.cn]代表 Xie Yanbo >> 发送时间: 2004年8月1日 17:32 >> 收件人: python-chinese at lists.python.cn >> 主题: [python-chinese] 第二次网上教程之录音文件 >> >> >> 从开始到最后,包括HD不在的半个多小时一点不漏,原始素材,180M >> >> ftp://202.108.142.211/pub/twisted/20040801.mp3 >> >> 不能下载mp3格式文件的下载: >> >> ftp://202.108.142.211/pub/twisted/20040801.copy >> >> _______________________________________________ >> python-chinese list >> python-chinese at lists.python.cn >> http://python.cn/mailman/listinfo/python-chinese >> _______________________________________________ >> python-chinese list >> python-chinese at lists.python.cn >> http://python.cn/mailman/listinfo/python-chinese > > >_______________________________________________ >python-chinese list >python-chinese at lists.python.cn >http://python.cn/mailman/listinfo/python-chinese > = = = = = = = = = = = = = = = = = = = = 致 礼! info info at xichen.com 2004-08-02
2004年08月02日 星期一 08:56
hoxide,您好! http://www-900.ibm.com/developerWorks/cn/linux/sdk/python/charm-20/index.shtml 没看懂,能讲解一下吗? ======= 2004-08-01 12:19:47 您在来信中写道:======= >HD,您好! > >大家最好先了解一下生成器的有关知识:IBM上的《可爱的 Python:迭代器和简单生成器》: http://www-900.ibm.com/developerWorks/cn/linux/sdk/python/charm-20/index.shtml > >昨天给的代码还有点错误,修改的代码(其实只改了打星号的地方): > > def testserver(self): > """向服务器发的测试报文""" > try: > self.pp.next() > self.call = reactor.callLater(0,self.testserver) > return > except StopIteration: > pass > > def __init__(self): > self.pp=self.sendQQ() > ussp.USSClientQueueProtocol.__init__(self) > > def sendQQ(self): > global nownum > global count > i=1 > while i < count: > message = usspmsg.USSPMessage() > message.setMsgName('mail_counter') > message.body.setField('uid',str(i)) > while self.factory.sendQueue.full(): #* > yield None #** > self.factory.sendQueue.put_nowait(message) > i += 1 > nownum=i > self.disconnect() > >这里真正的处理是在sendQQ这个函数定义的.self.pp是生成器的实例,由__init__()生成,testserver只是调度完成这个处理的函数,而且是和具体的处理独立的,他只是简单得实现了当处理"暂停"后的重新启动. > >真正神奇的地方是打星号的行.他测试sendQueue确定是否能发出message,如果不能就会执行yield None,这时函数就终止在**这行,直到在有.next()方法调用时再从这句开始执行. >这个好处是原来的处理流程可以很顺利得进行.不需要保存中间变量.注意0731a的testserver能正确得发出所有message,是因为恰巧有全局变量nownum完全确定处理的执行状态了.但事事上一般的处理不会那么简单,有复杂的状态组合(上面的代码并没用nownum,而是用了循环变量i,注意他不是全局的!!!!!).正像zoomq昨天说的0731a的testserver在queue满的时候前面对message的处理就被抛弃了,但在这个生成器版本,先前对message的处理没有被抛弃. > >个人觉得这个生成器版本还是不够完美,异步传输还是应该以线程为基础进行.下一个版本可能是基于生成器的简单线程:) > >说得不是很明白,我不清楚大家对什么地方有疑问. > > >===== 2004-08-01 00:33:08 您在来信中写道:======= > >>细说说,为什么说是生成器版的呢? >> >>On Sat, 31 Jul 2004 23:22:53 +0800, hoxide <hoxide_dirac at yahoo.com.cn> wrote: >>> python-chinese,您好! >>> >>> 为什么要用生成器,现在的testserver的执行流程只依赖于nownum,而事实上通常的服务要依赖于整个运行流程.另外这样的写法可将窗口部分的代码抽出. >>> >>> 致 >>> 礼! >>> >>> hoxide >>> hoxide_dirac at yahoo.com.cn >>> 2004-07-31 >>> >>> >>> >> >> >>-- >>HD(燃烧中的火) >>我工作我快乐,我勤奋我收获。请与我一起快乐,与我一起收获。 >>_______________________________________________ >>python-chinese list >>python-chinese at lists.python.cn >>http://python.cn/mailman/listinfo/python-chinese >> > >= = = = = = = = = = = = = = = = = = = = > > > 致 >礼! > > > hoxide > hoxide_dirac at yahoo.com.cn > 2004-08-01 > >_______________________________________________ >python-chinese list >python-chinese at lists.python.cn >http://python.cn/mailman/listinfo/python-chinese > = = = = = = = = = = = = = = = = = = = = 致 礼! info info at xichen.com 2004-08-02
2004年08月02日 星期一 09:04
python-chinese,您好! 刘鑫怎么没看见发言了呢?身为专栏作家,当时我学习python的时候他给了很大的帮助,也提一些意见啊。 致 礼! info info at xichen.com 2004-08-02
2004年08月02日 星期一 09:10
info,您好! 我想对于客户端我们首先要提供的是一个可用的API包。那么这个API包可能就有线程的内容。我们不仅要考虑稳定,还要考虑可扩展性。我们不能排除客户端的多线程访问,也许API不提供,那么客户端可能就会自已来实现了,既然如此,还不如由我们来提供为好。 ======= 2004-08-02 08:52:45 您在来信中写道:======= >limodou,您好! > > 用twisted写的服务器端本身就处理的多线程,这个大家可以用我们做测试的例子来试。 > 对于客户端来讲,除非是传输文件本身,没有必要采用多线程。 > 我的意见是,达到本期的产品基线,然后用最稳定、最简洁的方式来实现。 > >======= 2004-08-01 16:50:58 您在来信中写道:======= > >>hoxide,您好! >> >> 的确,整个程序只有一个线程,那么这种异步都通过twisted来完成,的确象queue这种阻塞方式就无法实现了。多线程,多点测试才更符合实际。 >> >> >>======= 2004-08-01 15:28:13 您在来信中写道:======= >> >>>limodou,您好! >>> >>> 开始我们也尝试过用queue的阻塞处理,但这样就阻塞了主线程,连recive都不行. >>>这个问题的根本解决方案还是用线程,我只是提供一种类似的东西("轻便线程"http://www-900.ibm.com/developerWorks/cn/linux/sdk/python/) >>>另外我觉得应该建一个多连接的测试程序,而不只是一个连接多请求的测试程序. >>>而窗口应该放在服务端比较好一点 >>> >>>======= 2004-08-01 14:54:55 您在来信中写道:======= >>> >>>>hoxide,您好! >>>> >>>> 其实真正的数据发送是由客户端做的,我们可以把连接、发送数据等进行封装由客户端来调用。这样由客户端去组织数据,而我们的协议处理只是一个被调用方就行了。因为这只是一个测试程序,还不是真正的应用,因此可能就不讲究了。真正做成客户端,可能程序都要改了。既然我们不想发送太快,queue完全可以采用阻塞方式来处理。 >>>> >>>>======= 2004-08-01 14:31:17 您在来信中写道:======= >>>> >>>>>limodou,您好! >>>>> >>>>> 这点我直到但是程序还是依赖一个全局变量,对于复杂的情况,这种用法是不好的,首先明显得会带来名字空间的污染,其次如果程序执行的上下文关系复杂,那么也就不是几个全局变量能轻松解决的. >>>>> >>>>> >>>>>======= 2004-08-01 14:07:21 您在来信中写道:======= >>>>> >>>>>>hoxide,您好! >>>>>> >>>>>> 其实不丢message也可以,这样不用使用生成器。只要把message生成放到else中就行了。因为那时是可以发送数据的。之所以丢是因为先生成了message,然后才判断是否可以发送,如果不能发送自然就丢了。如果改到可以发送才生成message就不会丢了。 >>>>>> >>>>>> while nownum < count: >>>>>> if self.factory.sendQueue.full(): >>>>>> self.call = reactor.callLater(0, self.testserver) >>>>>> return >>>>>> else: >>>>>> message = usspmsg.USSPMessage() #* >>>>>> message.setMsgName('mail_counter') #* >>>>>> message.body.setField('uid',str(nownum)) #* 这几行移下来了 >>>>>> self.factory.sendQueue.put_nowait(message) >>>>>> nownum += 1 >>>>>> >>>>>>======= 2004-08-01 12:19:47 您在来信中写道:======= >>>>>> >>>>>>>HD,您好! >>>>>>> >>>>>>>大家最好先了解一下生成器的有关知识:IBM上的《可爱的 Python:迭代器和简单生成器》: http://www-900.ibm.com/developerWorks/cn/linux/sdk/python/charm-20/index.shtml >>>>>>> >>>>>>>昨天给的代码还有点错误,修改的代码(其实只改了打星号的地方): >>>>>>> >>>>>>> def testserver(self): >>>>>>> """向服务器发的测试报文""" >>>>>>> try: >>>>>>> self.pp.next() >>>>>>> self.call = reactor.callLater(0,self.testserver) >>>>>>> return >>>>>>> except StopIteration: >>>>>>> pass >>>>>>> >>>>>>> def __init__(self): >>>>>>> self.pp=self.sendQQ() >>>>>>> ussp.USSClientQueueProtocol.__init__(self) >>>>>>> >>>>>>> def sendQQ(self): >>>>>>> global nownum >>>>>>> global count >>>>>>> i=1 >>>>>>> while i < count: >>>>>>> message = usspmsg.USSPMessage() >>>>>>> message.setMsgName('mail_counter') >>>>>>> message.body.setField('uid',str(i)) >>>>>>> while self.factory.sendQueue.full(): #* >>>>>>> yield None #** >>>>>>> self.factory.sendQueue.put_nowait(message) >>>>>>> i += 1 >>>>>>> nownum=i >>>>>>> self.disconnect() >>>>>>> >>>>>>>这里真正的处理是在sendQQ这个函数定义的.self.pp是生成器的实例,由__init__()生成,testserver只是调度完成这个处理的函数,而且是和具体的处理独立的,他只是简单得实现了当处理"暂停"后的重新启动. >>>>>>> >>>>>>>真正神奇的地方是打星号的行.他测试sendQueue确定是否能发出message,如果不能就会执行yield None,这时函数就终止在**这行,直到在有.next()方法调用时再从这句开始执行. >>>>>>>这个好处是原来的处理流程可以很顺利得进行.不需要保存中间变量.注意0731a的testserver能正确得发出所有message,是因为恰巧有全局变量nownum完全确定处理的执行状态了.但事事上一般的处理不会那么简单,有复杂的状态组合(上面的代码并没用nownum,而是用了循环变量i,注意他不是全局的!!!!!).正像zoomq昨天说的0731a的testserver在queue满的时候前面对message的处理就被抛弃了,但在这个生成器版本,先前对message的处理没有被抛弃. >>>>>>> >>>>>>>个人觉得这个生成器版本还是不够完美,异步传输还是应该以线程为基础进行.下一个版本可能是基于生成器的简单线程:) >>>>>>> >>>>>>>说得不是很明白,我不清楚大家对什么地方有疑问. >>>>>>> >>>>>>> >>>>>>>===== 2004-08-01 00:33:08 您在来信中写道:======= >>>>>>> >>>>>>>>细说说,为什么说是生成器版的呢? >>>>>>>> >>>>>>>>On Sat, 31 Jul 2004 23:22:53 +0800, hoxide <hoxide_dirac at yahoo.com.cn> wrote: >>>>>>>>> python-chinese,您好! >>>>>>>>> >>>>>>>>> 为什么要用生成器,现在的testserver的执行流程只依赖于nownum,而事实上通常的服务要依赖于整个运行流程.另外这样的写法可将窗口部分的代码抽出. >>>>>>>>> >>>>>>>>> 致 >>>>>>>>> 礼! >>>>>>>>> >>>>>>>>> hoxide >>>>>>>>> hoxide_dirac at yahoo.com.cn >>>>>>>>> 2004-07-31 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>-- >>>>>>>>HD(燃烧中的火) >>>>>>>>我工作我快乐,我勤奋我收获。请与我一起快乐,与我一起收获。 >>>>>>>>_______________________________________________ >>>>>>>>python-chinese list >>>>>>>>python-chinese at lists.python.cn >>>>>>>>http://python.cn/mailman/listinfo/python-chinese >>>>>>>> >>>>>>> >>>>>>>= = = = = = = = = = = = = = = = = = = = >>>>>>> >>>>>>> >>>>>>> 致 >>>>>>>礼! >>>>>>> >>>>>>> >>>>>>> hoxide >>>>>>> hoxide_dirac at yahoo.com.cn >>>>>>> 2004-08-01 >>>>>>> >>>>>>>_______________________________________________ >>>>>>>python-chinese list >>>>>>>python-chinese at lists.python.cn >>>>>>>http://python.cn/mailman/listinfo/python-chinese >>>>>>> >>>>>> >>>>>>= = = = = = = = = = = = = = = = = = = = >>>>>> >>>>>> >>>>>> 致 >>>>>>礼! >>>>>> >>>>>> >>>>>> limodou >>>>>> chatme at 263.net >>>>>> 2004-08-01 >>>>>> >>>>>>_______________________________________________ >>>>>>python-chinese list >>>>>>python-chinese at lists.python.cn >>>>>>http://python.cn/mailman/listinfo/python-chinese >>>>>> >>>>> >>>>>= = = = = = = = = = = = = = = = = = = = >>>>> >>>>> >>>>> 致 >>>>>礼! >>>>> >>>>> >>>>> hoxide >>>>> hoxide_dirac at yahoo.com.cn >>>>> 2004-08-01 >>>>> >>>>>_______________________________________________ >>>>>python-chinese list >>>>>python-chinese at lists.python.cn >>>>>http://python.cn/mailman/listinfo/python-chinese >>>>> >>>> >>>>= = = = = = = = = = = = = = = = = = = = >>>> >>>> >>>> 致 >>>>礼! >>>> >>>> >>>> limodou >>>> chatme at 263.net >>>> 2004-08-01 >>>> >>>>_______________________________________________ >>>>python-chinese list >>>>python-chinese at lists.python.cn >>>>http://python.cn/mailman/listinfo/python-chinese >>>> >>> >>>= = = = = = = = = = = = = = = = = = = = >>> >>> >>> 致 >>>礼! >>> >>> >>> hoxide >>> hoxide_dirac at yahoo.com.cn >>> 2004-08-01 >>> >>>_______________________________________________ >>>python-chinese list >>>python-chinese at lists.python.cn >>>http://python.cn/mailman/listinfo/python-chinese >>> >> >>= = = = = = = = = = = = = = = = = = = = >> >> >> 致 >>礼! >> >> >> limodou >> chatme at 263.net >> 2004-08-01 >> >>_______________________________________________ >>python-chinese list >>python-chinese at lists.python.cn >>http://python.cn/mailman/listinfo/python-chinese >> > >= = = = = = = = = = = = = = = = = = = = > > > 致 >礼! > > > info > info at xichen.com > 2004-08-02 > >_______________________________________________ >python-chinese list >python-chinese at lists.python.cn >http://python.cn/mailman/listinfo/python-chinese > = = = = = = = = = = = = = = = = = = = = 致 礼! limodou chatme at 263.net 2004-08-02
2004年08月02日 星期一 09:10
黎达?ldw,您好! 怎么可能没有。 ======= 2004-08-02 08:54:46 您在来信中写道:======= >同意,UDP更加合适,只是不知道那个所谓的twisted是不是根本没有UDP相关的组件。.^_^。 > >-----邮件原件----- >发件人: python-chinese-bounces at lists.python.cn [mailto:python-chinese-bounces at lists.python.cn] 代表 info at xichen.com >发送时间: 2004年8月2日 8:44 >收件人: python-chinese at lists.python.cn >主题: Re: Re:_Re:_[python-chinese]_Re:_ 涓 璁ㄨ 轰 姝e > >HD,您好! > > 不能和cmpp一样吗?先发resp消息,再发内容报告,也就是状态报告了。 > 因为 > 如果服务器查询文件简介需要花费很长时间,那么请求端就需要很大量的维持这个消息包和缓冲没有收到resp的请求加重了客户机负担。当一定时间没有返回,客户端只能再次发送查询包,服务器将出现恶性循环,直到瘫痪。 > 我一直没弄明白uss现阶段的目标是什么,可能和我没仔细看信件和资料有关系。 > 如果现在只查询地址信息,就是类似dns查询。那么和现在的代码目标不相符合啊,而且可以借鉴dns服务的包处理机制。 > 对于查询地址来讲udp包更适合。因为它不关心连接的状态。 > >======= 2004-08-01 21:38:35 您在来信中写道:======= > >>想起了你的代码了,给你一个非常特殊但是也会非常容易出现的情况,a这个报文是查询一个用户存储中的所有文件的简介,这个数据库查询的时间会较长,这种 >>情况下,如何处理? >> >>On Sun, 01 Aug 2004 19:19:25 +0800, "info" <info at xichen.com> >><info at xichen.com> wrote: >>> 周一上班了才能仔细看列表里面的邮件.再学习一下各位的先进经验. >>> >>> 关于短连接如果是用udp协议的话,我有几点建议. >>> 1、对于短连接来讲,滑动窗口存在的意义不大。因为是无连接的连接协议,保存发送的 >>> 数据包的状态并做正确处理(比如缓冲等)更需要良好的处理。 >>> 2、针对与不同的路由方式(有建立连接后端口不变和端口变化)需要不同的处理方式。 >>> (也就是最头疼的udp穿越路由的问题) >>> 3、解决后包先到,数据包重新组合的问题。 >>> >>> 还有,我觉得我写的版本好象比你们快些哦,窗口定为40后,单机运行在32秒左右发完 >>> 所有包。配置p4 2.4 +512RAM+2k >>> >>> HD的信件内容: >>> >>> > 呵呵.在我本机做的测试.数据量为0xfffff >>> > 测试数据. 1048575 条 >>> > 收到 1048575 条 >>> > 最后收到uid为.1048574 >>> > 用时.500.64 秒 >>> > 每秒.2094.466528条 >>> > 已经基本达到的预期.下面就看短连接的情况了. :) >>> > >>> > On Sat, 31 Jul 2004 13:33:54 +0800, Zoom.Quiet <zoomq at infopro.cn> wrote: >>> >> Hollo HD: >>> >> >>> >> 神. >>> >> Server at Win2k3; PIV2.8GHz;2Gb; >>> >> Client from Win2k3; C2.5Gb;512Mb; >>> >> [g:\zdevelop\zpython\@python-chinese\@uss\040731-hoxide\benchmarks >>> >> ]python ussc.py Connect successfully Connection lost >>> >> 测试数据. 65535 条 >>> >> 收到 65535 条 >>> >> 最后收到uid为.65534 >>> >> 用时.48.37 秒 >>> >> 每秒.1354.951168条 >>> >> >>> >> +++++++++++++++ >>> >> Server at Win2k3; C2.5Gb;512Mb; >>> >> Client from Win2k3; PIV2.8GHz;2Gb; >>> >> F:\ZqTEMP\040731-hoxide\benchmarks>python ussc.py Connect >>> >> successfully Connection lost >>> >> 测试数据. 65535 条 >>> >> 收到 65535 条 >>> >> 最后收到uid为.65534 >>> >> 用时.38.96 秒 >>> >> 每秒.1681.915314条 >>> >> >>> >> 看来将压力放到了客户端..... >>> >> >>> >> /******** [2004-07-31]13:31:16 ; HD wrote: >>> >> >>> >> HD> 这是我和hoxide优化后的banchmarks.数据量达到0xffff时还能保持到每秒2300的. :) >>> >> HD> 大家试试罢.今天晚上将细说banchmarks的优化过程. >>> >> >>> >> HD> On Sat, 31 Jul 2004 10:29:32 +0800, HD <hdcola at gmail.com> wrote: >>> >> >> 今天晚上.7月31日..月黑风高之时.20时点整..有一大驼人.pythoner.pyuss参与者.twisteder们..将 >>> >> >> 在uc.http://www.51uc.com可以下到.中的窝点.团体号4070424.开音乐会.twisted精讲会.ope >>> >> >> n >>> >> >> gns讨论会. >>> >> >> 欢迎大家前来参与.有任何问题请与火.就是HD乐..天成.qq号2251744.联系.或请至电qq群1073669向在线的gg.jj.dd.mm们询问. >>> >> >> >>> >> >> -- >>> >> >> HD.燃烧中的火. >>> >> >> 我工作我快乐.我勤奋我收获.请与我一起快乐.与我一起收获. >>> >> >>> >> >>> >> >> >>> >> >>> >> ********************************************/ >>> >> >>> >> -- >>> >> Free as in Freedom >>> >> >>> >> Zoom.Quiet >>> >> >>> >> #=========================================# >>> >> ]Time is unimportant, only life important![ >>> >> #=========================================# >>> >> >>> >> sender is the Bat!2.12.00 >>> >> >>> >> _______________________________________________ >>> >> python-chinese list >>> >> python-chinese at lists.python.cn >>> >> http://python.cn/mailman/listinfo/python-chinese >>> >> >>> > >>> > >>> > -- >>> > HD.燃烧中的火. >>> > 我工作我快乐.我勤奋我收获.请与我一起快乐.与我一起收获. >>> > _______________________________________________ >>> > python-chinese list >>> > python-chinese at lists.python.cn >>> > http://python.cn/mailman/listinfo/python-chinese >>> >>> _______________________________________________ >>> python-chinese list >>> python-chinese at lists.python.cn >>> http://python.cn/mailman/listinfo/python-chinese >>> >> >> >>-- >>HD(燃烧中的火) >>我工作我快乐,我勤奋我收获。请与我一起快乐,与我一起收获。 >>_______________________________________________ >>python-chinese list >>python-chinese at lists.python.cn >>http://python.cn/mailman/listinfo/python-chinese > >= = = = = = = = = = = = = = = = = = = = > > > 致 >礼! > > > info > info at xichen.com > 2004-08-02 > >_______________________________________________ >python-chinese list >python-chinese at lists.python.cn >http://python.cn/mailman/listinfo/python-chinese > = = = = = = = = = = = = = = = = = = = = 致 礼! limodou chatme at 263.net 2004-08-02
2004年08月02日 星期一 09:11
python-chinese,您好! "编写TCP客户端"和"运用进程"我已经翻完了,不过忘在家里了.晚上上载 今天打算翻"UDP网络" 以前没有翻过东西,还请大家多多指正. 另外麻烦Zoomq看看是不是wiki格式我写的不对,怎么实例代码看起来和前面的很不同. 致 礼! Jerry Marx zhiyuan.ma at enorbus.com.cn 2004-08-02
Zeuux © 2025
京ICP备05028076号