WsRtd - Websocket-Json standard Data plugin - Test Release

Plug-ins
167

Hello, very interested in this, would be willing to test and report as necessary.
Are there any files available for download yet?
Thanks

1 Like
168

Hi Thanks for the dll, been very busy with it. Excellent project and i am quite excited by the prospects.

I’m integrating a custom feed from Tai Pan into AmiBroker using the WSRTD plugin and a Python bridge. I have a few questions where the docs/forum posts aren’t completely clear:

  1. Volume and Trade Size in RTQ
  • From the WSRTD JSON spec, RTQ format allows fields:
    {"n","d","t","o","h","l","c","v","oi","x1","s","pc","bs","bp","as","ap","do","dh","dl"}
  • I understand that:
    • v = cumulative traded volume (must grow with each tick)
    • x1 = trade size (delta between feed’s current cumulative volume and previous tick)
    • s = sticky daily volume from feed
  • In practice, I see that AmiBroker shows static volume and blank trade size in RTQ window, even though I’m sending both fields. Can you confirm the expected mapping the plugin uses internally? Should x1 be treated as per-trade size, or does the plugin expect something different?
  1. Symbol Full Name / Metadata (cn)
  • My feed also provides a company name (e.g. "cn":"Adyen N.V.").
  • When a new symbol is added to AB via Retrieve, I notice the “Name” column is filled with the ticker (same as n) instead of the provided company name.
  • Is the plugin supposed to use the "cn" field to populate the “Full Name” in AB? Or is this ignored?
  1. Populating Master Symbol Metadata via JSON
  • I was hoping to use JSON backfill as the “master” to populate not just price/volume, but also metadata (alias, company name, float, ISIN, etc.) every morning.
  • From testing, it seems only n is used to create the symbol in AB, while other metadata fields are not stored. Is that correct?
  • If so, is there any supported way (via JSON-HIST or CMD messages) to push symbol metadata into AB automatically, instead of ASCII imports or manual edits?

I want to make sure I’m not misusing the fields, so any clarification would help.

Thanks!

1 Like
169

Thanks for your kind words. The project was purely for personal needs but I'm happy to advance it.

  1. Volume
    x1, x2 is meant for Aux1, Aux2 fields
    currently, the plugin is in 1-min base timeframe so the bars are built in your client-APP
    Ticks may be received say every 1-second so you accumulate volume in your app but send the json RTD everytime there is an update in client-app side
    "s" is total daily volume, which you can accumulate or receive from your data source and "pc" is required which is previous day close that AB uses to calculate the percentage change of a ticker.

So tradesize is calculated internally from current volume received - prev cached vol in the plugin.

When you send RTD json, these fields are present in each tick, so example DH / DL / PC etc will be present in every packet. Think of it as json snapshot of your client-app status being sent.
If I were to cache these, it would complicate, and lot of CPU IF-ELSE branching would probably hit performance.

For #2, let me check and get back.
For #3, for now it is not implemented. I will work on it. you can use OLE/ASCII import for bulk edits.

170

Regarding #2,#3,
it seems to be the default behaviour of ADK, in
struct StockInfo* (*AddStockNew)( const char *pszTicker );
ie. where SYMBOL is copied to Full Name.
After AddStockNew, we are supposed to update the StockInfo fields with relevant data.

For #2 to work like you want, the full #3 has to be implemented.
This requires a new json command or a full json structure.
So for now, you have use manual/ole/ascii methods.

Basically, the plugin DB needs to implement struct StockInfo from ADK. No timeline or promise, but it is doable.

171

Thanks very much. My idea is to load say, 150 symbols in each day, containing some metadata like Co Name and alias, this so i can use IBKR as broker to trade using the IBKR symbol in the alias field. Until this, I will have to import the exact same symbols using ASCi import and alias field and then run the new plugin with the same symbols. Thanks a lot for your efforts so far. When I have my client and feed code working should i post on here?
Cheers

172

Better to repo Client-app on GitHub, so you can collaborate with other similar users.
Unfortunately so far, except 1-2 testers, no client-app has been posted.
It would help those who are unable to wrap their Broker/Data source WS.

Implementing the CoName / Alias comes under Symbol Information, so as I wrote above, I have to implement the whole thing. Whether 1 field or many, its the same effort.

2 Likes
173

Out of academic interest, can I ask why you chose the relay server method? Is it because you wanted this plugin to be generic, capable of supporting multiple data sources?

174

If you see the Docs, there are both approaches, relay server AND server hosted within Client-App

The preference for relay is AB can have multiple instances open without complaining of connection drops.

Also, it was part of an idea where user can connect an external DB and use that to access local data

Simplify logic for users writing Client-App, they just need to write client side code (not server code)
Client-App being lighter can be written in any language of choice

Another important reason, multiple Client-App can be used, individually or simultaneously.
You can't do this if server is hosted inside Client-App for multiple apps.

2 Likes
175

Got it.

Thank You.

176

@chrisnoy

Have a look at this

Introduced a new json structure "info", corresponding to ADK struct StockInfo and Symbol Information in AB UI.

Added some fields, I'm testing and hopefully share the build this week.

No extra step for the user, info is updated when they click Retrieve from DB > Plugin settings. (The dark green notification)

2 Likes
177

That's great, look forward to testing it !

178

So, thanks for the updated plugin, I am actively testing it, but i am getting a bit bogged down in getting the hist data out from my vendor. So i'll plod on and report back here when i have news. Thanks again for your prompt action adding the new additions to json script.

179

Subject: INFO metadata now working – Tai Pan + WS_RTD + IBKR integration

