FlatBuffer Subscription

RequestWrapper.fbs

namespace fbs;
table LoginRequest {
  ucc: string; 
  token: string; // auth-token 
}

table SubscriptionBlock {
    symbol: string; // symbolName or symName as per syminfo. For Example ZOMATO25FEBFUT (fut in case of utick)
    sub_type: string; // either ["ltp" or "mtick" or "utick"]
    expiry: int; // expiry date in YYYYMMDD format (req only in utick)
}

table SubscribeRequest {
  id: string; // any unqiue string XXXX 
  subscription_list: [SubscriptionBlock]; 
}

table UnsubscribeRequest {
  id: string; // any unqiue string YYYY
  subscription_list: [SubscriptionBlock];
}

// A union for the message types
union RequestType {
  LoginRequest,
  SubscribeRequest,
  UnsubscribeRequest
}

// A wrapper table for the message
table RequestWrapper {
  content: RequestType; // The actual message content
}
root_type RequestWrapper;

This Request is what the backend expects from frontend. So consider it as a client to server messaging schema.

The request can be one of the RequestType: - LoginRequest - SubscribeRequest - UnsubscribeRequest

LoginRequest is what is expected while establishing the websocket connection.

SubscribeRequest is what the client sends to server in case a new message type's subscription is needed. Each subscribe request must have a unique string (id). This id will be returned back in SubscriptionResponse. Each subscribe request must have a subscription_list of SubscriptionBlock type.

sub_type is one of [ltp, mtick or utick] - ltp returns LtpPayload of the symbol - mtick returns MtickPayload of the symbol - utick returns UtickPayload of the symbol (must be a FUT symbol)

UnsubscribeRequest is what is sent by the client to unsubscribe a SubscriptionBlock. Each of these SubscriptionBlock in subscription_list of UnsubscribeRequest should be those which were subscribed before in SubscribeRequest.

ResponseWrapper.fbs

namespace fbs;
table LoginResponse {
  status: string; // "error description" or "OK"
}

table SubscriptionResponse {
    id: string; // same as in subscription request XXXX
    status: string; // "error description" or "OK"
}

table UnsubscriptionResponse {
    id: string;
    status: string;
}

struct Level {
    bid: int; // bid price in paise
    bid_qty: int; // not in lots
    ask: int;
    ask_qty: int;
}

table MtickPayload {
    ltp: int; // in paise
    ltq: int; // not in lots
    levels: [Level];
}

table LtpPayload {
    ltp: int; 
    ltq: int;
}

struct OptionInfo {
    strike_price: int; // in paise
    option_type: byte; // 'C' or 'P'
    ltp: int;
    oi: float;
    volume: int;
}

table UtickPayload {
    iv: float;
    spot_price: int; // FUT symbol's price
    options: [OptionInfo];
}

union MarketDataPayload {
    MtickPayload,
    LtpPayload,
    UtickPayload
}

table MarketDataBlock {
    symbol: string;
    sub_type: string;
    payload: MarketDataPayload; (if NONE then no data update)
}

table MarketDataMessage {
    sending_time: int64;
    seq_no: uint32; // incremental for a connection
    data: [MarketDataBlock];
}

// A union for the message types
union ResponseType {
  LoginResponse,
  SubscriptionResponse,
  UnsubscriptionResponse,
  MarketDataMessage
}

// A wrapper table for the message
table ResponseWrapper {
  content: ResponseType;
}
root_type ResponseWrapper;

Each response message from the server to the client can be one of - LoginResponse (received for each LoginRequest) - SubscriptionResponse (received for each SubscribeRequest) - MarketDataResponse (received continuously after successful subscription) - UnsubscriptionResponse (received for each UnsubscribeRequest)

Additional Notes: - Please note that this websocket standard websocket. We are not using nats for this communication - base uri for connection is : ws://arrow.irage.in:9091