问题标签 [fast-protocol]

Python 中是否有一个很好的包装器来使用FAST协议来解包来自流线的数据。Java (OpenFAST) 中有一个实现，但它存在一些无法使用的性能问题。

谢谢。

我与几位程序员交谈过，他们说编写基本引擎来编码/解码修复/快速消息非常容易，大约需要 3 天的修复工作和一周的快速工作。我正在寻找类似的东西。

QuickFix 看起来相当大而且有点“慢”和复杂的项目，我猜它包含很多我不需要的功能（但它们可能会影响性能）

到目前为止，我只需要通过多播 udp 接收来自快速修复的报价，并在缺少某些报价时恢复。

所以我正在寻找只提供一般功能的开源引擎，基本上是编码/解码快速/修复消息。你有什么建议？

我确实需要：

• 简单
• 速度

我不需要

• 特征

我不需要完整的即用型解决方案。我想要一些有用的简单快速的东西，我可以自己编写其余的代码。

像 FAST 这样的数据编码协议非常巧妙地减少了需要发送的数据量。基本上一个得到一个 char*，将前几个字节作为整数读取会给你一个 id 号，它指向你如何解码其余字节的指令（即它告诉你其余的字节是，例如，reverseivley an int，一个字符串、一个无符号整数、另一个无符号整数、一个嵌套消息等）和接下来的几个字节（在每一位中）告诉你后续字段是否存在。每个字节中的第 8 位保留用于表示数据之间的边界。

如果没有位操作（ands、ors、移位、位检查）的线性遍历，解码这样的协议似乎是不可能的……有没有办法更快地做到这一点？

我需要为FAST协议实施提要仲裁。问题很常见，甚至有硬件解决方案由于问题广为人知，我确实认为至少应该有关于如何实现该问题的一般建议（我应该使用多少查询，多少环形缓冲区，多少读者，何时丢弃数据包等），可能有人可以指出我的一些实现。对于那些不熟悉 FAST 的人，我添加一些描述：

所有 UDP 源中的数据都在两个不同的多播 IP 上的两个相同的源（A 和 B）中传播。强烈建议客户端接收并处理这两个提要，因为可能会丢失 UDP 数据包。处理两个相同的提要允许一个在统计上降低丢包的概率。未指定消息首次出现在哪个特定提要（A 或 B）中。要仲裁这些提要，应该使用在 Preamble 或标签 34-MsgSeqNum 中找到的消息序列号。Preamble 的使用允许在不解码 FAST 消息的情况下确定消息序列号。应使用以下算法处理来自提要 A 和 B 的消息：

1. 收听提要 A 和 B
2. 根据消息的序号处理消息。

3. 如果之前已经处理过具有相同序列号的消息，则忽略该消息。

   // tcp 恢复算法进一步

所以我认为解决方案应该是这样的：

1. 为两个提要中的每一个创建专用线程和专用缓冲区。数据到达时将数据添加到缓冲区。（应该是环形缓冲区还是队列还是什么？）

2. 创建“旋转”的“阅读器”并检查两个线程是否有最后一个可用的“序列号”。一旦“序列号”可用，就需要处理下一个数据包，并且两个线程都应该在此之后丢弃它。

欢迎任何关于如何实现算法本身的建议以及可能使用哪些结构的建议。特别是可能有人可以建议无锁队列/环形缓冲区实现。

我对 FAST 消息中的序列有一些问题
例如，我有下一个模板 xml

起初我得到我们模板的 PMap，下一步我得到模板 id，然后我一个一个地读取字节并且一切正常，但是如果我得到序列“MDEntries”，我的数据将不正确，因为字节序列将被破坏。

我看到下一张带有 FAST Message 结构的图片，并认为我应该读取序列和长度为 'NoMDEntries' 的 PMap，然后一个接一个地读取字节，是否正确？我曾经认为我应该一个一个地读取字节并删除停止位

帮帮我，我如何正确解析“序列”

我正在尝试在我的 Windows 机器上将 mFast 用于 FastFix 协议，但无法使用 cmake-gui.exe 安装我在 Windows Server 2003 上使用 Visual Studio 2010。

带有配置的 cmake-gui tool.exe 映像

CMAKE-LISTS.txt

错误日志文件

我尝试了什么：添加了可执行路径和库安装了 Boost-library 1.63 并添加到了路径中，但没有发现任何运气，因为你可以看到我收到静态库文件错误。提前致谢

当我打电话时

它在扔

它是一个库头文件。当我对字符串进行硬编码并将其传递给解码时不会出现这种情况，但是当我通过将数据编码为 UTF-8 来传递数据时会失败。

我从交易所得到的数据是

"Ýÿ”20181009-06:49:09.66±±jÏ€€€‚_À€ôCOCUDAKL20DEC201¸2972³ø2?IÁ€€€€€€€s•€€€€€€€€€€“ö€‚ "

使用 C++/CLI 将其转换为 UTF-8

好像我fast_message在声明中硬编码它可以工作，但当我执行不同的操作或在调试时我得到的值与硬编码它相同。

任何建议为什么它会下溢。