使用Python开发网络协议 [英] Developing a network protocol with Python
问题描述
你好，
我想开发一个新的网络协议，其中服务器和
客户端是Python程序。
我认为有效，我需要使用TCP_NODELAY，并手动
缓冲传输。
我想创建一个一般的消息传递对象，有类似的方法
sendinteger
recvinteger
senttring
recvstring
为了更安全，我想我可以使用这个加载函数来传递更多精心设计的python结构：
def load（s）：
"""从字符串加载一个对象。
@param s：从中加载对象的字符串。
@return：从字符串加载的对象。这个函数不会
unpickle全局和实例。
""
f = cStringIO.StringIO（s）
p = cPickle.Unpickler（f）
p.find_global =无
返回p.load（）
我是否正确地开发新协议？
程序员是否有任何常见的错误？
是否有一个howto我可以阅读更多关于此的内容？
谢谢
Les
>我是否正确地开发新协议？程序员是否有任何常见的错误？
是否有一个howto我可以阅读更多关于此的内容？
如果你_must_开发自己的协议，至少使用twisted。但是我会在那里找到现有的解决方案 - 即pyro。无需再发明
轮子:)
问候，
Diez
2005年12月12日星期一，Laszlo Zsolt Nagy写道：
我认为要有效，我需要使用TCP_NODELAY，并手动
缓冲转移。
为什么？
我想创建一个通用消息传递对象，其中包含
sendinteger
recvinteger
transmittring
recvstring
好的。所以你真的在开发一个编组层，介于运输和应用程序层之间 - 公平地说，有很多这样做的协议。
为了更安全，
你真的是说安全吗？我不认为使用泡菜会给你
安全。如果您需要安全性，请通过TLS / SSL
连接运行您的协议。
但是，如果您的意思是健壮性，那么这是合理的做 -
它减少了你必须编写的代码量，因此减少了你要编写的错误数量
！不过要注意的一件事是每一端酸洗的
兼容性 - 我不知道
向后兼容的泡菜是什么协议就像，但是你可能会发现，如果他们在不同的python版本上，那么结局
就不会互相理解了。将你自己的协议定义到
套接字级别将排除这种可能性。
我想我可以使用这个加载函数来传递更精细的python <结构：
def load（s）：
"""从字符串加载一个对象。
@param s：加载对象的字符串来自。
@return：从字符串加载的对象。这个函数不会刷新全局变量和实例。
"""
f = cStringIO.StringIO（s）
p = cPickle.Unpickler（f）
p.find_global =无
返回p.load（）
我不知道pickle模块，所以我不能对代码发表评论。
我是否正确地开发新协议？
除了我上面提到的版本控制问题，你应该记住
使用pickle将使得在
除了python之外的任何语言（除非某人已经实现了python
pickle库） - 是否有其他语言的野兽？）。
就个人而言，我会避免这样做，并尝试使用
现有的，语言中立的通用编组层。 XML和ASN.1将是明显的，但我不建议使用其中任何一个，因为它们是可憎的。 JSON将是一个不错的选择：
http：//www.json。 org /
如果它对你的物体有足够的表现力。这是一个非常简单的
格式，并且有一些库用于处理各种各样的
语言。
有没有共同点程序员做的错误？
关键的一点，我会说，不是在考虑未来。确保你的
协议能够增长 - 使用版本号，所以同行可以弄明白他们正在谈论什么语言，或许可以选择谈判
机制，如果你正在做任何复杂的事情来保证它（嘿，你，你可以在没有它的情况下启动
并在以后的版本中添加它！）。尝试
允许添加新命令，消息类型或其他任何内容，以及
扩展现有命令（在合理范围内）。
是有一个howto，我可以在这里阅读更多关于这个？
不是真的 - 协议设计有点像黑色艺术。有人刚才在comp.protocols.tcp-ip上询问了
：
http://groups.google.co.uk/group/com...ca111d67768b83
并没有太多的答案。有人确实指出了这一点，
虽然：
http://www.internet2.edu/~shalunov/w...ol-design.html
虽然我不同意所说的内容。
tom
-
限于元，通用，抽象和哲学的概念 -
IEEE SUO WG
Tom Anderson写道：
我认为要有效，我需要使用TCP_NODELAY，并手动
缓冲传输。
为什么？
由于发送小消息时的大延迟（大小<1500字节）。
就个人而言，我会避免这样做，并尝试使用现有的，语言中立的通用编组层。 XML和ASN.1将是显而易见的，但我不建议使用其中任何一个，因为它们是可憎的。 JSON将是一个不错的选择：
http：//www.json。 org /
我也需要发送Python对象。它们过于精细，无法将它们转换为XML。 （他们使用循环弱引用和其他Python
特定的东西。）我可以肯定，在双方都有Python
程序。如果我已经需要发送
Python对象，那么使用XML有什么优势吗？这些对象不能用XML表示，除非将
腌制成CDATA字符串。
并没有太多的答案。有人确实指出了这一点，
虽然：
http://www.internet2.edu/~shalunov/w...ol-design.html
Hmm ，这非常有帮助。谢谢！
Les
Hello,
I would like to develop a new network protocol, where the server and the
clients are Python programs.
I think to be effective, I need to use TCP_NODELAY, and manually
buffered transfers.
I would like to create a general messaging object that has methods like
sendinteger
recvinteger
sendstring
recvstring
To be more secure, I think I can use this loads function to transfer
more elaborate python stuctures:
def loads(s):
"""Loads an object from a string.
@param s: The string to load the object from.
@return: The object loaded from the string. This function will not
unpickle globals and instances.
"""
f = cStringIO.StringIO(s)
p = cPickle.Unpickler(f)
p.find_global = None
return p.load()
Am I on the right way to develop a new protocol?
Are there any common mistakes that programmers do?
Is there a howto where I can read more about this?
Thanks
Les
> Am I on the right way to develop a new protocol?Are there any common mistakes that programmers do?
Is there a howto where I can read more about this?
If you _must_ develop your own protocol, use at least twisted. But I''d
go for an existing solutions out there - namely pyro. No need to invent
wheels again :)
Regards,
Diez
On Mon, 12 Dec 2005, Laszlo Zsolt Nagy wrote:
I think to be effective, I need to use TCP_NODELAY, and manually
buffered transfers.
Why?
I would like to create a general messaging object that has methods like
sendinteger
recvinteger
sendstring
recvstring
Okay. So you''re really developing a marshalling layer, somewhere between
the transport and application layers - fair enough, there are a lot of
protocols that do that.
To be more secure,
Do you really mean secure? I don''t think using pickle will give you
security. If you want security, run your protocol over an TLS/SSL
connection.
If, however, you mean robustness, then this is a reasonable thing to do -
it reduces the amount of code you have to write, and so reduces the number
of bugs you''ll write! One thing to watch out for, though, is the
compatibility of the pickling at each end - i have no idea what the
backwards- and forwards-compatibility of the pickle protocols is like, but
you might find that if they''re on different python versions, the ends
won''t understand each other. Defining your own protocol down to the
bits-on-the-socket level would preclude that possibility.
I think I can use this loads function to transfer more elaborate python
stuctures:
def loads(s):
"""Loads an object from a string.
@param s: The string to load the object from.
@return: The object loaded from the string. This function will not
unpickle globals and instances.
"""
f = cStringIO.StringIO(s)
p = cPickle.Unpickler(f)
p.find_global = None
return p.load()
I don''t know the pickle module, so i can''t comment on the code.
Am I on the right way to develop a new protocol?
Aside from the versioning issue i mention above, you should bear in mind
that using pickle will make it insanely hard to implement this protocol in
any language other than python (unless someone''s implemented a python
pickle library in it - is there such a beast for any other language?).
Personally, i''d steer clear of doing it like this, and try to use an
existing, language-neutral generic marshalling layer. XML and ASN.1 would
be the obvious ones, but i wouldn''t advise using either of them, as
they''re abominations. JSON would be a good choice:
http://www.json.org/
If it''s expressive enough for your objects. This is a stunningly simple
format, and there are libraries for working with it for a wide range of
languages.
Are there any common mistakes that programmers do?
The key one, i''d say, is not thinking about the future. Make sure your
protocol is able to grow - use a version number, so peers can figure out
what language they''re talking, and perhaps an option negotiation
mechanism, if you''re doing anything complex enough to warrant it (hey, you
could always start without it and add it in a later version!). Try to
allow for addition of new commands, message types or whatever, and for
extension of existing ones (within reason).
Is there a howto where I can read more about this?
Not really - protocol design is a bit of a black art. Someone asked about
this on comp.protocols.tcp-ip a while ago:
http://groups.google.co.uk/group/com...ca111d67768b83
And didn''t get much in the way of answers. Someone did point to this,
though:
http://www.internet2.edu/~shalunov/w...ol-design.html
Although i don''t agree with much of what that says.
tom
--
limited to concepts that are meta, generic, abstract and philosophical --
IEEE SUO WG
Tom Anderson wrote:
I think to be effective, I need to use TCP_NODELAY, and manually
buffered transfers.
Why?
Because of the big delays when sending small messages (size < 1500 bytes).
Personally, i''d steer clear of doing it like this, and try to use an
existing, language-neutral generic marshalling layer. XML and ASN.1 would
be the obvious ones, but i wouldn''t advise using either of them, as
they''re abominations. JSON would be a good choice:
http://www.json.org/
I need to send Python objects too. They are too elaborate to convert
them to XML. (They are using cyclic weak references and other Python
specific stuff.) I can be sure that on both sides, there are Python
programs. Is there any advantage in using XML if I already need to send
Python objects? Those objects cannot be represented in XML, unless
pickled into a CDATA string.
And didn''t get much in the way of answers. Someone did point to this,
though:
http://www.internet2.edu/~shalunov/w...ol-design.html
Hmm, this was very helpful. Thank you!
Les
这篇关于使用Python开发网络协议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
