2

所以，我一直在阅读有关自动（加密）交易的信息，我想让我们试一试。我已经能够为 Poloniex 交易所做一个简单的交易者。

我的想法是连续进行多笔交易，这样当第一笔交易完成时，它会发出开始第二笔交易的信号，依此类推。

买入/卖出交易通过该HTTPS POST方法发送到 Poloniex API。

我希望几个连续交易的时间跨度最小。但是，我注意到使用 npm 请求包时，单个购买/出售请求大约需要500 [ms]（有时甚至超过一秒）。

现在我想知道是否有更快的方法来发送这些HTTPS POST请求，这样在第二次连续请求时价格改变的可能性很小。

我目前的方法如下：

            //   create timestamp and encrypt secret
            //                              + message
            //   with current timestamp using Hmac
            timeStamp = Math.floor(Date.now());
            sign = ...

            var headers = {
                'Key':    key,
                'Sign':   sign
            };

            // make first trade
            request.post({
                'headers': headers,
                'url':    'https://poloniex.com/tradingApi',
                'form':    ... 
            }, function (error, response, body) {
                // go on to second trade if previous finished correctly
                if (!error)
                {
                    // use same procedure again for encryption
                    timeStamp = Math.floor(Date.now());
                    sign      = ... 

                    headers = {
                        'Key':    key,
                        'Sign':   sign
                    };

                    request.post({
                        'headers': headers,
                        'url':    'https://poloniex.com/tradingApi',
                        'form':    ...
                    }, function (error, response, body) {
                        if (!error)
                        {
                         // same pattern for the third one
4

1 回答 1

0

为加速 SSL 加密/解密阶段（下面的步骤 [3]）购买一台稍微好一点的计算机（参考下文）的建议，另外说明，500 [ms] 中的大部分可能只是响应时间您要发送到的服务器。”是（恕我直言）完全错误且具有严重误导性的陈述。

（引用，重点补充）：

“...... 有可能稍微快一点的计算机可能会更快地为初始连接执行 SSL 连接计算，但这只是一个猜测。仅供参考，您不必等待一个事务完成才能开始下一个事务。您可以一次启动多个事务，看看它们什么时候完成。然后它们都将同时“飞行”。您注意到的 500 毫秒延迟可能主要只是您发送到的服务器的响应时间。- jfriend00 10 小时前 "

（哎呀，我仍然在这里看到的这条评论，在屏幕上，由 jfriend00 签名，日期......现在似乎被作者删除了，而不是明确地解决下面要求的澄清多少 [ms] 确实会得到剃光头，因为她/他建议对 O/P 使用稍快的计算机）[2017-10-27 09:15:37Z]

好吧，这是选择直接错误工具的典型结果......

在此处输入图像描述

仔细阅读实际e2e.RTT数据，
以及它们的差异（比 L3 网络交付阶段的常见延迟噪声大两个数量级），

只有
一起观察才能真正反映真实世界的端到端所有 XTO 指令中最简单的确认的往返时间，不需要任何额外的 [风险管理] 或 API 提供者 BackOffice/NDD/ECN 端的其他后处理

也可以看到
API 提供者丢失了多少丢失的答案——发送BEEP[7238]与接收刚刚准备好处理甚至丢失的 API 调用？LAST[7206]

在外汇市场技术领域工作了几十年（少数> 3），我觉得我可以说出以下几点：

  • 市场准入提供商（您都可以说出他们的名字）决定向公众出售/提供 API
  • 他们的 CIO + COO 决定将 + 轻量级加密服务包装到HTTPS-envelopes 中
  • 您的应用程序只需满足 API-Finite-State-Machine 的逻辑，包括。他们选择将所有东西重新包装进/出 -HTTPS信封。

这个怎么运作：

  1. 您的应用逻辑可能会决定[NOW]向交易引擎发送一些 XTO 指令

  2. 此时，你的应用程序必须执行 XTO 指令重新格式化为格式，远程操作的 API 既可以接收也可以处理。这需要一些时间，一般不会超过几十个~[我们]

  3. 接下来，您的符合 API 的 XTO 指令必须被包装 + 加密到HTTPS-envelope 中，再次添加了几十个 ~ [us]

  4. 接下来，您的 localhost 将HTTPS-envelope 编组到您的 LAN 接口，添加一些 [us]

  5. 您的下一个障碍是通过公共互联网发送这样的信封（无论是全球性的（通过大陆支付+1 .. +10 [ms] ，如果通过海底电缆或通过新西兰的卫星通信连接，则大约 +100 [ms]）等），或者如果指定的提供商的本地 Intranet 在其托管数据中心中暴露了一个用于托管对等互连的区域（在那里通过10GBE电缆（如果API Provider 为您提供了这样的报价））。

  6. 到这里 - 故事还没有结束 - 你的HTTPS-wrapped 信封刚刚到达Provider 自己的 API-providing-Gateway队列的输入端口，所以到目前为止还没有任何处理开始，直到你已经收集了数百个 [我们]（至少）。稍后，所述 API 提供者会HTTPS从队列中弹出你的 -envelope 以便开始解码 + 解包队列释放的HTTPS-envelope 的内容（添加 +few [us] 的成本，具体取决于流量模式和在 API-providing-Gateway + 解码操作的排队策略取决于他们用于这种分解的技术，即使是最复杂的基于硅的技术也无法更快地执行此操作）
  7. 在上一步之后，API-providing-Gateway 可以将您解码的 XTO 指令传送到 API-service（猜猜看，为这一步添加几个 +[us] ）
  8. API-FSA 开始将您的 API-conformant XTO 指令转换为交易执行（取决于备用性能和工作负载/流量模式，在这里您支付几十、几百、几千 [ms]还取决于智能集成工具交易执行场所的风险评估、价格反馈、流动性池和与 NDD/ECN 执行引擎和政策一起使用的群岛账簿维护有多么棘手，最终确定了 XTO 的实际市场价格被处决。

--------到目前为止，它是单个 XTO 交易端到端路径的时间（价格）关键部分。

  1. 一旦您的 XTO 在订单簿记录上真正“匹配”，就会创建确认，以便将其发送回您身边（时间非关键操作，因此不要指望任何最高优先级，也不要在处理中, 也不在排队策略中发生，所以添加 +few [ms] )

  2. 为了交付，重复相同的步骤序列——API-conformant answer assembly + queuing + API-response translation in an API-providing-Gateway to text-format with HTTPS-encryption + queueing + series of all involved ISO/ OSI-L3 交付路线（无论是托管还是通过全球网络）

  3. 在这里，您的 LAN 已将一系列 IP 数据包传送到您的 localhost 接口，以解包、解密、转换并开始解码消息的含义。
  4. 此时，您的 XTO 指令的响应可以与最初发送的 XTO 指令的意图进行比较和最佳匹配。
  5. 按秒表读取E2E-RTT持续时间。

这就是为什么你可以遇到从几十 [us] 到+1000 [ms] 以上的任何东西的原因

如何做到最好的最好的？

  • 避免项目在没有彻底验证其可行性的情况下开始（无论是在高工作负载下的延迟包络和整体扩展的意义上）——在简单的工作负载下可能工作的事情往往会在繁重和持久的情况下显示出令人讨厌的惊喜和非凡的麻烦负载模式和虚假风暴...
  • 避免依赖“Wannabe-TechGuru(s)”（即使所有人都在谈论基于 REST/HTTP 的 API，也不要将这种体验移到区域之外，这可能就足够了，进入区域的次数越少，最终会变得紧张-时间控制回路不能提供稳定的结果）
  • 避免遵循“营销”准论点（即使所有人都在谈论某些技术——无论是 { JSON | XML | CORBA-BLOBs }——永远不要将这种技术自动用于你的延迟敏感的实时分布式系统等）
  • 引入低延迟工具 + 避免任何昂贵的开销
  • 永远不要重新包装东西（最好在二进制密集地图中提供）
  • 始终根据合同条款和条件记录时间戳时间并记录/核对证据记录，如果在生产中未满足或以其他方式违反 T&C，则要求财务补救（这是一个漫长的故事）

最好的下一步？

如果您已阅读此预告片，您一定已经注意到，以上这些选择实际上都不是您的选择。

您将在任何情况下承担商品之间的价格变动[1..8]和内部价格滑点的风险[8]

最好去寻求一个更好更快的 API + 一个共同定位的服务器托管。

奖金：

如果确实在寻找高级

“发送……请求的方法，这样在第二次连续请求中价格发生变化的可能性很小。”

然后听 - 有一种方法 - 如果您的交易策略不需要与E2E 分布式交易确认/更改交互，通过所有传入通道{ price | DoM-L3 }异步宣布，只需智能并提交所有立即执行[_>>_price-stream_>>_]此类 XTO 指令[PARALLEL]（有经过验证的方法可以在您的本地执行此操作）。

使用这种方法，您的齐射将简单地以最佳执行价格从订单簿的实际状态中抽出所有必要的流动性（如果没有被运营商政策欺骗（再次，请参阅日志记录证据以检查并可能要求 FSA 保护您的利益，以防出现任何公平交易 + 公平价格差异））。

更新

好的，@jfriend00 介入并反对（引用，强调添加）：

您提出的问题过于复杂。OP 有一个 HTTP API，他们想知道他们是否可以比 request() 模块更快地向该 API 发出请求。这就是问的问题。您根本没有解决这个问题，而是进入了与所提出的问题完全无关的各种内容。一个冗长、复杂、难以理解的答案实际上甚至没有回答所提出的问题，这就是投票的目的。– jfriend00 28 分钟前

成为：

  • 很长 ——好吧，当然——算法交易基础设施并不简单

  • 复杂 - 多方（相反利益）分布式交易很复杂

  • 难以理解——任何人都可能出现在这里并更好地解释如此复杂的 E2E 问题
  • 没有解决这个问题——提供了唯一有意义的解决方案，连同所有相关的论点，为什么任何其他的（更简单，仅一步隔离，甚至过度简化以变得“更容易”）将不适用于 O /P 面向。

很抱歉不得不重复一遍，30 多年后我敢告诉你，我很清楚没有其他人（如果仍有疑问，请重新考虑这个故事——如果有的话，所有顶级 HFT 鲨鱼已经证明了他们立即投入其中。因此，如果他们中没有一个人进入任何如此简单和微不足道的魔法射击，但都保持在下面解释的最知名解决方案的范围内，那就是一个清晰而可靠的证据，没有更好的存在。QED）

于 2017-10-27T14:53:45.583 回答