epam / fix-antenna-net-core Goto Github PK

Will you be supporting FixMessage.Parse which is supported by the .net version that is wrapped around C library?

also will you support all the features and is there a page showing how to port your code to this library from the current .net framework version?

Currently IExtendedFixSessionListener interface is internal. It is useful to be public.

You've stated your library is compatible for .net standard 2.0 which means .net framework 4.7.2 is supported by according to Microsoft .Net Standard documentation but you're saying it's from .Net Framework 4.8 and above, are you sure this is true?

Hi Everyone!
Thanks a lot for your open source product! I would like to ask about unexpected (for me) actual behavior of FA provided below. Was this expected by design?

Version of FIX Antenna .NET Core Community Edition: 1.0.4

Preconditions
The following params are specified:

1. fixVersion = FIX.4.4
2. autoreconnectAttempts = 0
3. autoreconnectDelayInMs = 3000
4. forceSeqNumReset = OneTime
5. inMemoryQueue = true
6. storageFactory = Epam.FixAntenna.NetCore.FixEngine.Storage.InMemoryStorageFactory
7. All other params kept with their default values.

No FIX session acceptor which runs.

Actions

1. Start FIX session initiator first.
2. Wait until it tried some reconnects.
3. Start FIX session acceptor.

FIX message Logon will be send without tag “141=Y”. It seems like FA send this tag only in first try of connection. If first try was successful, Logon with “141=Y” will be send as expected. But if first try was unsuccessful FA doesn’t set this tag in further reconnects.

Expected (for me) behavior
Trying to send Logon with “141=Y” until FIX session will be successfully established once. For example, seems like in such case with similar parameters proprietary FIX Antenna .NET 2.24.0.255 acts as expected.

Usually offset and length are related to the input byte[] parameter. However in the following code the offset parameter is treated as destinationIndex. Why is that?

// ByteArrayMessageStorage class
public override void Add(int tagIndex, byte[] value, int offset, int length)
{
    Array.Copy(value, 0, _origBuffer, offset, length);
}

If we want to move from Net (Wrapper) to .Net Core are there any good articles, also my understanding is that .Net Wrapper will be obsolete in the near future whereas .Net Core will be a new way forward, is that correct?

Hi,

When sending a test of new order single (35="D"), I get an execution report in return (35=8). However the FixAntenna engine then rejects that report (35=3). There is no tag 371 included in the rejection report which would show me which tag apparently has no value. I also can't see that any tag in the execution report does not have a value - this must be a bug as there is no tag value missing. I have had a call with our provider - a big reputable provider in the industry and all checks out on their side. Please advise ?

log messages out; new order single and the reject:

20230814 16:52:29.923 - 8=FIX.4.2 �9=205�35=D�34=4�49=RID�56=IR�52=20230814-14:52:29.923�1=LCE1�15=ZAR�21=1�22=8�38=1�40=2�44=3150�48=Instr�54=1�55=Instr�59=0�100=SAFX�128=SAS�60=20230814-14:52:29.918�11=stringOnlyID�10=036�

20230814 16:52:29.957 - 8=FIX.4.2�9=103�35=3�34=5�49=RID�56=IR�52=20230814-14:52:29.957�45=4�372=8�373=4�58=Application not available�10=118�

log in; execution report:

20230814 16:52:29.953870000 - 8=FIX.4.2�9=330�35=8�115=SAS�34=4�49=IR�52=20230814-14:52:29.944�56=RID�1=LCE1�6=0.000000�11=stringOnlyID�14=0�15=ZAR�17=36�20=0�21=1�22=8�31=0.000000�32=0�37=22�38=1�39=A�40=2�44=3150�48=Instr�54=1�55=Instr�59=0�60=20230814-14:52:29.944�150=A�151=1�167=FUT�198=69337265�200=202312�205=20�207=APD�424=1�425=0�426=0.000000�10=223�

Hi,

I have a production application using the FixAntenna nuget package: NetCore 1.1.0. I make two fix session connections with identical settings. The one just a different port.

At random I lose connection with only one of the fix sessions, maybe 10min in, maybe 40min in.

No indication in the log files at /logs/<SenderCompID-TargetCompID.out/in.

fixEngine.properties:

Log.TraceIsOn = true
Log.Engine.TraceIsOn = true
Log.DebugIsOn = true
Log.Engine.DebugIsOn = true
Log.NoteIsOn = true
Log.WarnIsOn = true
Log.ErrorIsOn = true
Log.FatalIsOn = true

tradePeriodTimeZone = GMT+2

inMemoryQueue=true
validation=false
queueThresholdSize = 1

enableNagle=false

validateCheckSum=false
validateGarbledMessage=false

markIncomingMessageTime=true
cpuAffinity=0

Is there another setting or location I can see more detailed connection specific logs to troubleshoot?

Hello... when building the solution, it raised a lot of errors regarding Epam.FixAntenna.Constants does not exist.

thanks.

1. Clone Repo
2. Main Branch
3. Open Solution in Visual Studio 2022
4. Build

Error :

private readonly SemaphoreSlim _msgBufferSemaphore = new SemaphoreSlim(1);

CA2213 : Disposable fields should be disposed - Error

The .editorconfig stops solution from building due to this.

DateTimeHelper uses Stopwatch.GetTimestamp() to calculate current time, and when running on AWS in some conditions DateTimeHelper.CurrentTicks tend to accumulate time shift (long running sessions)

I have a question about parsing datetime values, specifically year values.

In several places in the code, validation is used against the hard coded value 1582, which is the beginning of the Gregorian calendar. But according to the FIX specification, any value between 0000 and 9999 should be valid for the year. Moreover, particular value 1582 has no practical meaning for today's trading platforms :-)

Is this a bug or is it intentional?

There are trading parties (KBC) that sometimes send 0000 as the year and parsing of such messages throws exception.

Hi, with data incremental refresh (35=x) the rule is that 271 is conditionally required when 279 = 0 AND 269 = 0, 1 or 2. I have incoming data from my market data provider where 269 = q (trading period details) and there is no 271 (MDEntrySize) field in the message then. This then is seen as an invalid message and I lose the fix connection.

Since 269 is not 0, 1 or 2 - that is then a bug correct?

This is with FixAntenna.NetCore

Hi,

I am sure this is not actually an issues with the fix-antenna-net-core library, so feel free to close this issue if my posting here is inappropriate.

I get a false return on fixMessage.IsTagExists(268) even though all the message cleary has Tag268 included in the messages according to the log file.

My code example here

(This happens on 35=X incoming messages, where 268 is a required field according to the providers dictionary)

IMO ByteBuffer.Add(char) method is implemented incorrectly.

Following is the code:

public ByteBuffer Add(char b)
{
    if (Buffer.Position == Buffer.Length)
    {
        IncreaseBuffer(64);
    }

    _writer.Write(b);
    return this;
}

Inside that function BinaryWriter.Write(char) method is used. According to MSDN

BinaryWriter.Write(char) writes a Unicode character to the current stream and advances the current position of the stream in accordance with the Encoding used and the specific characters being written to the stream.

Thus based on Encoding that method can write more than 1 byte (even 4 bytes) into buffer. Is it expected?