好的。首先,我们需要将任务(专家的类型)分为商业性的(通过网络),和名义上的非商业性的变体(在同一个OP系统内)。
网络变体--毫不含糊地通过额外的服务器,用于安全和客户端管理。
系统内-通信:映射,因为速度和可靠性。
由于终端将保持libc,直到它下降或关闭,它将是MT(从机)本身状态的一个指示。
该协议将看起来像这样。
主站创建一个命名的mappu(其名称为所有从站所知),并等待他们发出信号来启动路径这将是顾问(从站)的窗口句柄。
在信号交换后,另一个被创建,交易信号在这里被传递,同时,更新窗口的命令被给予每个从属机构。
信号执行后,从属机构应报告其执行情况,否则将被视为冻结,并采取措施使其恢复。
如果从机已经卸载(正确),它应该报告。
任何一个从属机构都可以反过来监测主站的状态,并采取必要的行动来提高它或发出警报。
一般来说是差不多的。
关于网络通信,见下文。
制作一个商业版本并加以推广。
TheXpert:
制作一个商业版本并加以推广。
制作一个商业版本并加以推广。
你在跟我说话吗?
FAQ:
你在跟我说话吗?
如果你是话题发起人,是的 :)
你在跟我说话吗?
FAQ:
一旦信号被执行,从属机构必须报告执行情况,否则将被视为冻结,并采取措施将其提高。
如果它被卸载(正确地),从属机构应该报告它。
这几句话提醒我有必要讨论两种运作模式
在主站->客户端的订单层面上进行订单同步。还有主站->客户端层面的信号同步(我们是否需要一个信号数据库,从客户端接收的确认,等等)
,我想我们也应该决定在同步和信号丢失方面什么会更可靠,更不复杂。
TheXpert:
制作一个商业版本并加以推广。
制作一个商业版本并加以推广。
我不想推动什么,也不会。 我在做一个手段,而不是目的。 我为每个人都这样做。
sergeev:
这几句话提醒我有必要讨论两种运作模式
在主站->客户端的订单水平上进行订单同步。在主站的信号->客户端的信号层面上的信号同步(是否需要一个信号数据库,确认从客户端接收,等等)。
我认为我们还应该决定在同步和信号丢失方面什么会更可靠,更不复杂。
你不需要把事情弄得很复杂,只要在一定的时间间隔内(比如一秒钟一次)向客户发送一个控制信号,如果他没有反应,就采取行动。
sergeev:
我不想推动什么,也不会。 我只做手段,不做目的。 我为每个人都这样做。
我不想推动什么,也不会。 我只做手段,不做目的。 我为每个人都这样做。
我尊重这样的人,继续努力!!!。
没有必要把事情复杂化,只要在一定的时间间隔内(比如,一秒钟一次)向客户发送一个控制信号,如果客户没有反应,就采取行动。 <br / translate="no">
你所说的服务器到客户端的信号就是这些吗? 你需要一个详细的机制,说明信号如何生存并传输到接收器。 我以前从未遇到过这样的系统。只订购复印件。
这一切都解决了,但抱歉不是免费的。
- 当地
- 远程
我们正计划以一个服务器--许多客户 的模式一次完成所有工作。
我们将需要注意以下几个方面
- 链接选项(文件、内存用于本地;套接字、http、中间服务器等用于远程)。
- 对通信通道没有负荷(对远程同步来说尤其如此)。
- 故障安全(在通道丢失的情况下恢复通道)
- 在终端/操作系统故障的情况下重新初始化专家顾问本身
- 如果连接丢失/恢复,不重复/不删除交易
等。
你还需要考虑两种意识形态
- 订单可用性水平上的同步
- 在发送开仓/平仓订单信号的层面上实现同步。
描述这种变体对我们每个建议的优缺点。
我希望通过讨论来帮助我们找到系统可靠性/简单性的最佳解决方案。
我将进行编码和测试。
经协商,结果可在代码库中公布。