wjdhamilton / ig-haskell Goto Github PK

There is no reason for the client to write back to the channel which a realtime subscription is using. According to the docs:

The problem with using newTChan to create the broadcast channel is that if it is only written to and never read, items will pile up in memory. By using newBroadcastTChan to create the broadcast channel, items can be garbage collected after clients have seen them.

https://hackage.haskell.org/package/stm-2.4.4.1/docs/Control-Concurrent-STM-TChan.html

A recurrent problem in my trading application is that a data connection silently fails - usually when waiting for an update to arrive from the server.

The heartbeat has been noted to provide stability to incoming connections since it keeps the session alive at the IG end. However, a subscription to the heartbeat may overcome these issues by keeping the mechanism turning over at the IG end.

The practical uses of these two values are achieved by the listen function which is internal to the module...

The lightstreamer server returns a timeout value on subscribing, but I think I was misusing it since the app said a timeout had occured far too frequently. So I removed it in #8.

This is not a complete fix, since the value is now being ignored. Investigate it and find out how to use it.

The IG realtime feeds have a predefined group of fields, and the content of any subscription is provided in a consistent, structured manner.

So it should be possible, therefore to create a class which represents things that can be read from a Lightstreamer feed. Call it RTEntity for now.

The general structure of the data returned for an update (which is what we are interested in from the perspective of data feeds is:

table + "," + item + "|" + values + "\r\n"

Where table is the number of the table

item is the number of the item within the table assigned by the Metadata adapter during the subscription operation

values is a pipe-separated list of the values corresponding to the schema.

For example:

2,1|17.48|1.68|14:32:48
1,1|16.6|3.16|14:32:49
1,1|||14:32:50
2,1|17.47|1.62|14:32:50

In an idea world, the object would map the different values by their field names, but this may not be possible since that information is not available when the channel is initially created in openSession.

The most obvious solution would be to use something like this:

data StreamContent = Update Int Int [Text]

Network protocol tutorial page 30

This is easy for spreadbet positions:

(currentLevel - dealLevel) * contractSize * size * dir

where dir = 1 if the direction of the trade is BUY and -1 if SELL

Network protocol tutorial page 29