[QFJ-43] Throwing RejectLogon causes Logout message before Disconnect Created: 10/Aug/06 Updated: 15/Nov/12 Resolved: 12/Aug/06 |
|
| Status: | Closed |
| Project: | QuickFIX/J |
| Component/s: | Engine |
| Affects Version/s: | 1.0.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Default |
| Reporter: | Rob Gilliam | Assignee: | Steve Bate |
| Resolution: | Not a bug | Votes: | 0 |
| Labels: | None | ||
| Environment: |
Windows XP, Sun JVM 1.4.2_06 |
||
| Issue Links: |
|
||||||||
| Description |
|
Trying to reject invalid (potentially malicious) Logon requests from an unrecognised IP address fromAdmin by throwing RejectLogon exception when a "bad" Logon is detected. The JavaDoc for RejectLogon says: "This exception causes a logon to be reject with an immediate disconnect." However Session.next(Message) is calling generateLogout() when RejectLogon is caught, so the disconnect is not "immediate", and the "unauthorized" logon attempt consumes a sequence number in the outgoing direction which the "authorized" connecting system may not be aware of when next it logs in, causing a ResendRequest to be sent when a valid logon is finally established (see FIX Protocol 4.4 with Errata 20030618, Vol 2 - "Session Protocol", page 6). |
| Comments |
| Comment by Steve Bate [ 10/Aug/06 ] |
|
I'll investigate this. I understand the issue with the consumed sequence number. However, on page 9 of the specification it states... The only exception to the "do not terminate the session" rule is for an invalid I'll check on the behavior of the C++ engine. I'd like to keep it consistent. In any case, the Javadocs should be updated to be more accurate. |
| Comment by Steve Bate [ 12/Aug/06 ] |
|
The behavior is consistent with the C++ engine and the FIX spec so I'm reclassifying this issue as an improvement rather than a bug. However, I'll add the capability for the behavior to be optional. See the linked issue for more details. |
| Comment by Rob Gilliam [ 14/Aug/06 ] |
|
OK, we can make that work, although you also might like to consider the inconsistency that then appears to occur when throwing RejectLogon if the Logout message is sent: the engine uses up a MsgSeqNum for its Logout, but doesn't appear to advance the sequence number it expects from the initiator. |