这个问题我需要好好的来说明，一起来讨论一下。 :)
在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（燃烧中的火）
我工作我快乐，我勤奋我收获。请与我一起快乐，与我一起收获。

Hollo HD:
注意哪！大家的邮件主题怎么了！？！？
乱码！我一点邮件，整个软件就死了！


++++++++++++++++++++++++++++++++++++++++
  答复: 答复: Re:_Re:_[python-chinese]_Re:_???涓????璁ㄨ?轰??姝ｅ????????
黎达文 ldw at suntektech.com 
Mon Aug 2 09:50:21 HKT 2004 

Previous message: Re: 答复: Re:_Re:_[python-chinese]_Re:_???涓????璁ㄨ?轰??姝ｅ???????? 
Next message: Re: Re[4]: _[python-chinese]_一个生成器版本的ussc.py 
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 

--------------------------------------------------------------------------------

哦，sorry，绝对没有鄙视之意！因为没有用过， 所以我根本不能发出褒扬或者贬斥的任何评论。
我想了一下，可能是我用词不当，用了“所谓”。其实，其代表的意思是：“我没有用过的那个”的意思，.^_^。
这也是为什么我不知道twisted也支持UDP的缘故！
让我说一下UDP和TCP倒是可以的。其实说实在的UDP没有多少合适使用的环境，TCP要比UDP应用范围更加广泛。
UDP只适合在丢包关系不大的情况下使用，比如DNS，RADIUS（计费除外），流媒体等。甚至一些IM等等。
因为这些应用第一、不涉及到生命安全，第二、丢一两个包没有关系。要是真要拿UDP来实现一些字节敏感的通信协议（类似SMPP等）
的话，那么在UDP上还要做很多很多工作，最终的效果就没有直接使用TCP来得高效！
按照HD大侠刚才的解析uss就不适合用UDP了！




/******** [2004-08-02]10:00:28 ; HD wrote:

HD> 这个问题我需要好好的来说明，一起来讨论一下。 :)
HD> 在cmpp中submit是将消息提交给ismg，但是ismg返回的submit_resp并不是一个真正的到达的回复，而是ismg收到的回复。真正用户收到这个消息时会产生一个mo消息，你必须再使用deliver再收回消息报告。也就是说在cmpp的协议中全局事务处理就是一个异步的状态。但不排除一个事务的时间，如cmpp的cancel和query这样的命令。其实cmpp中的submit有时也会时间比较久的，这样通常是和智能网在一起时，即时扣费花费比较久的时间。
HD> :)
HD> 也就是说，在协议上就要考虑好异步，但是在程序中也不可能不出现几秒以上的大事务处理工作。

HD> uss测试框架是为了解决存储访问部分的测试。它主要体现在文件的清单获取、内容存取等工作。这部分工作的特点是客户机的数量相对稳定（可能在数十台至数千台）。不可能使用udp来做处理的原因就是组包的问题，而tcp更能准确的了解到通迅的状况。还有就是这数千台机器的并发会很多，但是应尽可能的减少并发的连接数，而增强一个连接上的处理能力。

HD> 查询地址是gns的工作，这部分工作我打算使用短连接来做，这样更简单而且更可行。使用tcp还是udp我想在测试后用事实说话好了。


HD> 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包更适合。因为它不关心连接的状态。




********************************************/

-- 
Free as in Freedom

 Zoom.Quiet                           

#=========================================#
]Time is unimportant, only life important![
#=========================================#

sender is the Bat!2.12.00

用那个软件的，容错性这么差的。 

-----邮件原件-----
发件人: python-chinese-bounces at lists.python.cn
[mailto:python-chinese-bounces at lists.python.cn] 代表 Zoom.Quiet
发送时间: 2004年8月2日 10:02
收件人: HD
主题: [python-chinese] Re[3]:一个生成器版本的ussc.py

Hollo HD:
注意哪！大家的邮件主题怎么了！？！？
乱码！我一点邮件，整个软件就死了！


++++++++++++++++++++++++++++++++++++++++
  答复: 答复: Re:_Re:_[python-chinese]_Re:_???涓????璁ㄨ?轰??姝ｅ????????
黎达文 ldw at suntektech.com
Mon Aug 2 09:50:21 HKT 2004 

Previous message: Re: 答复: Re:_Re:_[python-chinese]_Re:_???涓????璁ㄨ?轰??
姝ｅ???????? 
Next message: Re: Re[4]: _[python-chinese]_一个生成器版本的ussc.py
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] 

----------------------------------------------------------------------------
----

哦，sorry，绝对没有鄙视之意！因为没有用过， 所以我根本不能发出褒扬或者贬斥的
任何评论。
我想了一下，可能是我用词不当，用了“所谓”。其实，其代表的意思是：“我没有用
过的那个”的意思，.^_^。
这也是为什么我不知道twisted也支持UDP的缘故！
让我说一下UDP和TCP倒是可以的。其实说实在的UDP没有多少合适使用的环境，TCP要比
UDP应用范围更加广泛。
UDP只适合在丢包关系不大的情况下使用，比如DNS，RADIUS（计费除外），流媒体等。
甚至一些IM等等。
因为这些应用第一、不涉及到生命安全，第二、丢一两个包没有关系。要是真要拿UDP
来实现一些字节敏感的通信协议（类似SMPP等）
的话，那么在UDP上还要做很多很多工作，最终的效果就没有直接使用TCP来得高效！
按照HD大侠刚才的解析uss就不适合用UDP了！




/******** [2004-08-02]10:00:28 ; HD wrote:

HD> 这个问题我需要好好的来说明，一起来讨论一下。 :)
HD> 在cmpp中submit是将消息提交给ismg，但是ismg返回的submit_resp并不是一个真
正的到达的回复，而是ismg收到的回
HD> 复。真正用户收到这个消息时会产生一个mo消息，你必须再使用deliver再收回消
息报告。也就是说在cmpp的协议中全局事务处理就是一个异
HD> 步的状态。但不排除一个事务的时间，如cmpp的cancel和query这样的命令。其实
cmpp中的submit有时也会时间比较久的，这样
HD> 通常是和智能网在一起时，即时扣费花费比较久的时间。
HD> :)
HD> 也就是说，在协议上就要考虑好异步，但是在程序中也不可能不出现几秒以上的大
事务处理工作。

HD> uss测试框架是为了解决存储访问部分的测试。它主要体现在文件的清单获取、内
容存取等工作。这部分工作的特点是客户机的数量相对稳定（可能在数
HD> 十台至数千台）。不可能使用udp来做处理的原因就是组包的问题，而tcp更能准确
的了解到通迅的状况。还有就是这数千台机器的并发会很多，但是
HD> 应尽可能的减少并发的连接数，而增强一个连接上的处理能力。

HD> 查询地址是gns的工作，这部分工作我打算使用短连接来做，这样更简单而且更可
行。使用tcp还是udp我想在测试后用事实说话好了。


HD> 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包更适合。因为它不关心连接的状态。




********************************************/

--
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