Changelog


There is a new section in your account: [Signals](/signals). A signal is the moment our published price has moved
and at least one of the other price sources behind it is still quoting the old price. Every signal shows which way
the price went, how big the gap was, how long it stayed open and how many sources lagged. You see them live, and you
can go back through the last 30 days.

## What a signal is

We watch every source we take prices from. A signal fires when two things are true at once:

- **Our published price moved** at least 3 times its own typical spread.
- **Another source has not followed:** it is behind by at least that much, and by at least 2 times its own spread,
  so a gap that is only the source's spread never counts.

There is one signal per move on a symbol. It stays open while the slow sources catch up, for at most 300 ms, and
then closes with the reason: all sources caught up, the window ran out, or the move faded or reversed. If a source is
still on its old price when the window closes, we keep watching it for up to 5 seconds and record when the gap
finally closed.

Nothing is delayed or batched. A signal is detected in our London (LD4) server in microseconds, on the same tick that
triggered it.

## What each signal tells you

| Field | Meaning |
|---|---|
| Direction | ▲ the price moved up, ▼ down |
| Gap | The gap when the signal fired and the largest it reached, in points |
| Gap window | How long the gap stayed open: from the signal until the slowest source caught up |
| Strength | How many live sources lagged, for example 2/7 |
| Price at signal | Our published bid and ask at that moment |
| Outcome | All caught up, window cap, faded or reversed |

Sources are numbered the way they are on the tick chart: Source 1, Source 2 and so on, in the order the symbol uses
them.

## Five views

- **[Overview](/signals):** every symbol in one table, with an ON / OFF light that says whether the last 15 minutes
  looked tradeable at your own execution speed (see below), the best hour of the day, when signals cluster through
  the week, how long gap windows last, and which source tends to be slowest.
- **[Live](/signals/live):** new signals as they happen, with filters for direction, strength, gap size and gap
  window.
- **[Explorer](/signals/explorer):** any signal from history, on a tick chart centred on it, with ← and → to step to
  the previous and next one. Each signal has its own link you can share.
- **[Heatmap](/signals/heatmap):** one row per symbol, one column per time slot, coloured by direction and
  intensity. From the last 15 minutes in 5-second slots up to 30 days in 4-hour slots.
- **[Best](/signals/best):** the biggest, longest and strongest signals per symbol for the last hour, day, week or
  month.

<Image src="/assets/images/posts/latency-signals/explorer.jpg" width={1200} height={739} alt="Explorer: a GER40 signal centred on the tick chart, with the gap window shaded and every lagging source listed" />

<Image src="/assets/images/posts/latency-signals/heatmap.jpg" width={1200} height={945} alt="Heatmap: every symbol over two hours in one-minute slots, coloured by direction and intensity" />

<Image src="/assets/images/posts/latency-signals/best.jpg" width={1200} height={647} alt="Best: the ten largest signals per symbol for the last 24 hours" />

## Your execution settings

Whether a signal could have been traded depends on how fast your orders reach the broker and what they cost you.
Set both once, under **Execution** in the Signals pages (we start you at 50 ms and 0.1 bps of slippage per side), and
every view uses them:

- A signal counts as **tradeable** when at least one source stayed on its old price longer than your execution time,
  and its gap was bigger than that source's spread plus your slippage on the way in and out.
- The **ON / OFF light** turns on when a symbol has had at least three tradeable signals in the last 15 minutes and
  its windows are, in the middle, longer than your execution time. It goes off when the windows get shorter than your
  execution time or the gaps fall below your costs, and the reason is shown next to it.

<Image src="/assets/images/posts/latency-signals/overview.jpg" width={1200} height={215} alt="Overview: how long GER40's gap windows lasted, with the share that stayed open longer than a 50 ms execution time" />

Signals record differences between price sources. They are an observation of market data, not a trading
recommendation, and a quote can change before an order reaches it.

## On the tick chart

Signals are drawn on the [tick chart](/chart) as well: a shaded band for the window and an arrow labelled with the
gap, the window and the strength. A **Signals** switch in the toolbar turns them on and off. The chart loads its
ticks first and the signals right after, and new ones appear as they happen.

## All sources on one price level on the chart

Sources quote the same instrument at slightly different levels: an index CFD built on the futures price sits a few
dozen points away from one built on cash, and brokers mark up differently. The server now learns each source's offset
against the first source of the symbol and draws every source on that level, so the lines on the tick chart overlap
the way the market actually moves.

