我是twisted的新手,我很难想出如何组织代码。客户机连接到一个TCP(SSL)控制通道,然后根据TCP上提供的加密设置,尝试连接到UDP上的同一个IP:port以获得低延迟数据通道。如果不能,将使用TCP控制通道来传输数据。我想编写一个可重用的客户机,这样人们就可以用dataReceived、controlMessageXReceived、sendControlMessageX、sendDataMessage等函数重写类,不管UDP通道是否正在使用中,都可以抽象到我的代码中。在
我目前有一个可以理解TCP控制通道的协议;出于测试目的,我在那里重写了ConnectionMade(),以发送设置消息并确认一切正常(它可以理解服务器,反之亦然),但我不知道如何将其集成到更广的上下文中。在
(出于好奇,这是Mumble的客户机-此协议规范是here,我正在尝试将this可怕的umainable(多线程)代码更新为现代的)
考虑镜像Twisted中已经存在的协议/传输分离。在
Protocol
对TCP一无所知。它只知道如何处理字节流。传输知道TCP(或TLS、UNIX套接字或其他东西)。在在
Protocol
及其传输之间有一个显式接口(实际上,有两个接口-IProtocol
让传输知道它可以对协议对象做什么,ITransport
让协议知道它可以对传输对象做些什么)。在发明一个对你正在使用的应用程序有意义的接口。例如,},因为“一些字节到达”是“字节流”发生的事情之一。在咕哝中会发生什么事?例如,这些内容可能是“连接到服务器的用户”或“到达您所在频道的消息”。你的接口可能有一个方法来处理这些问题。在
Protocol
有{现在,应用程序开发人员可以通过编写这个接口的一个实现来实现他们自己的新行为——这个接口是明确和完整定义的——然后将这个实现插入到你的库中(例如,也许你的库可以提供一个
connectToMumbleServer(address, mumbleApplicationObject)
API)。在因为接口是显式定义的,所以库确切地知道它可以对应用程序对象做什么。如果您以相反的方向重复这个过程,那么应用程序开发人员也将知道他们可以使用您的库对mumble服务器做什么(例如“加入一个频道”或“发送一个音频数据包”)。在
您可以为应用程序提供一个基类(如
Protocol
)作为子类,但这只是一个非常小的方便。如果您最近还没有,请打开twisted/internet/protocols.py
并查看Protocol
类的实现。那里几乎什么都没有,也没有什么是非常复杂或难以复制的。如果应用程序开发人员必须从子类化object
开始,并自己键入所有方法,那么他们不会处于很大的劣势。在相关问题 更多 >
编程相关推荐