epam/fix-antenna-net-core

FIX Antenna™ .NET Core is a high-performance low latency .NET FIX Engine.

FIX Antenna™ .NET Core Community Edition

FIX Antenna™ .NET Core is a high-performance low latency .NET FIX Engine. Ideal solution for buy side and proprietary trading companies.

Here you can find out more about our other products.

Fast response time

Requirements & Compatibility

The engine is based on .NET Standard 2.0 and is compatible with any platform that supports .NET Standard 2.0 e.g. .NET Framework 4.8, .NET Core 3.1, .NET 5, .NET 6.0.

Samples and libraries were tested with .NET Framework 4.8 and .NET 6.0 under Windows 10 and Linux Ubuntu 16.04.

.NET SDK 6.0 is required to build and run samples

Quick start guide

Features

• FIX Engine
• Session processing
• Storage
• Performance tuning
• Message composition API
• Security

Current State

2022 – FIX Antenna .NET Core 1.0 Community Edition (open source)

Changelog

Roadmap

• NuGet packages
• Message decorator
• Scheduler
• REST admin and monitoring interface

Samples description

Sample name	Folder	Description
EchoServer	Samples/EchoServer	A very simple server, which sends all the received messages back to a client.
ConnectToGateway	Samples/ConnectToGatway	A very simple client, which connects to the server and accepts all received messages.
SimpleServer	Samples/SimpleServer	Demonstrates how to implement a FIX server with simple IP filtering of incoming sessions.
SimpleAdminClient	Samples/SimpleAdminClient	Demonstrates how to connect to an administrative session and communicate with it using the implementation of administrative messages.
ConnectToGatewayAsync	Samples/ConnectToGatewayAsync	Version of 'ConnectToGateway' using 'session.ConnectAsync(...)'
Latency	Samples/Latency/Server Samples/Latency/Sender	Simple scenario to test performance
Scheduler	Samples/SimpleScheduledServer Samples/SimpleScheduledClient	Demonstrates how to accept a scheduled connection, and how to connect with a schedule.

How to build and run samples

With Visual Studio

Recommended version is Visual Studio 2022

1. Open FixAntenna\Epam.FixAntenna.sln in Visual Studio
2. Choose Debug configuration
3. Build → Rebuild solution
4. Find the Samples\EchoServer\bin\Debug\net6.0\EchoServer.exe and run
5. Find the Samples\ConnectToGateway\bin\Debug\net6.0\ConnectToGateway.exe and run

With CLI

1. Make sure you have .NET SDK 6.0 installed
2. dotnet build Epam.FixAntenna.sln -c Debug -f net6.0
3. Find the Samples\EchoServer\bin\Debug\net6.0\EchoServer.exe and run
4. Find the Samples\ConnectToGateway\bin\Debug\net6.0\ConnectToGateway.exe and run

Documentation

• Backgrounder
• Basic concepts
• Configuration
• FIX Message
• Prepared message
• FIX Session
• FIX Session Acceptor
• FIX Session Initiator
• Installation and Uninstallation
• Monitoring and Administration
• Other topics
• Quick Start
• Recovery
• Repeating Group API
• Tags Generator Tool
• SSL/TLS support
• Validation
• Scheduler

Contributing

1. Fork it (https://github.com/epam/fix-antenna-net-core/fork)
2. Create your feature branch (git checkout -b feature/fooBar)
3. Read our contribution guidelines and Community Code of Conduct
4. Commit your changes (git commit -am 'Add some fooBar')
5. Push to the branch (git push origin feature/fooBar)
6. Create a new Pull Request

Development team

• Aleksey Shuvalov - Developer
• Ivan Ponomarev - QA Engineer
• Sergey Matveev - Developer
• Vladimir Gusev - Analyst
• Viktar Tserashchuk - Developer
• Oleh Vasyliev - Developer
• Vasili Yakauleu - QA Engineer
• Aliaksandra Khrutskaya - QA Engineer
• Mariia Golubeva - Analyst

License

Copyright © 2020-2023 EPAM Systems, Inc.

Distributed under the Apache License, Version 2.0.

Support

Should you have any questions or inquiries, please direct them to [email protected]

fix-antenna-net-core's Issues

.Net Standard 2.0 with .Net Framework 4.7.2

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?

ByteBuffer.Add(char) is Encoding dependant

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?

Make IExtendedFixSessionListener public

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

Question about behavior when param forceSeqNumReset set to OneTime

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.

FieldNotFoundException - tag 271 not in message (35=x) where 269 = q

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

.editorconfig file makes the solution unbuildable in Visual Studio

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.

Support FixMessage.Parse

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?

Epam.FixAntenna.Constants does not exist.

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

thanks.

Datetime values parser

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.

ByteArrayMessageStorage.Add: Suspicious code

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);
}

Disconnect / losing fix connection not in logs

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?

Loss of data integrity with threading from OnNewMessage()

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)

Reject message (35=3) does not include tag 371 for troubleshooting

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�

Net (Wrapper) migration to .Net Core

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?

Time drift when running on AWS

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)