Results 1 to 10 of 18

Hybrid View

  1. #1
    Clarifications of goals:
    8) Move from REST API to Streaming API due to REST API loosing 30% datalines (removing lines with NA).
    9) Being in Streaming API secure candlestick OHLC data. Basically data when each candlestick is closed and do not update more.
    10) In streaming API secure stability if data with 1 minute OHLC data.
    11) If not getting all candlestick lines in streaming API, use the stream to construct the candlestick.

    To summarize: I am using the lightstreamer technique to significantly improve the data quality and stability. However, my tool summarize all the lightstream updates within a candlestick resolution, eg. 5 minutes and stores the closure status of the candlestick.
    Last edited by toolbox; June 20th, 2017 at 11:35 PM.

  2. #2
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,091
    Ok, so point 9) seems to match my assumption in the previous post.
    But operating on the client side to reduce the updates of candlestick data to only the ones related to candlestick close seems impossible to me. For sure, you cannot achieve that by leveraging LS_requested_max_frequency.
    I think that your only possibility is to:
    • subscribe normally and read all updates,
    • keep the state of the current candlestick by integrating the updates,
    • however, whenever an update carries a new timestamp value, save the previous state as a full candlestick and clear the state to prepare for the next candlestick (but the incoming update should itself take care of the clearing).


    I cannot understand point 10), but it seems just a reinforcement of point 9).

    I also can't understand point 11). So far, the problem seems that, in streaming API you get more lines than needed, not fewer.
    Perhaps you mean that if you cannot satisfy point 9) you have to give up subscribing to candlesticks and subscribe to ticks only and use the ticks to build the candlesticks yourself on the client side. Guidance on this is obviously out of our scope as Lightstreamer support.

  3. #3
    Yes, I understand that the guidance is limited, but I think it might be valid to keep the thread open so I can potentially update it. I assume that it is of benefit for Lightstreamer as a product that the users creates clients that are not officially released nor supported to empower and grow the usage of Lightstreamer.

 

 

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 04:57 PM.