quickfixgo / quickfix

The Go FIX Protocol Library :rocket:
https://www.quickfixgo.org/
Other
753 stars 291 forks source link

sessionID in Send message not consider TargetSubID, ServerSubId, TargetLocationID etc #356

Open susannamartinelli opened 5 years ago

susannamartinelli commented 5 years ago

version: 0.6.0

I've started a new Initiatior/Acceptor session. Both components has in correctly configured TargetCompID, TargetSubID, TargetLocationID, SenderCompID, SenderSubID, SenderLocationID in his own configuration files (SESSION part)

After the Logon went correctly the Initiator creates a new key in sessions variable (file registry.go) with the following value: FIX.4.2:MyInititiatorCompID/MyInititiatorSubID/MyInititiatorLocationID-> MyTargetCompID/MyTargetSubID/MyTargetLocationID...

However from the Initiator side if I send a message with the correct tag:

        msg := quickfix.NewMessage()
    msg.Header.SetString(tag.MsgType, "D")
    msg.Header.SetString(tag.SenderCompID, "MyInititiatorCompID")
    msg.Header.SetString(tag.SenderSubID, "MyInititiatorSubID")
    msg.Header.SetString(tag.SenderLocationID, "MyInititiatorLocationID")
    msg.Header.SetString(tag.TargetCompID, "MyTargetCompID")
    msg.Header.SetString(tag.TargetSubID, "MyTargetSubID")
    msg.Header.SetString(tag.TargetLocationID,  "MyTargetLocationID")
    msg.Header.SetString(tag.BeginString, "FIX.4.2")
        ...

It returns to me Unknow session. I've noticed that in registry.go in this line https://github.com/quickfixgo/quickfix/blob/90abc7fbcb82e4f15f75a593ea947667810c019e/registry.go#L37 you search the sessionID with only BeginString, TargetCompID and SenderCompID by omitting SenderSubID, SenderLocationID, TargetSubID, TargetLocationID in sessions created before and this cause the Unknow session error

Thanks

frozenpine commented 4 years ago

same issue, OnBehalfOfSubID is discarded in my case, and server reject my message.

frozenpine commented 4 years ago

i found that logon procedure handled in session.go

func (s *session) sendLogonInReplyTo(resetStore, setResetSeqNum bool, inReplyTo *Message) error {
    logon := NewMessage()
    logon.Header.SetField(tagMsgType, FIXString("A"))
    logon.Header.SetField(tagBeginString, FIXString(s.sessionID.BeginString))
    logon.Header.SetField(tagTargetCompID, FIXString(s.sessionID.TargetCompID))
    logon.Header.SetField(tagSenderCompID, FIXString(s.sessionID.SenderCompID))
    logon.Body.SetField(tagEncryptMethod, FIXString("0"))
    logon.Body.SetField(tagHeartBtInt, FIXInt(s.HeartBtInt.Seconds()))

    if setResetSeqNum {
        logon.Body.SetField(tagResetSeqNumFlag, FIXBoolean(true))
    }

    if len(s.DefaultApplVerID) > 0 {
        logon.Body.SetField(tagDefaultApplVerID, FIXString(s.DefaultApplVerID))
    }

    if err := s.dropAndSendInReplyTo(logon, resetStore, inReplyTo); err != nil {
        return err
    }

    return nil
}

in this function, only common tag is handled, and this function is owned by private structure session.

so is this means i can't handle logon procedure in my code and use some extra tag in logon message?

Arvi89 commented 3 years ago

Same here, I need those extra fields otherwise I'd have duplicated sessions, but it's not taken into account in send() I can manage and handle this myself, just I would prefer using the updated send function :)