在服务器和客户端之间以扭曲方式发送数据
我正在尝试在使用twisted 实现的服务器和客户端之间传输数据。据我所知,仅当 data 是字符串时,使用 self.transport.write([data]) 才有效。有没有其他方法可以发送其他类型的对象?谢谢你!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
套接字携带字节。这是他们唯一携带的东西。 TCP 连接的任何两个端点只能互相传送字节。
字节并不是对于每种形式的通信来说最有用的数据结构。因此,在字节传输之上,我们发明了格式化和解释字节的方案。这些是协议。
Twisted 将协议表示为类,几乎总是
twisted.internet.protocol.Protocol
的子类,它们实现了特定的方案。这些类具有将非纯字节的内容转换为纯字节的方法。例如,
twisted.protocols.basic.NetstringReceiver
是netstring的实现协议。它将特定数量的字节转换为代表字节数和字节本身的字节。这是一个相当微妙的协议,因为字节计数也是需要传达的信息并不是立即显而易见的。这些类还根据它们实现的协议,在其 dataReceived 方法中解释从网络接收的字节,并将结果信息转换为更结构化的信息。
NetstringReceiver
使用长度信息从网络接收正确数量的字节,然后将它们作为单个 Pythonstr
传递到其stringReceived
回调实例。其他协议的功能远不止
NetstringReceiver
。例如,twisted.protocols.ftp 包含 FTP 协议的实现。 FTP 是一种旨在通过套接字(或实际上是多个套接字)传递文件列表和文件的协议。twisted.mail.pop3
实现 POP3,一种通过套接字传输电子邮件的协议。有很多很多不同的协议,因为您可能想做很多很多不同的事情。根据您想要执行的操作,可能有不同的方法来转换字节或从字节转换,以使事情变得更容易、更快或更强大(等等)。因此,不存在适合一般情况的单一协议。这包括“发送对象”的情况,因为对象可以采取许多不同的形式,并且您可能有许多不同的原因想要发送它们,并且您可能需要许多不同的方式来处理诸如对象突变之类的事情之前发送过,等等。
您可能需要花一点时间思考您需要什么样的沟通。这应该会建议您选择用于进行通信的协议的某些信息。
例如,如果您希望能够调用连接另一端存在的 Python 对象的方法,则 Twisted Spread 可能会很有趣。
如果您想要跨语言的东西,并且只需要传达简单的类型,如整数、字符串和列表,那么 XML- RPC(Twisted How-To)可能更好合身。
如果您需要一个比 XML-RPC 更节省空间并支持更复杂类型的序列化的协议,那么 AMP 可能更合适。
这样的例子还在继续。 :)
Sockets carry bytes. That's the only kind of thing they carry. Any two endpoints of a TCP connection can only convey bytes to each other.
Bytes aren't the most useful data structure for every form of communication. So on top of this byte transport, we invent schemes for formatting and interpreting bytes. These are protocols.
Twisted represents protocols as classes, almsot always subclasses of
twisted.internet.protocol.Protocol
, which implement a particular scheme.These classes have methods for turning something which isn't pure bytes into something which is pure bytes. For example,
twisted.protocols.basic.NetstringReceiver
is an implementation of the netstring protocol. It turns a particular number of bytes into bytes which represent both the number of bytes and the bytes themselves. This is a rather subtle protocol, since it's not instantly obvious that the byte count is information that needs to be conveyed as well.These classes also interpret bytes received from the network, in their
dataReceived
method, according to the protocol they implement, and turn the resulting information into something more structured.NetstringReceiver
uses the length information to accept exactly the right number of bytes from the network and then deliver them to itsstringReceived
callback as a single Pythonstr
instance.Other protocols do more than
NetstringReceiver
. For example,twisted.protocols.ftp
includes an implementation of the FTP protocol. FTP is a protocol geared towards passing file listings and files over a socket (or several sockets, actually).twisted.mail.pop3
implements POP3, a protocol for transferring email over sockets.There are lots and lots of different protocols because there are lots and lots of different things you might want to do. Depending on exactly what you're trying to do, there are probably different ways to convert to and from bytes to make things easier or faster or more robust (and so on). So there's no single protocol that is ideal for the general case. That includes the case of "sending an object", since objects can take many different forms, and there may be many different reasons you want to send them, and many different ways you might want to handle things like mutation of an object you'd previously sent, and so on.
You probably want to spend a little time thinking about what kind of communication you need. This should suggest certain things about the protocol you'll select to do the communication.
For example, if you want to be able to call methods on Python objects that exist on the other side of a connection, then Twisted Spread might be interesting.
If you want something cross-language instead, and only need to convey simple types, like integers, strings, and lists, then XML-RPC (Twisted How-To) might be a better fit.
If you need a protocol that's more space efficient than XML-RPC and supports serialization of more complicated types, then AMP might be more appropriate.
And the list goes on. :)