1) If I want to write three applications for EQ, Fut, Opt on same machine(same IP Address), then I need to open three web socket connections using SAME KEY. Do u allow multiple active web socket connection at same time from SAME or MULTIPLE machines using SAME KEY ?
2) I am still not clear about how u push tick data. For example, if I open web socket connection for 100 scrips and at time "t1" only 10 scrips are traded. Then a) Are u going to push 10 tick trades only OR b) Are u going push tick data for all 100 scrips where for 90 scrips data will be old(prev tick data) OR c) Are u going to wait for ticks in all 100 scrips before sending data AND hence in one packet we can have multiple ticks for same scrip
3) At what time granularity NSE operates. Is it nanosecond/microsecond or even multiple trades can happen in one nanosecond for same instrument ?
4) If I have web socket connection open for most liquid 100 scrips(tick data) for whole day(market hours) [four of which are Nifty Future, Bank Nifty Future, Nifty, Bank Nifty] then whats approximate data I would have downloaded for a day. Is it in multiple GBs ? It might be hard to answer this but can u please give rough estimate of tick data size for most liquid 100 scrips for whole day
1) We do not limit this as of now, but we may introduce a connection limit in the future. The correct way to do this would be to open a central connection and use that for managing all subscriptions.
2) Right after you send one subscription request for 100 instruments, you'll get one or more ticks (last value cache) for all those. If this is during market hours, it'll be the last live tick, if it's during off-market hours, the last ever tick.
Ticks are streamed to you as they arrive from the exchange. There is no waiting. The messages you get, they may contain tick packets for one, many, or all instruments, depending on market activity.
3) Nanoseconds and microseconds are impossible over the internet. We stream sub-second ticks (700ms-1s), although exchanges may have varying frequencies. If you are concerned about microsecond level speeds, co-location with the exchanges is the only solution.
4) It will not be in GBs. Assuming you're subscribing to a full quote packet (164 bytes). TCP+protocol overheads, let's say, 100 bytes (will not be this much for sure, but still), that's 264 bytes in total per instrument for 6.5 market hours. So 264 * 100 * (6.5 * 60) = 10.2 MB, which is negligible.
Thaks Kailash for detailed reply so 3) So one packet can have multiple values for same scrip as 10 trades can happen in 700ms 4) Your cal assumes 1 trade per MINUTE, asuming 1 trade per 500ms then it should be 10.2 * 60 sec/minute * 2 trades per sec = ~ 1.2GB ... Please correct me if I am wrong
3) For one scrip, you'll ideally get 1 tick per 1000ms (700 is rare). You can approximate to 1 tick / scrip / second.
4) Ah yes, you're right. I was off by an order of magnitude! The correct calculation would be 264 * 100 * (6.5 * 60 * 60) = 617.76 MB, which is significant (again, my bad). However, in reality, it should not amount to this much as 100 scrips may not produce 1 tick every second non-stop.
2) Right after you send one subscription request for 100 instruments, you'll get one or more ticks (last value cache) for all those. If this is during market hours, it'll be the last live tick, if it's during off-market hours, the last ever tick.
Ticks are streamed to you as they arrive from the exchange. There is no waiting. The messages you get, they may contain tick packets for one, many, or all instruments, depending on market activity.
3) Nanoseconds and microseconds are impossible over the internet. We stream sub-second ticks (700ms-1s), although exchanges may have varying frequencies. If you are concerned about microsecond level speeds, co-location with the exchanges is the only solution.
4) It will not be in GBs. Assuming you're subscribing to a full quote packet (164 bytes). TCP+protocol overheads, let's say, 100 bytes (will not be this much for sure, but still), that's 264 bytes in total per instrument for 6.5 market hours. So 264 * 100 * (6.5 * 60) = 10.2 MB, which is negligible.
3) So one packet can have multiple values for same scrip as 10 trades can happen in 700ms
4) Your cal assumes 1 trade per MINUTE, asuming 1 trade per 500ms then it should be 10.2 * 60 sec/minute * 2 trades per sec = ~ 1.2GB ... Please correct me if I am wrong
4) Ah yes, you're right. I was off by an order of magnitude! The correct calculation would be 264 * 100 * (6.5 * 60 * 60) = 617.76 MB, which is significant (again, my bad). However, in reality, it should not amount to this much as 100 scrips may not produce 1 tick every second non-stop.