呵呵，在smpp中就是变长的字段，但是变长字段一定会有一个size的。作法就是将前面的解完，然后读长度，取出来再unpack不就成了。
还有就是现在pack和unpack都是自己可以随意写的，哪么就看你是不是想写成一个通用的写法了。

On Tue, 3 Aug 2004 09:43:13 +0800, info at xichen.com <info at xichen.com> wrote:
> HD,您好！
> 
>         请教一个问题，我看到你写的解包过程都是定长字段的，如果有变长字段怎么处理呢？如果有两个变长字段呢？能不能给个实际的例子？谢谢了。
> 
> ======= 2004-08-03 08:00:36 您在来信中写道：=======
> 
> >服务器已经到位，今天我会setup相关的东东，最先把mail list搞起来，解决很多人收不到信的问题。
> >
> >短连接程序在昨天睡觉前基本完成，今天会仔细试试，没有问题就会发布出来。
> >
> >测试环境已经搭建好了，我打算使用600个用户并发连接测试短连接服务器的处理能力。
> >--
> >HD（燃烧中的火）
> >我工作我快乐，我勤奋我收获。请与我一起快乐，与我一起收获。
> >_______________________________________________
> >python-chinese list
> >python-chinese at lists.python.cn
> >http://python.cn/mailman/listinfo/python-chinese
> >
> 
> = = = = = = = = = = = = = = = = = = = =
> 
> 致
> 礼！
> 
> info
> info at xichen.com
> 2004-08-03
> 
> 
> 
> 


-- 
HD（燃烧中的火）
我工作我快乐，我勤奋我收获。请与我一起快乐，与我一起收获。

HD,您好！

	谢谢了。

======= 2004-08-03 09:45:19 您在来信中写道：=======

>呵呵，在smpp中就是变长的字段，但是变长字段一定会有一个size的。作法就是将前面的解完，然后读长度，取出来再unpack不就成了。
>还有就是现在pack和unpack都是自己可以随意写的，哪么就看你是不是想写成一个通用的写法了。
>
>On Tue, 3 Aug 2004 09:43:13 +0800, info at xichen.com <info at xichen.com> wrote:
>> HD,您好！
>> 
>>         请教一个问题，我看到你写的解包过程都是定长字段的，如果有变长字段怎么处理呢？如果有两个变长字段呢？能不能给个实际的例子？谢谢了。
>> 
>> ======= 2004-08-03 08:00:36 您在来信中写道：=======
>> 
>> >服务器已经到位，今天我会setup相关的东东，最先把mail list搞起来，解决很多人收不到信的问题。
>> >
>> >短连接程序在昨天睡觉前基本完成，今天会仔细试试，没有问题就会发布出来。
>> >
>> >测试环境已经搭建好了，我打算使用600个用户并发连接测试短连接服务器的处理能力。
>> >--
>> >HD（燃烧中的火）
>> >我工作我快乐，我勤奋我收获。请与我一起快乐，与我一起收获。
>> >_______________________________________________
>> >python-chinese list
>> >python-chinese at lists.python.cn
>> >http://python.cn/mailman/listinfo/python-chinese
>> >
>> 
>> = = = = = = = = = = = = = = = = = = = =
>> 
>> 致
>> 礼！
>> 
>> info
>> info at xichen.com
>> 2004-08-03
>> 
>> 
>> 
>> 
>
>
>-- 
>HD（燃烧中的火）
>我工作我快乐，我勤奋我收获。请与我一起快乐，与我一起收获。
>_______________________________________________
>python-chinese list
>python-chinese at lists.python.cn
>http://python.cn/mailman/listinfo/python-chinese
>

= = = = = = = = = = = = = = = = = = = =
			

　　　　　　　　致
礼！
 
				 
　　　　　　　　info
　　　　　　　　info at xichen.com
　　　　　　　　　　2004-08-03

Zoom.Quiet,您好！

	我的意思是用来讨论的效果，与maillist差不多，一样可能会很乱的。

======= 2004-08-03 09:05:35 您在来信中写道：=======

