高度可靠的交易/信号复制器(意识形态的讨论和发展)

 
关于这个问题,我对同步(传输订单)终端的选项感兴趣
- 当地
- 远程

我们正计划以一个服务器--许多客户 的模式一次完成所有工作。

我们将需要注意以下几个方面
- 链接选项(文件、内存用于本地;套接字、http、中间服务器等用于远程)。
- 对通信通道没有负荷(对远程同步来说尤其如此)。
- 故障安全(在通道丢失的情况下恢复通道)
- 在终端/操作系统故障的情况下重新初始化专家顾问本身
- 如果连接丢失/恢复,不重复/不删除交易
等。

你还需要考虑两种意识形态
- 订单可用性水平上的同步
- 在发送开仓/平仓订单信号的层面上实现同步。

描述这种变体对我们每个建议的优缺点。

我希望通过讨论来帮助我们找到系统可靠性/简单性的最佳解决方案。

我将进行编码和测试。

经协商,结果可在代码库中公布。
 

好的。首先,我们需要将任务(专家的类型)分为商业性的(通过网络),和名义上的非商业性的变体(在同一个OP系统内)。

网络变体--毫不含糊地通过额外的服务器,用于安全和客户端管理。

系统内-通信:映射,因为速度和可靠性。

由于终端将保持libc,直到它下降或关闭,它将是MT(从机)本身状态的一个指示。

该协议将看起来像这样。

主站创建一个命名的mappu(其名称为所有从站所知),并等待他们发出信号来启动路径这将是顾问(从站)的窗口句柄。

在信号交换后,另一个被创建,交易信号在这里被传递,同时,更新窗口的命令被给予每个从属机构。

信号执行后,从属机构应报告其执行情况,否则将被视为冻结,并采取措施使其恢复。

如果从机已经卸载(正确),它应该报告。

任何一个从属机构都可以反过来监测主站的状态,并采取必要的行动来提高它或发出警报。

一般来说是差不多的。

关于网络通信,见下文。

 
制作一个商业版本并加以推广。
 
TheXpert:
制作一个商业版本并加以推广。

你在跟我说话吗?
 
FAQ:
你在跟我说话吗?
如果你是话题发起人,是的 :)
 
FAQ:

一旦信号被执行,从属机构必须报告执行情况,否则将被视为冻结,并采取措施将其提高。

如果它被卸载(正确地),从属机构应该报告它。

这几句话提醒我有必要讨论两种运作模式

在主站->客户端的订单层面上进行订单同步。还有主站->客户端层面的信号同步(我们是否需要一个信号数据库,从客户端接收的确认,等等)

,我想我们也应该决定在同步和信号丢失方面什么会更可靠,更不复杂。

 
TheXpert:
制作一个商业版本并加以推广。

我不想推动什么,也不会。 我在做一个手段,而不是目的。 我为每个人都这样做。
 
sergeev:

这几句话提醒我有必要讨论两种运作模式

在主站->客户端的订单水平上进行订单同步。在主站的信号->客户端的信号层面上的信号同步(是否需要一个信号数据库,确认从客户端接收,等等)。

我认为我们还应该决定在同步和信号丢失方面什么会更可靠,更不复杂。


你不需要把事情弄得很复杂,只要在一定的时间间隔内(比如一秒钟一次)向客户发送一个控制信号,如果他没有反应,就采取行动。
 
sergeev:

我不想推动什么,也不会。 我只做手段,不做目的。 我为每个人都这样做

我尊重这样的人,继续努力!!!。
 
没有必要把事情复杂化,只要在一定的时间间隔内(比如,一秒钟一次)向客户发送一个控制信号,如果客户没有反应,就采取行动。 <br / translate="no">
你所说的服务器到客户端的信号就是这些吗? 你需要一个详细的机制,说明信号如何生存并传输到接收器。 我以前从未遇到过这样的系统。只订购复印件。
 
这一切都解决了,但抱歉不是免费的。