Python论坛 - 讨论区
标题：Re: 答复: Re:_R
2004年08月02日 星期一 09:24
HD hdcola at gmail.com
Mon Aug 2 09:24:40 HKT 2004
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Mon Aug 2 09:24:40 HKT 2004
不知为什么这位黎达同仁对twisted一直很鄙视，到是听说他以经用python写了很牛的东东呢。 :) 他们的应用一定支持udp，我们慢慢挖twisted罢，如果不成我们给twisted加上udp功能好不好？ ^_^ On Mon, 2 Aug 2004 09:10:46 +0800, limodou <chatme at 263.net> wrote: > 黎达?ldw,您好！ > > 怎么可能没有。 > -- HD（燃烧中的火） 我工作我快乐，我勤奋我收获。请与我一起快乐，与我一起收获。
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2004年08月02日 星期一 09:28
info at xichen.com info at xichen.com
Mon Aug 2 09:28:55 HKT 2004
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Mon Aug 2 09:28:55 HKT 2004
Zoom.Quiet,您好！ 谢谢，学习中。。。 ======= 2004-08-02 09:12:31 您在来信中写道：======= >Hollo info: > > 可能是翻译的问题！ >还是看Limodou 的介绍吧！ >http://www.donews.net/limodou/archive/2004/07/10/40913.aspx > > >/******** [2004-08-02]09:12:09 ; info wrote: > >info at xichen.com> hoxide,您好！ > >info at xichen.com> http://www-900.ibm.com/developerWorks/cn/linux/sdk/python/charm-20/index.shtml > >info at xichen.com> 没看懂，能讲解一下吗？ > >info at xichen.com> ======= 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 at xichen.com> = = = = = = = = = = = = = = = = = = = = > > >info at xichen.com> 致 >info at xichen.com> 礼！ > > >info at xichen.com> info >info at xichen.com> info at xichen.com >info at xichen.com> 2004-08-02 > > > >********************************************/ > >-- >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 > = = = = = = = = = = = = = = = = = = = = 致 礼！ info info at xichen.com 2004-08-02
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2004年08月02日 星期一 09:50
黎达文 ldw at suntektech.com
Mon Aug 2 09:50:21 HKT 2004
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Mon Aug 2 09:50:21 HKT 2004
哦，sorry，绝对没有鄙视之意！因为没有用过， 所以我根本不能发出褒扬或者贬斥的任何评论。 我想了一下，可能是我用词不当，用了“所谓”。其实，其代表的意思是：“我没有用过的那个”的意思，.^_^。 这也是为什么我不知道twisted也支持UDP的缘故！ 让我说一下UDP和TCP倒是可以的。其实说实在的UDP没有多少合适使用的环境，TCP要比UDP应用范围更加广泛。 UDP只适合在丢包关系不大的情况下使用，比如DNS，RADIUS（计费除外），流媒体等。甚至一些IM等等。 因为这些应用第一、不涉及到生命安全，第二、丢一两个包没有关系。要是真要拿UDP来实现一些字节敏感的通信协议（类似SMPP等） 的话，那么在UDP上还要做很多很多工作，最终的效果就没有直接使用TCP来得高效！ 按照HD大侠刚才的解析uss就不适合用UDP了！ -----邮件原件----- 发件人: python-chinese-bounces at lists.python.cn [mailto:python-chinese-bounces at lists.python.cn] 代表 HD 发送时间: 2004年8月2日 9:25 收件人: python-chinese at lists.python.cn 主题: Re: 答复: Re:_Re:_[python-chinese]_Re:_ 涓 璁ㄨ 轰 姝ｅ 不知为什么这位黎达同仁对twisted一直很鄙视，到是听说他以经用python写了很牛的东东呢。 :) 他们的应用一定支持udp，我们慢慢挖twisted罢，如果不成我们给twisted加上udp功能好不好？ ^_^ On Mon, 2 Aug 2004 09:10:46 +0800, limodou <chatme at 263.net> wrote: > 黎达?ldw,您好！ > > 怎么可能没有。 > -- HD（燃烧中的火） 我工作我快乐，我勤奋我收获。请与我一起快乐，与我一起收获。
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2004年08月02日 星期一 09:53
info@xichen.com info at xichen.com
Mon Aug 2 09:53:03 HKT 2004
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Mon Aug 2 09:53:03 HKT 2004
HD,您好！
如果是这样的话，应该采用tcp是确定了的。不过我觉得难点在于如果要提高访问速度（文件的缓冲和写入）和一个连接上的处理能力。
如果按照上次提到的不关心后面的存储设备的话，所采用的传输方式有很多借鉴的例子，比如ftp,http和BT等。
我想在实际的例子中，几千台机器的并发的话，对服务器的压力是非常大的。客户端也必须缓冲发送过去的请求包，并在队列中良好的管理。服务器也需要管理和轮询每个连接的客户端的状态。
现阶段我觉得可以分几步来同时进行，协议、传输和队列、优化和文件缓冲。
======= 2004-08-02 09:22:20 您在来信中写道：=======
>这个问题我需要好好的来说明，一起来讨论一下。 :)
>在cmpp中submit是将消息提交给ismg，但是ismg返回的submit_resp并不是一个真正的到达的回复，而是ismg收到的回复。真正用户收到这个消息时会产生一个mo消息，你必须再使用deliver再收回消息报告。也就是说在cmpp的协议中全局事务处理就是一个异步的状态。但不排除一个事务的时间，如cmpp的cancel和query这样的命令。其实cmpp中的submit有时也会时间比较久的，这样通常是和智能网在一起时，即时扣费花费比较久的时间。
>:) 也就是说，在协议上就要考虑好异步，但是在程序中也不可能不出现几秒以上的大事务处理工作。
>
>uss测试框架是为了解决存储访问部分的测试。它主要体现在文件的清单获取、内容存取等工作。这部分工作的特点是客户机的数量相对稳定（可能在数十台至数千台）。不可能使用udp来做处理的原因就是组包的问题，而tcp更能准确的了解到通迅的状况。还有就是这数千台机器的并发会很多，但是应尽可能的减少并发的连接数，而增强一个连接上的处理能力。
>
>查询地址是gns的工作，这部分工作我打算使用短连接来做，这样更简单而且更可行。使用tcp还是udp我想在测试后用事实说话好了。
>
>
>On Mon, 2 Aug 2004 08:44:25 +0800, info at xichen.com <info at xichen.com> wrote:
>> HD,您好！
>>
>> 不能和cmpp一样吗？先发resp消息，再发内容报告，也就是状态报告了。
>> 因为
>> 如果服务器查询文件简介需要花费很长时间，那么请求端就需要很大量的维持这个消息包和缓冲没有收到resp的请求加重了客户机负担。当一定时间没有返回，客户端只能再次发送查询包，服务器将出现恶性循环，直到瘫痪。
>> 我一直没弄明白uss现阶段的目标是什么，可能和我没仔细看信件和资料有关系。
>> 如果现在只查询地址信息，就是类似dns查询。那么和现在的代码目标不相符合啊，而且可以借鉴dns服务的包处理机制。
>> 对于查询地址来讲udp包更适合。因为它不关心连接的状态。
>
>
>--
>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
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
2004年08月02日 星期一 09:55
info at xichen.com info at xichen.com
Mon Aug 2 09:55:01 HKT 2004
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Mon Aug 2 09:55:01 HKT 2004
limodou,您好！
直接提供python的代码不是好些吗？我们是在做开源的项目啊。如果别人有兴趣可以用其他语言按照协议来重些不就行了吗？
======= 2004-08-02 09:10:14 您在来信中写道：=======
>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
>
>_______________________________________________
>python-chinese list
>python-chinese at lists.python.cn
>http://python.cn/mailman/listinfo/python-chinese
>
= = = = = = = = = = = = = = = = = = = =
致
礼！
info
info at xichen.com
2004-08-02
[导入自Mailman归档：http://www.zeuux.org/pipermail/zeuux-python]
Zeuux © 2025
京ICP备05028076号