我是新来的扭曲，我在弄清楚如何组织我的代码时遇到了麻烦。客户端连接到TCP（SSL）控制通道，然后将尝试连接到UDP上的相同IP：端口，以获得基于TCP提供的加密设置的低延迟数据通道。如果不能，则TCP控制信道将用于数据。我想编写一个可重用的客户端，以便人们可以使用诸如dataReceived，controlMessageXReceived，sendControlMessageX，sendDataMessage等函数覆盖一个类，以及UDP通道是否正在使用或不抽象到我的代码中。
我目前有一个可以理解TCP控制通道的协议;出于测试目的，我已经覆盖ConnectionMade（）那里发送设置消息并确认一切正常（它可以理解服务器，反之亦然）但我不知道如何将它集成到更广泛的上下文中。
（对于好奇，这是Mumble的客户端 - 此协议规范是here，我正在尝试更新this可怕的无法维护（多线程）代码变成现代的东西）
答案 0 :(得分：1)
考虑镜像已存在于Twisted中的协议/传输分离。
Protocol对TCP一无所知。它只知道如何处理字节流。它是了解TCP（或TLS，或UNIX套接字或其他东西）的传输。
Protocol与其传输之间存在明确的接口（实际上，有两个 - IProtocol让传输知道它可以对协议对象做什么，ITransport让协议知道它能对传输对象做些什么。）
创建一个对您正在使用的应用程序有意义的界面。例如，Protocol有dataReceived因为＆＃34;某些字节到达＆＃34;是＆＃34;字节流＆＃34;发生的事情之一。 Mumble会发生什么事？例如，这些东西可能是，＆＃34;用户连接到服务器＆＃34;或者＆＃34;消息到达您所在的频道＆＃34;。您的界面可能有针对每种方法的方法。
现在，应用程序开发人员可以通过编写此接口的实现（明确且完全定义）来实现他们自己的新行为，然后将该实现插入到您的库中（例如，您的库可能提供connectToMumbleServer(address, mumbleApplicationObject) API）。
您的库确切地知道它允许对应用程序对象做什么，因为接口是明确定义的。如果你以相反的方向重复这个过程，那么应用程序开发人员也会知道他们可以使用你的库对mumble服务器做些什么（例如＆＃34;加入一个频道＆＃34;或者＆＃34;发送一个音频包数据＆＃34;。）
你可以为子类的应用程序提供基类（如Protocol），但这是一个非常简单的方便。如果您最近没有，请打开twisted/internet/protocols.py并查看Protocol课程的实施情况。那里几乎没有任何东西，没有什么是非常复杂或难以复制的。如果应用程序开发人员不得不开始子类化object并自行键入所有方法，那么他们就不会处于劣势。