Changelog


HFTFeed.Client 1.1.2 is [on NuGet](https://www.nuget.org/packages/HFTFeed.Client). It changes one thing: the default
host is the name `fix-server.hftfeed.com` instead of the IP address that 1.1.0 and 1.1.1 had built in.

```bash
dotnet add package HFTFeed.Client --version 1.1.2
```

The API, the ports, the FIX session behaviour and everything else are unchanged from 1.1.1. Upgrading is a version
bump and a rebuild.

## What changed

`HFTFeedClient.DefaultHost` is now `"fix-server.hftfeed.com"`. The two-argument constructor uses it, so this connects
to the name:

```csharp
using var client = new HFTFeedClient("you@example.com", "your_password");
```

The name is resolved on every connect. Two consequences for your deployment:

- The machine running your client needs **DNS** in addition to outbound TCP on port `9030` (or `9031`).
- In your firewall, allow the **name**, not an address. An address allow-list will keep working only until the
  address changes.

If you pass an explicit endpoint with `new HFTFeedClient(email, password, host, port)`, pass the name there too.

## Why it matters

Until now the feed's address was compiled into the SDK. That is fine while the address never changes, and a problem
on the day it does: every customer would need a new build to reach the feed again, and nothing we could do on our
side would help them in the meantime.

With a name, moving the feed to another address is a DNS change. Clients pick it up on their next connect, and
nobody has to rebuild, redeploy or edit a configuration file.

There is history behind this. Between 11 and 17 September 2026 `fix-server.hftfeed.com` had no record of its own and
was answered by our `*.hftfeed.com` wildcard with the website's address, which refuses FIX connections. That is why
1.1.0 and 1.1.1 shipped the address instead. The name has had its own record since 17 September 2026, and it is
again the only endpoint we publish.

## If you wrote your own FIX client

Nothing about the protocol changed, but the same advice applies: set the host in your FIX engine's session settings
to `fix-server.hftfeed.com`. The connection details in the
[FIX protocol reference](/docs/fixmsg) and on your [Connection](/connection) page show the name, and the rest of the
session is as it was: port `9030` (`9031` is the alternate), `FIX.4.4`, TargetCompID `FixServer`, SenderSubID and
TargetSubID `QUOTE`, and one live session per account.

## Upgrade

```bash
dotnet add package HFTFeed.Client --version 1.1.2
```

Then rebuild. There is no code change to make, and no behaviour to re-test: 1.1.2 is 1.1.1 with a different default
host. If you are still on 1.1.0, read the
[1.1.1 post](/blog/changelog/hftfeed-client-1-1-1) first: it describes the connection pacing and the `Stop()` change
that came with that release. Versions 1.0.x remain unsupported.

## Check what the feed carries

The instruments we stream are now listed publicly at [hftfeed.com/symbols](https://hftfeed.com/symbols), with no
sign-in: the tag 55 key you subscribe with, the symbol name, the asset class and the number of price decimals. The
page is generated from the feed server's own live configuration, so it cannot list a symbol the feed does not carry.

In your own code, `GetSymbols()` returns the same list for your session after `Start()`.

## Get it

- Package: [HFTFeed.Client on nuget.org](https://www.nuget.org/packages/HFTFeed.Client)
- Guide: [Connect with the .NET SDK](/docs/dotnet)
- Reference: [HFTFeed.Client API reference](/docs/dotnet-reference)


HFTFeed.Client 1.1.2: the feed has a stable host name


HFTFeed.Client 1.1.1 is [on NuGet](https://www.nuget.org/packages/HFTFeed.Client). It builds on
[1.1.0](/blog/changelog/hftfeed-client-1-1-0) with a faster receive path and two fixes we recommend to everyone:
reconnects that respect the feed server's connection limit, and a client you can stop and start again.

```bash
dotnet add package HFTFeed.Client --version 1.1.1
```

The upgrade is source-compatible with 1.1.0. Read the two behaviour changes below before you deploy.

## Faster ticks

- **About 2.5x faster decoding.** Market-data snapshots are now decoded in a single pass that applies the feed
  server's own framing rules; every other message still goes through the server's parser. On .NET 8 the cost per
  tick fell from about 314 ns to about 125 ns.
- **No allocations while receiving on Linux and macOS.** 1.1.0 allocated around 190 bytes per tick on those systems
  at typical feed rates and took an extra thread hop on every wake-up. 1.1.1 waits in one plain `recv` call and
  allocates nothing. On our loopback test rig the median receive latency dropped from 35 µs to 28 µs at 1,000 ticks
  per second, and from 14 µs to 9 µs at 10,000. Your own numbers depend on your machine and network.
- **Rate counters are cheaper.** `TPS` and `TPM` read the clock once per socket read instead of twice per tick, and
  still count the trailing second and minute.

With `ReuseTickObject = true` the receive path stays allocation-free end to end, as in 1.1.0.

## Built for .NET 10

The package now contains a native .NET 10 build next to the .NET 8 one, and both are tested on every release. NuGet
picks the right build for your project; .NET 9 applications use the .NET 8 build.

## Two new options for low-latency setups

- `BusyPollMicroseconds`: when set, the receive thread keeps checking the socket for up to that many microseconds
  after it runs dry, so a tick that arrives in that window is handled without a thread wake-up. It keeps one CPU
  core busy while the feed is active, so use it only on a machine with a core to spare. Typical values are
  1,000 to 50,000; the default is 0 (off).
- `ReceiveBufferSize`: the kernel receive buffer for the feed socket, in bytes. A larger buffer absorbs longer bursts
  when your `OnNewTick` handler is occasionally slow. It does not lower latency. The default, 0, keeps your operating
  system's value.

Set both before `Start()`.

```csharp
using var client = new HFTFeedClient("you@example.com", "your_password")
{
    ReuseTickObject      = true,
    BusyPollMicroseconds = 20_000,       // only with a spare core
    ReceiveBufferSize    = 4 * 1024 * 1024,
};
```

## Reconnects that never get your IP address banned

The feed server accepts **6 connections per minute per IP address**. When an address goes over that limit, the server
closes the extra connection without a reply and records a strike. Strikes expire one every 10 minutes, and enough of
them ban the address for minutes, an hour or a day.

1.1.0 retried 0.25 to 0.5 seconds after a drop, could make up to eight attempts in the first minute, and treated a
connection the server closed for being over the limit as one more failure to retry. Under bad network conditions
that could turn into a ban.

1.1.1 opens **at most 5 connections per host in any 60 seconds**, counted across every `HFTFeedClient` in your
process:

- Every connection the server accepts counts, whether its logon succeeds or not.
- An attempt that never reaches the server (connection refused, host unreachable, connect timeout) does not count,
  so reconnecting while the server restarts is never held back.
- `AutoReconnect` waits 1 to 2 seconds after a drop, backs off from there, and waits for a free slot before each
  retry. `Stop()` and `Dispose()` end the wait at once.
- `Start()` never waits. When the budget is spent it opens no connection and throws the new
  `HFTFeedThrottledException`. Its `RetryAfter` property says how long to wait.

```csharp
try
{
    await client.StartAsync();
}
catch (HFTFeedThrottledException ex)
{
    Console.Error.WriteLine($"Too many connection attempts; try again in {ex.RetryAfter.TotalSeconds:F0} s.");
}
```

The limit is per IP address on the server side, so several processes or machines behind the same NAT still share it.
Keep one client per application and share its ticks inside your process.

## Stop, then start again

In 1.1.0, `Stop()` kept the list of subscribed symbols but the next `Start()` did not send it. `Subscribe` for
those symbols then only reported `Already subscribed`, and no ticks arrived.

In 1.1.1, `Stop()` and `Dispose()` clear the subscription list. After `Start()`, subscribe again:

```csharp
client.Stop();

await client.StartAsync();
client.Subscribe("1013");   // sends a new subscription and ticks flow again
```

`AutoReconnect` is unchanged: after an unexpected drop it restores your previous subscriptions once per connection.

## Smaller fixes

- A logon that the server ends by closing the connection now fails at once with an `HFTFeedException` that says so,
  instead of an `HFTFeedTimeoutException` after 10 seconds.
- A failed `Start()` closes its connection and never starts the reconnect loop. `Stop()` ends a reconnect attempt
  that is in progress.
- A garbled entry date or time beyond `DateTime.MaxValue` now yields `EntryTimeUtc = DateTime.MinValue` instead of an
  exception that dropped the connection.

## Upgrade checklist

1. `dotnet add package HFTFeed.Client --version 1.1.1`
2. If your code calls `Start()` in its own retry loop, catch `HFTFeedThrottledException` and wait `RetryAfter`, or
   let `AutoReconnect` handle drops for you.
3. If your code restarts a stopped client, call `Subscribe` again after `Start()`.

The [.NET SDK guide](/docs/dotnet) and the [API reference](/docs/dotnet-reference) cover every option, exception and
limit in detail. If you still run 1.0.x, the [1.1.0 post](/blog/changelog/hftfeed-client-1-1-0) explains what changed
there. Version 1.0.x can no longer reach the feed.


HFTFeed.Client 1.1.1: faster ticks, safer reconnects


HFTFeed.Client 1.1.0, the official .NET SDK for the HFTFeed FIX 4.4 market-data feed, is now
[live on NuGet](https://www.nuget.org/packages/HFTFeed.Client). We rebuilt the client on a plain socket and the feed
server's own FIX codec. The result is a single `net8.0` assembly with no NuGet dependencies. Its receive path can run
without allocating, and its FIX session handles heartbeats and test requests correctly.

```bash
dotnet add package HFTFeed.Client --version 1.1.0
```

## Upgrade now if you run 1.0.x

> **1.0.x can no longer reach the feed.** Version 1.1.0 connects to the feed server in London LD4 on port `9030`.

*Updated 17 September 2026: this post originally named the feed server's IP address, because
`fix-server.hftfeed.com` did not resolve to it at the time. The name has had its own record since 17 September 2026
and is what every client should be configured with — see
[HFTFeed.Client 1.1.2](/blog/changelog/hftfeed-client-1-1-2).*

For most applications the upgrade is a version bump. The client's own API keeps its names, signatures and meaning:
both constructors, `Start()`, `Stop()`, `GetSymbols()`, `Subscribe()` and `Unsubscribe()` with their `All`
variants, the `On…` callbacks, `ConnectionStatus`, `SubscribedSymbolsCount`, `TPS` and `TPM`. Update the package and
rebuild.

Two things went away together with the old networking and sign-in libraries:

- `HFTFeedClient` no longer derives from NetCoreServer's `TcpClient`, and it is now `sealed`. If you called
  inherited members such as `Connect()`, `Disconnect()`, `Reconnect()` or `Send()`, use `Start()` / `StartAsync()`
  and `Stop()` / `StopAsync()` instead, or set `AutoReconnect`. `IsConnected` and `Port` are still there, and
  `Host` replaces the inherited `Address`.
- The public helper classes `MessageBuilder` and `AuthorizationService` are gone. The client builds its own FIX
  messages and signs in for you.

If your code passes an explicit endpoint to the `(email, password, host, port)` constructor, switch to the
two-argument constructor. It uses the default host and port.

## What's new

### No dependencies

1.0.x pulled in three extra NuGet packages for networking, sign-in and token handling. 1.1.0 has none. The
client uses `System.Net.Sockets.Socket` directly and compiles in the same FIX codec the feed server runs, so the
SDK and the server always parse FIX the same way. The package adds nothing to your dependency graph that could
conflict with the packages your application already uses.

### An allocation-free receive path

The client parses ticks with spans, straight out of the socket buffer, with no per-tick strings. Set
`ReuseTickObject = true` and the client passes the same `Md` instance to every `OnNewTick` call, so receiving a tick
allocates nothing at all. The SDK's test suite parses 100,000 snapshots and fails if even one byte is allocated.

Because the instance is reused, copy any values you need to keep before your callback returns. Also leave `OnFixMsg`
unset in production. It builds a string for every frame and is meant for diagnostics only.

### A FIX session that behaves

- `Start()` returns as soon as the symbol list arrives. 1.0.x first sat through about three seconds of internal
  timeouts.
- The client answers the server's TestRequest, so the server no longer drops quiet sessions.
- Heartbeats go out when the session is idle. Set the interval with `HeartbeatSeconds` (default 30; the server
  clamps it to 5–60).
- `Stop()` sends a FIX Logout before it closes the connection, and it is safe to call more than once.

### Async lifecycle

`StartAsync(CancellationToken)` and `StopAsync()` join `Start()` and `Stop()`. The client also implements
`IDisposable`, so a `using` declaration ends the session for you.

### Opt-in reconnect

Set `AutoReconnect = true`, and after an unexpected drop the client reconnects with jittered backoff (0.5 s, doubling
up to 30 s). It then logs on again and restores your subscriptions once per connection. Reconnect is off by
default. A Logout from the server is deliberate, so it never triggers a reconnect.

### Snapshots on demand

`RequestSnapshot(symbolKey)` asks for a single snapshot of one symbol without subscribing to it. The snapshot
arrives on `OnNewTick` like any other tick.

### Richer ticks and live rates

Each `Md` now carries `BidSize`, `AskSize` and `EntryTimeUtc` alongside `Bid` and `Ask`. The sizes are 0 when
the feed does not carry them for a symbol.

`TPS` and `TPM` now count ticks over the trailing second and minute, so a read just after a second boundary no
longer shows 0 while ticks are flowing.

### Errors you can act on

The new `OnError` event receives every error the client handles internally, including exceptions thrown by your own
callbacks. Those exceptions can no longer stop the read loop. `Start()` and `StartAsync()` throw typed exceptions:

- `HFTFeedAuthException`: sign-in failed, or the account has no active plan.
- `HFTFeedLogoutException`: the server refused or ended the session. `Text` carries the server's reason, and
  `IsTooManySessions` tells you the account is already connected elsewhere.
- `HFTFeedTimeoutException`: the connection or the FIX handshake did not complete in time.

### Connection details at hand

`Connected` and `IsConnected`, `Host`, `Port` and `ClientId` report the current session. If your network blocks port
9030, `new HFTFeedClient(email, password, useAlternatePort: true)` connects on port 9031 to the same feed.

## Quick start

Sign in with the email and password of your hftfeed.com account. The account needs an active plan.

```csharp
using HFTFeed.Client;

using var client = new HFTFeedClient("you@example.com", "your_password")
{
    AutoReconnect   = true,   // reconnect and resubscribe after a drop
    ReuseTickObject = true,   // one Md instance for every tick
};

client.OnError = e => Console.Error.WriteLine(e.Message);

try
{
    await client.StartAsync();   // sign in, log on, load the symbol list
}
catch (HFTFeedLogoutException ex) when (ex.IsTooManySessions)
{
    Console.Error.WriteLine("This account is already connected elsewhere.");
    return;
}

// Subscribe by SymbolKey; show SymbolName to people.
var names = client.GetSymbols()
                  .ToDictionary(s => s.SymbolKey, s => s.SymbolName);

client.OnNewTick = t =>
{
    var name = names.GetValueOrDefault(t.Symbol, t.Symbol);
    Console.WriteLine($"{name} {t.Bid}/{t.Ask}");
};

client.Subscribe("1013");   // a SymbolKey from GetSymbols()
Console.ReadLine();

await client.StopAsync();
```

The feed allows one live session per account. Always call `Stop()` or `Dispose()` on a client before you start
another one with the same credentials. If several parts of your application need ticks, share them from one client
inside your process.

## Get it

- Package: [HFTFeed.Client on nuget.org](https://www.nuget.org/packages/HFTFeed.Client)
- Documentation: [the .NET SDK guide](/docs/dotnet) covers events, symbols, subscriptions, reconnect and error
  handling in detail.

If you run 1.0.x, upgrade today: `dotnet add package HFTFeed.Client --version 1.1.0`.


HFTFeed.Client 1.1.0: zero dependencies, allocation-free ticks



## What is FIX Protocol?

FIX (Financial Information Exchange) Protocol is the **language of electronic trading**. It is a standardized messaging format used by financial institutions to **communicate trade-related information quickly and efficiently**.

Imagine FIX as the **WhatsApp for financial markets**, where brokers, exchanges, hedge funds, and banks exchange trade orders, executions, and market data instantly.

## Why Was FIX Created?

Before FIX, traders relied on **phone calls and faxes** to place and confirm trades. This process was slow, error-prone, and inefficient. FIX was introduced in **1992** to solve this problem by allowing **automated, real-time trade communication**.

## How Does FIX Work?


FIX messages are **structured text messages** that follow a specific format. Each message consists of **tags and values** that represent trade details. Here’s an example of a simple FIX message:

```fix
8=FIX.4.2|9=100|35=D|49=BUYER|56=SELLER|55=AAPL|54=1|38=100|40=2|10=123|
```

### Breaking it down:
- **8=FIX.4.2** → FIX version
- **35=D** → Message type (D = New Order)
- **49=BUYER** → Sender (Buyer)
- **56=SELLER** → Receiver (Seller)
- **55=AAPL** → Stock symbol (Apple)
- **54=1** → Side (1 = Buy)
- **38=100** → Order quantity (100 shares)
- **40=2** → Order type (2 = Limit Order)
- **10=123** → Checksum (ensures message integrity)

These tags ensure that all participants **understand the trade details without confusion**.

## Who Uses FIX?

FIX is used by:
- **Banks & Brokers** – To send trade orders and confirmations.
- **Exchanges & ECNs** – To process electronic trades.
- **Hedge Funds & Asset Managers** – To automate trading strategies.
- **Market Data Providers** – To distribute live price data.

## Why is FIX Important?
✅ **Speed** – Trades happen in milliseconds.
✅ **Standardization** – All market participants use the same language.
✅ **Automation** – Reduces human errors and manual work.
✅ **Global Adoption** – Used by nearly all financial firms worldwide.

## Conclusion

FIX Protocol is the **backbone of modern electronic trading**. It enables seamless, automated communication between traders, brokers, and exchanges. If you're working in finance or algorithmic trading, **understanding FIX is essential**.

🚀 Want to learn more? Stay tuned for future posts where we dive deeper into FIX message types, connectivity, and implementation!


Blog

Tutorials, Guides and Updates from the HFTFeed team

HFTFeed.Client 1.1.2: the feed has a stable host name

HFTFeed.Client 1.1.1: faster ticks, safer reconnects

HFTFeed.Client 1.1.0: zero dependencies, allocation-free ticks

FIX Protocol for Dummies: A Simple Guide