After several weeks of development and testing, I now have a fully working integration between Tai Pan Euronext data, WS_RTD, and AmiBroker, complete with INFO metadata, historical backfill, and real-time quotes.

:white_check_mark: What’s Working

  • INFO JSON: Each symbol now imports with metadata — Full Name, Alias, Address, ISIN, and Market (integer).
  • HIST backfill: 30 days of clean, chronological 1-minute bars (no gaps, no dashes).
  • RTQ passthrough: Real-time ticks flow correctly with full o/h/l/c/v + bid/ask fields.
  • Previous Close (“pc”) Fix: The Tai Pan API does not include previous close in its real-time stream, so this value is now added explicitly — ensuring correct display in AmiBroker’s RTQ window and enabling breakout logic based on the prior close.
  • Symbol import: 173 Euronext symbols load from CSV, each creating an AmiBroker entry with INFO fields populated.
  • IBKR link: The Alias field provides symbol mapping for execution through IBKR.

:gear: Setup Overview

  • Feed: Tai Pan API (TPRAccess) → C# WebSocket Feed (ws://localhost:10103)
  • Bridge: Python client (ws://127.0.0.1:10101) → connects to WS_RTD plugin
  • Plugin: WS_RTD v7.0 x64 for AmiBroker
  • Database: Coretest (Euronext data)

The bridge handles three data streams:

  • RTQ – forwards live ticks unchanged, injecting previous close when missing.
  • HIST – aggregates raw ticks into 1-min bars (oldest → newest) and trims large payloads under 1 MB safely.
  • INFO – loads from coretest.csv and sends one JSON object per symbol when AmiBroker [requests it via “Retrieve.”

:light_bulb: Objective

The goal is to:

  • Load 173 Euronext stocks from cold start, all with metadata.
  • Trade them intraday using IBKR (via Alias link).
  • Use 30 days of accurate backfill for replay/breakout systems.
  • Display correct “Prev Close” values in AmiBroker’s RTQ window — previously missing from Tai Pan data.

:receipt: Code

The full Python client bridge and C# feed source are on GitHub:
:backhand_index_pointing_right:](GitHub - chrisnoy/TP-WSRTD-Client: Tai Pan WebSocket RTD Client for AmiBroker – includes C# Feed Server and Python Bridge with INFO metadata integration.)

Thanks to nsm51 and everyone who helped clarify the INFO and HIST integration — adding the missing “Prev Close” value finally makes the Tai Pan → WS_RTD → AmiBroker chain complete.

6 Likes
180

Good job!
Happy to see this expansion, this is the ultimate goal!
Many users unable to bridge their vendor WS to AB and each client-app customization fills the gap.

4 Likes
181

Hi @nsm51,
could you please share me how to download the WsRTD.dll, i have searched in the github did not found it. could you please help me how to download the plugin.

regards
Kadesh j

182

Thanks for sharing great plugin @nsm51. i have tested. it is working beautifully. thank you very much. :heart:

183

Hi there, using my setup to trade, I have come up upon a strange problem with the new plugin (for INFO). The volume and trade size fields in the RTQ window have become large and getting larger. After many hours of tests I managed to swap the dll's over and now using the original there is no problem. Sorry I didn't pick this up before but it wasn't obvious until i used the setup for a few days. Let me know if you need more on this. Thanks

185

ok i found the issue, it had something to do with
iTotalVol, iTradeVol and their floating counterparts.
I over optimized some code.

sent you the fixed build.

186

Thanks for the new dll. I will test when i sort my present problem out. I am getting loads of retrieval requests every few seconds, and the full number or a large number of symbols getting loaded, but these are already in the DB. Whilst I am debuging, I wonder if you could confirm the following questions? -

  1. Does the vendor need to delay JSON after sending rolesend, or can it send JSON immediately?
  2. What exact cping reply does the plugin require to stop issuing Retrieve/DoS?
  3. Does the relay ever filter or mis-handle cping messages when they come too soon after rolesend?.
    Does having , say 171 symbols, tick data, running all the time affect the dos event? .

Maybe some sort of symbol list needs maintaining by the client?

Thanks

187

DLL you can easily swap-out, it was just 2 line change which caused the Vol/TradeSize issue

In DB settings, "Local Storage" : "Enabled" <- it should be enabled.

Are you using the RELAY SERVER model?
If plugin is disconnected, then the AUTO-BACKFILL data it maintains is cleared out.
It is similar to internet disconnection.

During AB lifetime, if plugin is not disconnected, there is only 1 BFFULL or BFAUTO request sent per symbol.
BFFULL is there is NO data, else BFAUTO with last BAR timstamp to optimize the backfill.

If you use relay server, AB will be open and connected for 1 month without complaining. I only restart AB because of Windows Updates.

This is by Design, because once plugin disconnects, there is no way to know if data is missing, so it will generate AUTO BF requests.

Q&A:

  1. rolerecv is sent by plugin to RELAY.PY, rolesend is "first" packet sent by CLIENT-APP. This is only useful in RELAY model, else these are of no use.

Again, are you using Relay server?

  1. cping is not mandatory, it was used by another user to determine in AFL, if CLIENT-APP is disconnected.
    Also, client-app can send this and get reply to make sure AB is running.

  2. Relay server should always be kept running, and the first script to start.
    rolesend should be the first packet relay should get so that it can MAP the routing.

I tested with 1000 concurrent symbols RTD blast/second, there is NO issue in relay or AB.
300 symbols in RTQ. IT is a mid-range laptop i7(4c-8T)

Client-App maintains list, also build 1-min candles, don't just forward request to Vendor server.
On AB side, avoid plugin disconnections because even if you were connected to internet, you won't know if data is lost or not.

1 Like