实现TCP框架的正确模式是什么?它是一个过滤器堆栈吗?

时间:2012-07-03 12:01:34

标签: c# .net tcp

我正在尝试实现一个强大的TCP库,它允许用户选择一个应用程序协议或实现他们自己的,并简单地“插入”到客户端/服务器。

通过协议我的意思是简单地定义如何将流构成消息的能力。

我正在为堆栈的其余部分使用内置的异步TCP库,并开发了一个客户端,无论何时建立连接,读取或写入数据或引发异常,都会引发事件。

我有两种实现成帧协议的选择。第一个已经工作的是扩展客户端类并覆盖接收的数据事件,这样只有在收到完整消息时才会引发此事件。 (即在引擎盖下,我缓冲来自套接字的原始数据,并根据协议决定何时有完整的消息,然后才提出数据接收事件。)这类似于Nito.Asynch库的工作方式。 / p>

这种方法的问题在于它意味着每个新协议都需要新的客户端实现。我更希望客户端维护一个可以添加或删除的内部过滤器堆栈。

当在套接字上接收到数据时,它将被传递给第一个缓冲区,该缓冲区将一直缓存,直到它决定传递一个已删除标题或元数据的完整消息。然后将其传递给堆栈等中的下一个过滤器。

这样,可以独立于库定义/开发过滤器,并根据配置(在运行时)将过程注入到客户端。

为了实现这一点,我考虑将过滤器定义为由客户端内部保存的System.IO.Stream(传入和传出)的实现对。

从套接字读取的数据将写入堆栈的底部传入流。然后,从该流读取的数据将被写入下一个流等,直到最后一个流(堆栈顶部)返回数据,然后由客户端返回。 (我的计划是使用Stream的CopyTo()函数。

写入客户端的数据将写入顶部传出Stream并向下复制到堆栈,直到底部传出Stream写入底层套接字。

显然有很多需要考虑的因素,我正试图让我的头脑正确地表现为Stream对象。 示例:当有人调用Flush()时,我该怎么办??

这是实现这一目标的好方法还是我在这里重新发明轮子?

Nito.Asynch图书馆

1 个答案:

答案 0 :(得分:1)

我正在回答我自己的问题,希望我的解决方案能得到一些好评,并可能帮助别人。

我为协议过滤器和数据框定义了两个接口。 (为了清楚术语,我避免使用“数据包”一词,以避免与低级协议中定义的数据包混淆。)

虽然不是我自己的意图,但我想这可以在任何传输协议(即命名管道,TCP,串行)之上使用。

首先是数据框的定义。这包括“数据”(有效载荷)以及将数据作为原子“消息”传输的任何字节。

/// <summary>
/// A packet of data with some form of meta data which frames the payload for transport in via a stream.
/// </summary>
public interface IFramedData
{
    /// <summary>
    /// Get the data payload from the framed data (excluding any bytes that are used to frame the data)
    /// i.e. The received data minus protocl specific framing
    /// </summary>
    public readonly byte[] Data { get; }

    /// <summary>
    /// Get the framed data (payload including framing bytes) ready to send
    /// </summary>
    /// <returns>Framed data</returns>
    public byte[] ToBytes();
}

然后有协议过滤器从某个源(例如TCP套接字或甚至是堆栈中使用的另一个过滤器)读取数据并将数据写回。

过滤器应读取数据(包括框架)并为每个完整的帧读取引发DataReceived事件。通过IFramedData实例的“Data”属性访问有效负载。

当数据写入过滤器时,它应该适当地“框架”它,然后在每次完整的数据帧准备发送时引发DataToSend事件。 (在我的情况下,这将是立即的,但我试图允许一个协议,可能会发送一个固定长度的消息或缓冲输入由于某些其他原因,然后返回一个完整的帧准备发送。

/// <summary>
/// A protocol filter can be used to read and write data from/to a Stream and frame/deframe the messages.
/// </summary>
/// <typeparam name="TFramedData">The data frame that is handled by this filter</typeparam>
public interface IProtocolFilter<TFramedData> where TFramedData : IFramedData
{
    /// <summary>
    /// Should be raised whenever a complete data frame is ready to send.
    /// </summary>
    /// <remarks>
    /// May be raised after a call to <see cref="FlushSend()"/>
    /// </remarks>
    public event Action<TFramedData> DataToSend;

    /// <summary>
    /// Should be raised whenever a complete data frame has been received.
    /// </summary>
    /// <remarks>
    /// May be raised after a call to <see cref="FlushReceive()"/>
    /// </remarks>
    public event Action<TFramedData> DataReceived;

    /// <summary>
    /// Should be raised if any data written or read breaks the protocol.
    /// This could be due to any asynchronous operation that cannot be raised by the calling function.
    /// </summary>
    /// <remarks>
    /// Behaviour may be protocol specific such as flushing the read or write cache or even resetting the connection.
    /// </remarks>
    public event Action<Exception> ProtocolException;

    /// <summary>
    /// Read data into the recieve buffer
    /// </summary>
    /// <remarks>
    /// This may raise the DataReceived event (possibly more than once if multiple complete frames are read)
    /// </remarks>
    /// <param name="buffer">Data buffer</param>
    /// <param name="offset">Position within the buffer where data must start being read.</param>
    /// <param name="count">Number of bytes to read.</param>
    /// <returns></returns>
    public int Read(byte[] buffer, int offset, int count);

    /// <summary>
    /// Write data to the send buffer.
    /// </summary>
    /// <remarks>
    /// This may raise the DataToSend event (possibly more than once if the protocl requires the data is broken into multiple frames)
    /// </remarks>
    /// <param name="buffer">Data buffer</param>
    /// <param name="offset">Position within the buffer where data must start being read.</param>
    /// <param name="count">Number of bytes to read from the buffer</param>
    public void Write(byte[] buffer, int offset, int count);

    /// <summary>
    /// Flush any data from the receive buffer and if appropriate, raise a DataReceived event.
    /// </summary>
    public void FlushReceive();

    /// <summary>
    /// Flush any data from the send buffer and if appropriate, raise a DataToSend event.
    /// </summary>
    public void FlushSend();
}

然后我在TcpClient周围编写了一个非常简单的包装器,只要协议栈顶部的过滤器引发DataReceived事件或者底部的过滤器引发DataToSend事件,它就会执行asynch读取和写入并引发事件(我也写了)数据到套接字,但这允许应用程序监视它写入客户端的数据何时实际发送。