This is a chart view. The feed itself does not change: every tick of our primary source is published the moment it
arrives, at its own price. A new source appears on the chart once its offset has been learned, about a minute after
it connects, and the learned offsets survive a restart of the server.

Two smaller chart changes come with it:

- **A line only breaks when its source is down.** A source that is connected but whose price has not changed simply
  holds its last price, however long that takes.
- **A source that is still learning its offset shows "waiting"** instead of a price at the wrong level.

## How far back

| Data | Kept |
|---|---|
| Signals | 30 days |
| Ticks (tick chart, Explorer charts) | 7 days |

A signal older than 7 days still opens in Explorer, with all its numbers, but without the ticks around it.


Latency signals: see when one price source is still quoting the old price


If your strategy sends orders through a Terminal 4 or Terminal 5 broker, the distance between your VPS and the
broker's trade server is part of every order's round trip. [Broker Infra](https://forexinfra.hftteam.com) tells you
where that server is. It is a separate research site, published as FX Broker Geolocations, and it is included with
every active paid HFTFeed plan.

## What it shows

- **Where every published server is.** Terminal 4 and Terminal 5 brokers list their trade servers publicly.
  Broker Infra reads those lists, resolves every hostname and places each address in a city, with its hosting
  provider or network and, where the provider publishes its address ranges, the cloud region.
- **Who shares infrastructure with whom.** Brokers that publish the same addresses, the same ports or the same website
  are shown as sharing infrastructure, with the evidence next to the claim: which addresses, which ports, which
  website.
- **The main hosting zones of the industry.** A colocation shortlist ranks metro areas by the live servers hosted
  there, with the main provider in each.
- **A Monitor of changes.** New brokers, brokers no longer published, servers that moved to another city or
  provider, and regulation changes, written as one story per broker per daily refresh.
- **Declared regulation.** The regulation status each broker declares in its public broker profile, labelled as
  declared.

The data is refreshed once a day. The history starts from a snapshot of 18 May 2026, and the daily Monitor has run
since 12 October 2026.

## The industry in numbers

As of mid-October 2026, Broker Infra tracks more than 4,000 Terminal 4 and Terminal 5 brokers, running over 9,000
servers (about 6,300 of them live) on about 20,000 addresses in more than 70 countries. About half of those brokers
belong to one of nearly 600 groups that share infrastructure.

Hosting is concentrated in a few places. The top of the colocation shortlist, by share of the live servers whose
location is known:

| Metro area | Share of live servers |
|---|---|
| London | 62% |
| Hong Kong | 31% |
| Singapore | 28% |
| Amsterdam | 22% |
| Frankfurt | 18% |
| Tokyo | 17% |
| New York | 15% |

The shares add up to more than 100% because a server published in two places counts in both. By provider, AWS
carries about 38% of live servers, Alibaba Cloud about 22% and Microsoft Azure about 17%. The busiest single cloud
region is AWS eu-west-2 in London, with about 17%.

## Why it matters for your setup

Where you put your VPS sets the round trip to your broker on every order. Broker Infra tells you which city your
broker's live servers are in and on which provider, so you can pick a VPS location from data rather than from a
guess. The Monitor tells you when that answer changes, for example when a broker moves its live servers to another
city.

HFTFeed's FIX server is in Equinix LD4, London (see [how a connection works](/docs/intro)). As the FAQ on our
[home page](/) puts it, co-locating in LD4/LD5 or any London facility with a cross-connect puts you under a
millisecond from the feed. With more than 60% of live broker servers in the London area, one London VPS can often sit
close to both your feed and your broker. Broker Infra shows you whether your broker is hosted there.

## Who gets it

- **Included with an active paid HFTFeed plan,** monthly, yearly or lifetime, at no extra cost and for as long as
  the plan is active. Plans and prices are on the [pricing page](/pricing).
- **The 24-hour trial does not include it.**
- **Without an HFTFeed plan,** Broker Infra costs $49 per month, paid in crypto; card payments are planned. Each
  payment adds one month, and nothing renews automatically.

## Signing in

There is no new account to create. On Broker Infra's sign-in page, choose **Sign in with your HFTFeed account** and
use the same email and password you use on hftfeed.com. Your password goes from your browser straight to HFTFeed's
sign-in service, and Broker Infra never stores it.

## What it does not tell you

- **Locations are city-level estimates** from IP geolocation, not building addresses.
- **Regulation is declared, not verified.** It repeats what the broker states in its public broker profile and is
  not checked against any regulator's register.
- **Shared infrastructure is not ownership.** Brokers end up on the same addresses for many reasons, a common
  technology supplier among them.
- **Distance is not latency.** Broker Infra does not measure round-trip times. Test from a VPS before you commit to
  one.
- **Only published servers are covered.** A broker can run servers it does not list.

## Open it

[Sign in with your HFTFeed account](https://forexinfra.hftteam.com/login) on Broker Infra. If your plan does not show
as active there, or you have a question about access, write to us through [support](/helpdesk/support) or use the
chat at the bottom right of every page.


Broker Infra: where Terminal 4 and Terminal 5 brokers host servers, included with HFTFeed


There is a new page in your account: [Candles](/candles). It draws the same prices your FIX session receives as
candlesticks, in eleven timeframes, with a volume strip underneath. It sits next to the [tick chart](/chart) in the
menu and needs nothing more than a plan in force, a trial included.

## What it shows

- **Eleven timeframes:** 5s, 15s, 30s, 1m, 5m, 15m, 30m, 1H, 2H, 4H and 1D.
- **Bid, ask or mid.** Both sides are stored as full OHLC, so switching is instant and the ask candle is the real
  ask, not the bid shifted by a spread.
- **Volume is the tick count:** how many prices we published inside the bar. We do not see traded size, so we do not
  pretend to.
- **The bar that is forming moves live,** about once a second, and closes on its own. No refresh.
- **Scroll back and it keeps going.** Older bars are fetched in the background before you reach the edge.

Every symbol on the [symbol list](/symbols) has candles, all 45 of them.

## What a candle is made of

One rule: a candle is built from the prices we **published**, the ones that went out on the wire, and from nothing
else. Open is the first published price in the bar, close the last, high and low the extremes, volume the count.
If you rebuild a bar from your own FIX log you should get the same numbers, give or take a tick that lands exactly
on a bar's edge.

A bar with no published price does not exist. We do not draw flat candles through a quiet minute or a closed
market, so on a slow symbol a 5-second chart has gaps, and that is the honest picture.

## The trading day starts at 17:00 New York

The 1D, 4H and 2H candles follow the FX convention: the day rolls at 17:00 New York, not at midnight UTC. That gives
five full daily candles a week, with Sunday evening's first hours belonging to Monday's candle, the way most FX
platforms draw it. In UTC the roll is 21:00 in summer and 22:00 in winter; the 4H bars count from there
(21:00, 01:00, 05:00 and so on in summer).

For everything except crypto, candles pause from Friday 17:00 to Sunday 17:00 New York. Crypto trades through the
weekend and has candles for every day of it.

## How far back

| Timeframes | History kept |
|---|---|
| 5s, 15s, 30s | 7 days |
| 1m and longer | 1 year |

The history starts in early October 2026, so the longer timeframes fill in as the weeks pass. The first week was
rebuilt from our stored ticks, which keep price changes only; its volume therefore reads a little lower than the
live bars that follow, which count every published price.

For anything finer than five seconds, the [tick chart](/chart) is still the place: every published tick, and each
source behind it, for the last seven days.

## Also new since September

- **A 24-hour trial for $50.** Three symbols (EURUSD, GBPUSD and XAUUSD) over the real FIX connection, starting
  from your first logon. The $50 is credited toward your first plan if you subscribe within seven days of the
  trial ending. Start one from the [trial page](/trial).
- **HFTFeed.Client 1.1.3** is [on NuGet](https://www.nuget.org/packages/HFTFeed.Client). It accepts trial accounts;
  1.1.2 refused them before opening a connection. If you are on a paid plan, nothing changes for you.
- **Fixed published spreads.** Each symbol is now published with a fixed spread, so a wide moment upstream no
  longer reaches your session.
- **Yearly and lifetime plans** joined the monthly one. The monthly price is $300 today and $499 from
  1 November 2026; the details are on the [pricing page](/pricing).
- **A daily feed report by e-mail:** how many prices we took in and published the day before.
- **Support chat** on every page, bottom right. It reaches the same people as the [support](/helpdesk/support) form.
- **Sign-up confirmation links** that hung on "loading" for some browsers are fixed.

## Not yet

Candles are on the website only. There is no public candle API for your own code yet; if that is something you
would use, tell us through [support](/helpdesk/support), because it decides what we build next.

## Try it

Open [Candles](/candles), pick a symbol and a timeframe. The **Ticks** button in the toolbar jumps to the tick chart
for the same symbol, and back.


Candles: the feed as OHLC, from 5 seconds to a day


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/Changelog