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号