快速修复库问题

发布于 2024-08-19 10:00:12 字数 288 浏览 18 评论 0原文

我对quickfix 很陌生,我有几个关于quickfix 库的问题,我将非常高兴从您那里得到答案:

我计划开发FIX 服务器,它可以同时从多个客户端获取FIX 请求。关于这一点,

a)如果我需要区分来自不同客户端的请求(如何区分这些请求),TargetID(即CLIENT1)的确切含义是什么?

b) 对于服务器/客户端来说,TargetID 的一般含义是什么?

c) 如何添加自定义字段和自定义消息以及消息破解对象的确切连接是什么?

问候,

莫迪凯·雅各比

I’m new with the quickfix stuff and I have several questions regarding the quickfix library, and I will be more than happy to get answers from you:

I’m planning to develop FIX server that gets FIX request from multiple clients concurrently. Regarding that,

a) What is the exact meaning of TargetID (i.e. CLIENT1) if I need to distinguish request from different clients (how can I distinguish those request from each other)?

b) What in general is the meaning of TargetID regarding the server/client?

c) How do I add custom fields and custom messages and what is the exact connection to message cracker object ?

Regards,

Mordechai Yaakobi

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

一页 2024-08-26 10:00:12
  1. TargetID 是盒子的名称
    到您发送消息的地方,如果
    你需要区分会话
    对于多个客户(我假设
    一台服务器)只需给每个客户端
    不同的SenderCompID

    在您的服务器上,您必须为每个客户端设置一个会话。

    一个服务器-客户端会话的示例:

    在您的服务器(INCA)上:

    <前><代码>[会话]
    开始字符串=FIX.4.0
    发件人CompID=INCA
    目标CompID=客户端1

    在您的客户端 (CLIENT1) 上:

    <前><代码>[会话]
    开始字符串=FIX.4.0
    发件人CompID=客户端1
    目标化合物 ID=INCA

    quickfixengine区分会话
    (服务器-客户端连接)基于
    这 3 个值:(BeginString,
    TargetCompID、SenderCompID)

    当您发送消息时,您将
    comp id 为 sendercompid 并且
    定位到您发送消息的位置
    作为targetcompid。您指定
    基于修复的 beginstring
    您想要使用的版本
    通信(FIX4.0/FIX4.2
    ....).

  2. 我想上面已经解释过了,
    TargetID 是您所在盒子的 ID
    发送消息。当服务器
    回复客户端它将
    SenderCompID 设置为(服务器)
    id 和 TargetCompID 将设置为
    客户端到响应所在的位置
    正在发送。

  3. 自定义字段取决于什么
    正是需要的。固定协议
    指定自定义字段
    FieldID 大于保留值
    范围,因此您的自定义字段可以
    从 FieldID 5000 开始。

    有几个选项
    该怎么做呢?最简单的一个
    就是只使用数值
    消息并将其添加到消息中(我
    假设你使用 c++ 但它是相似的
    与其他语言)。

    类似于:

     msg.setField(5000,"SomeValue");
    

    此自定义字段不会
    自动验证,因为 FIX
    不知道这件事。 FIX 使用 xml
    每个消息和字段所在的文件
    已指定。

    有一个适当的程序来添加
    新消息到 xml 规范,然后
    重新生成quickfixengine代码
    生成新的字段结构但是这样
    到目前为止我不需要这样做。

    消息破解只是一种方法
    需要指向泛型的指针
    消息,然后它查看
    消息 ID(如果我记得的话)和电话
    适当的处理程序。

    这是一个包含很多内容的大型 if 语句
    字符串操作所以有时
    最好进行检查
    你自己,但你应该没问题
    使用它。

    这就是该方法的样子,您就会明白:

    void hack( const Message& message, 
          const FIX::SessionID&会话ID)
    {
    const std::string&消息类型值 
             = message.getHeader().getField( FIX::FIELD::MsgType );        
    if( 消息类型值 == "0" )
      onMessage( (const Heartbeat&)message, sessionID );
    别的
    if( 消息类型值 == "A" )
      onMessage( (const Logon&)message, sessionID );
    别的
    if( 消息类型值 == "1" )
      onMessage((const TestRequest&)消息,sessionID);
    别的
    

    然后你通常会实现
    适当的方法,例如
    如果你只关心
    您实施的 ExecutionReport
    你的代码:

    virtual void onMessage( ExecutionReport&, const FIX::SessionID& );
    

    然后你的应用程序将得到
    ExecutionReport 这样您就可以
    处理它。 onMessage 方法
    对于您不喜欢的消息
    实施简单地什么都不做并且
    返回,这样消息就永远不会到达
    您的应用程序。

如果您需要添加自定义消息/字段,我发现这很有用< /a>,不过我还没用过。

  1. TargetID is the NAME of the box
    to where you sending message, if
    you need to distinguish sessions
    for multiple clients (I assume into
    one server) just give each client
    different SenderCompID.

    On your server you have to setup one session for each client.

    Example for one server-client session:

    On your server (INCA):

    [SESSION]
    BeginString=FIX.4.0
    SenderCompID=INCA
    TargetCompID=CLIENT1
    

    On your client (CLIENT1):

    [SESSION]
    BeginString=FIX.4.0
    SenderCompID=CLIENT1
    TargetCompID=INCA
    

    quickfixengine distinguishes session
    (server-client connection) based on
    those 3 values: (BeginString,
    TargetCompID, SenderCompID)

    When you send message you put your
    comp id as sendercompid and the
    target to where you sending message
    as targetcompid. You specify
    beginstring based on the fix
    version you wish to use to
    communicate (FIX4.0/FIX4.2
    ....).

  2. I guess it's explained above,
    TargetID is the ID of box where you
    sending messages. When server
    responding back to client it will
    set SenderCompID as it's (server)
    id and TargetCompID will be set to
    the client to where the response is
    being sent.

  3. Custom fields depends on what
    exactly is required. FIX protocol
    specifies custom fields those with
    FieldID bigger than the reserved
    range, so your custom fields can
    start with FieldID 5000.

    There are couple of options about
    how to go about it. The simplest one
    is to just use the numerical value
    of message and add it to message (I
    assume you use c++ but it's similar
    with other languages).

    Something like:

     msg.setField(5000,"SomeValue");
    

    This custom field will not be
    validated automatically because FIX
    does not know about it. FIX uses xml
    files where each message and field
    is specified.

    There is a proper procedure to add a
    new message to xml specs and then
    regenerate quickfixengine code to
    generate new field structures but so
    far I did not need to do it.

    message cracker is just a method
    that takes pointer to generic
    message and then it looks at the
    message id (if I remember) and calls
    appropriate handler.

    It is one big if statement with lots
    of string operations so sometimes
    it's better to do the checking
    yourself, but you should be okay to
    use it.

    This is how the method looks like, you'll get the idea:

    void crack( const Message& message, 
          const FIX::SessionID& sessionID )
    {
    const std::string& msgTypeValue 
             = message.getHeader().getField( FIX::FIELD::MsgType );        
    if( msgTypeValue == "0" )
      onMessage( (const Heartbeat&)message, sessionID );
    else
    if( msgTypeValue == "A" )
      onMessage( (const Logon&)message, sessionID );
    else
    if( msgTypeValue == "1" )
      onMessage( (const TestRequest&)message, sessionID );
    else
    

    You then generally implement the
    appropriate method like for example
    if you only care about
    ExecutionReports you implement in
    your code:

    virtual void onMessage( ExecutionReport&, const FIX::SessionID& );
    

    Then your application will get the
    ExecutionReport so that you can
    process it. The onMessage methods
    for messages that you don't
    implement simply do nothing and
    return so message will never get to
    your application.

If you need to add custom messages/fields I've found this useful, I haven't used it though.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文