>Hollo limodou:
>
>  newsgroup 需要专门的协议支持！
>不象mailist 仅仅是自动的群发邮件而已！
>
>
>/******** [2004-08-03]09:05:03 ; limodou wrote:
>
>limodou> hoxide,您好！
>
>limodou> 	news与maillist有多大的区别？我看差不多。
>
>limodou> ======= 2004-08-02 17:26:02 您在来信中写道：=======
>
>>>Zoom.Quiet,您好！
>>>
>>>	偶们可以到newsfans新闻组讨论阿,我发了开版申请,但那里的老大说,暂时先到perl组,以后他们确认人多了再单独开一个.
>>>
>>>======= 2004-08-02 16:41:33 您在来信中写道：=======
>>>
>>>>Hollo info:
>>>>
>>>>  大家都感觉现在的
>>>> 列表，知识的查询非常困难，那未，将讨论出来的有效知识固定下来，成为文章，为后来者作个准备，实为一大德政是也乎！
>>>>请关注
>>>>http://220.248.2.35:7080/moin/RecentChanges
>>>>Wiki 更新记录
>>>>
>>>>今天在 PyUSS 页面组织了:
>>>>
>>>>基准代码/benchmarks 
>>>>-- 测试平台; 演化,UML设计等等 
>>>>
>>>>相关知识
>>>>收集整理开发过程中大家发现,使用,迷惑的知识点,包括基础的东西是也乎 
>>>>
>>>> FAQnetwork -- TCP/IP;UCP...... 
>>>> PyThread -- 线程编程 
>>>> PyOptimize -- Python 代码优化经验收集! 
>>>>
>>>>请同志们继续学习，共享经验！
>>>>
>>>>/******** [2004-08-02]16:30:37 ; info wrote:
>>>>
>>>>info at xichen.com> limodou,您好！
>>>>
>>>>info at xichen.com>
>>>>	用twisted写的服务器端本身就处理的多线程，这个大家可以用我们做测试的例子来试。
>>>>info at xichen.com>    
>>>>info at xichen.com>
>>>>对于客户端来讲，除非是传输文件本身，没有必要采用多线程。
>>>>info at xichen.com>    
>>>>info at xichen.com>
>>>>我的意见是，达到本期的产品基线，然后用最稳定、最简洁的方式来实现。
>>>>
>>>>info at xichen.com> ======= 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 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
>>>
>>>= = = = = = = = = = = = = = = = = = = =
>>>			
>>>
>>>　　　　　　　　致
>>>礼！
>>> 
>>>				 
>>>　　　　　　　　hoxide
>>>　　　　　　　　hoxide_dirac at yahoo.com.cn
>>>　　　　　　　　　　2004-08-02
>>>
>>>_______________________________________________
>>>python-chinese list
>>>python-chinese at lists.python.cn
>>>http://python.cn/mailman/listinfo/python-chinese
>>>
>
>limodou> = = = = = = = = = = = = = = = = = = = =
>			
>
>limodou> 　　　　　　　　致
>limodou> 礼！
> 
>				 
>limodou> 　　　　　　　　limodou
>limodou> 　　　　　　　　chatme at 263.net
>limodou> 　　　　　　　　　　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
>

= = = = = = = = = = = = = = = = = = = =
			

　　　　　　　　致
礼！
 
				 
　　　　　　　　limodou
　　　　　　　　chatme at 263.net
　　　　　　　　　　2004-08-03

On 2004-08-03 09:45:1091497519 +0800, HD wrote:
> 呵呵，在smpp中就是变长的字段，但是变长字段一定会有一个size的。作法就是将前面的解完，然后读长度，取出来再unpack不就成了。
> 还有就是现在pack和unpack都是自己可以随意写的，哪么就看你是不是想写成一个通用的写法了。

我们的协议不必非设计成 bin 的数据包吧，用纯文本的不成吗？也方便人
调测。

呵呵，文本的解析太麻烦，不如bin用着爽 :)
其实8个字节就解决了文本情况下的命令识别、换行符和间隔符的问题，不是很爽的事吗？

On Tue, 3 Aug 2004 10:06:27 +0800, Xie Yanbo <idkey at 163.com> wrote:
> On 2004-08-03 09:45:1091497519 +0800, HD wrote:
> > 呵呵，在smpp中就是变长的字段，但是变长字段一定会有一个size的。作法就是将前面的解完，然后读长度，取出来再unpack不就成了。
> > 还有就是现在pack和unpack都是自己可以随意写的，哪么就看你是不是想写成一个通用的写法了。
> 
> 我们的协议不必非设计成 bin 的数据包吧，用纯文本的不成吗？也方便人
> 调测。
> 
> 
> 
> _______________________________________________
> python-chinese list
> python-chinese at lists.python.cn
> http://python.cn/mailman/listinfo/python-chinese
> 


-- 
HD（燃烧中的火）
我工作我快乐，我勤奋我收获。请与我一起快乐，与我一起收获。

Hollo HD:

  嘿嘿嘿！在下倾向于直接使用Python pickle模块，
将信息元组,或是其它数据，操作对象生成字节串进行传送，反正都是Python 程序，直接就可以解析为标准的Python 对象进行使用！

可行否？效率上？？


/******** [2004-08-03]10:13:51 ; HD wrote:

HD> 呵呵，文本的解析太麻烦，不如bin用着爽 :)
HD> 其实8个字节就解决了文本情况下的命令识别、换行符和间隔符的问题，不是很爽的事吗？

HD> On Tue, 3 Aug 2004 10:06:27 +0800, Xie Yanbo <idkey at 163.com> wrote:
>> On 2004-08-03 09:45:1091497519 +0800, HD wrote:
>> >
>> 呵呵，在smpp中就是变长的字段，但是变长字段一定会有一个size的。作法就是将前面的解完，然后读长度，取出来再unpack不就成了。
>> >
>> 还有就是现在pack和unpack都是自己可以随意写的，哪么就看你是不是想写成一个通用的写法了。
>> 
>> 我们的协议不必非设计成 bin 的数据包吧，用纯文本的不成吗？也方便人
>> 调测。
>> 
>> 
>> 
>> _______________________________________________
>> python-chinese list
>> python-chinese at lists.python.cn
>> http://python.cn/mailman/listinfo/python-chinese
>> 




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

-- 
Free as in Freedom

 Zoom.Quiet                           

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

sender is the Bat!2.12.00

On 2004-08-03 10:10:1091499024 +0800, HD wrote:
> 呵呵，文本的解析太麻烦，不如bin用着爽 :)
> 其实8个字节就解决了文本情况下的命令识别、换行符和间隔符的问题，不是很爽的事吗？

各有各的优点。如果数据包以后不会有什么变动，也不会有各种复杂的
变长包，bin 是不错的选择；文本格式的优点是易读、易扩展，也应该
适当考虑它的必要性。

On 2004-08-03 10:22:1091499774 +0800, Zoom.Quiet wrote:
> Hollo HD:
> 
>   嘿嘿嘿！在下倾向于直接使用Python pickle模块，
> 将信息元组,或是其它数据，操作对象生成字节串进行传送，反正都是Python 程序，直接就可以解析为标准的Python 对象进行使用！
> 
> 可行否？效率上？？

这样协议就只能使用 Python 来实现了，而且 Python 并不许诺 pickle
模块的稳定性，它的实现在不同的 Python 里可能并不相同，甚至可能
不会兼容。这把整个协议都绑定在 Python pickle 上了，不好。