Thanks for clarification. Right, the actual market data is a continuous very non-uniform timeseries. If you wish to receive trades in such continuous Times & Sales form, all you need to do is to include in the list of implemented interfaces TradeDataListener and implement onTrade(), for instance:
Code: Select all
@Layer1SimpleAttachable
@Layer1StrategyName("My Custom Module")
@Layer1ApiVersion(Layer1ApiVersionValue.VERSION1)
public class MyCustomModule implements CustomModule, TradeDataListener {
int lastTradeSizeOnBid;
int lastTradeSizeOnAsk;
@Override
public void onTrade(double price, int size, TradeInfo tradeInfo) {
if (tradeInfo.isBidAggressor) {
lastTradeSizeOnAsk = size;
} else {
lastTradeSizeOnBid = size;
}
}
@Override
public void initialize(String alias, InstrumentInfo info, Api api, InitialState initialState) {
}
@Override
public void stop() {
}
}
mdtrader wrote: ↑Wed Nov 14, 2018 2:55 pm
...here in Bookmap you have a continous flow of executions, is this the reason you need this "nanoseconds-variable" to cummulate the volume within
Well, there may be many thousands trades per second and dozens of thousands market depth updates per second. But even that doesn't require the granularity of nanoseconds. The simplest answer is this: whether you use milliseconds, microseconds, or nanoseconds, it still requires 64-bit integer (long). Even seconds resolution will require 64-bit in several years )). So, there is no any downside of using nanoseconds by default. But there are definitely some advantages. Here is a more detailed answer:
https://bookmap.com/wiki/Market_Mechani ... in_Bookmap.