CASE1] Assuming that I have order updates using the websocket "on_order_update(ws, data)" api then: 1) In case of a Websocket disconnection and re-connection further say after a few attempts; does the order postback data on websocket get lost for that much amount of time? => PLEASE CONFIRM THIS 2) Even if lost for 1 sec and after the re-connection will the "on_order_update(ws, data)" api return the "DOES IT SEND LAST STATUS" of that order?? (Although I know name does not warrant for this!!) => PLEASE CONFIRM THIS WHICH IS CRUCIAL
If DOES NOT SEND LAST STATUS then I will have to use "polling method" with "def order_history(self, order_id) " api.
CASE2] How is the "number of attempts = 3 max per sec" considered? 1) I use a margin call api with upto 3 attempts within 1sec max if earlier fails 2) I use order api to place order with upto 3 attempts within 1sec max if earlier fails 3) I use order_history api to see status with upto 3 attempts within 1sec max if earlier fails
Will my account get locked or its OK. => PLEASE CONFIRM THIS WHICH IS CRUCIAL
In case of a Websocket disconnection and re-connection further say after a few attempts; does the order postback data on websocket get lost for that much amount of time?
on_order_update(ws, data) gives you the streaming updates(i.e only when your Websocket connection is connected live). All Websocket methods are streaming based not store and fetch based. So, you get only live data post connection, no previous data.
Even if lost for 1 sec and after the re-connection will the "on_order_update(ws, data)" api return the "DOES IT SEND LAST STATUS" of that order?? (Although I know name does not warrant for this!!)
No,as stated above.
How is the "number of attempts = 3 max per sec" considered?
The rate limit is decided per API key/user level, not for specific API method calls. So, you shouldn't exceed the rate limit per second combining all our requests made for that specific interval.
Will my account get locked or its OK.
No, you will receive rate limit http error 429 Too many requests with failed request.
But regarding the rate limit criteria => "The rate limit is decided per API key/user level, not for specific API method calls. So, you shouldn't exceed the rate limit per second combining all our requests made for that specific interval."
Q] At any given time span of "1sec" there could be at least 3 api calls for a "single user key" like; a) margins api => 1 attempt b) place_order api => 1 attempt c) order_history api => 1 attempt
So in case of a failed response this leaves no room for reattempt of the api within 1 sec since the per user per 1sec max limit is "just 3 calls" (Well "margins api" can be discounted but still there is no room to reattempt!!!)
@rakeshr , @sujith PS. (Consider this as a part of suggestive enhancement / user's perspective) 1] Frankly speaking this "on_order_update(ws, data)" callback should return the last updated OMS data upon every connect; whether its the 1st connect or subsequent reconnects. a) On 1st connect => Return NULL b) On subsequent reconnects => Return NULL or the last updated OMS data
Usage :: We can use this instead of order_history api where requests have rate limits and ultimately loads your system!! Also not good from coding point of view!!!
Why so :: Since even if there is small % chance of websocket disconnection by virtue of any reason (However good a coder is there are other uncontrolled parameters also) we are leaving this loss of "EXTREMELY IMPORTANT DATA" totally unhandled!! This on_order_update is after all "only receive enabled" interrupt (as we call them in embedded).
At any given time span of "1sec" there could be at least 3 api calls for a "single user key"
The rate limit is decided per API key/user level
Here, what we meant by per API key is you can't spin multiple programs using the same API key and making the same request from multiple sources at the same time. Eg. The rate limit for order place API is 10r/second, so if you spin 3 different program source, which uses same API key, but with different strategy/calculation to place an order, so it can happen that at any instance more than one source(eg.here 3) can try to place an order with 5,6 and 3 orders of that particular second and requested API will be rejected with rate-limited for 2nd and 3rd source, even though you are making less than 10 r/s i.e 6 and 3 request for that second. So, basically API rate limit is a combination of API key and specific method API call.
So in case of a failed response this leaves no room for reattempt of the api within 1 sec since the per user per 1sec max limit is "just 3 calls"
on_order_update(ws, data)gives you the streaming updates(i.e only when your Websocket connection is connected live). All Websocket methods are streaming based not store and fetch based. So, you get only live data post connection, no previous data. No,as stated above. The rate limit is decided per API key/user level, not for specific API method calls. So, you shouldn't exceed the rate limit per second combining all our requests made for that specific interval. No, you will receive rate limit http error429 Too many requestswith failed request.If you repeatedly offend the system and system flags you then RMS might block your app. So make sure you don't exceed rate limits.
Thanks for your generous responses.
But regarding the rate limit criteria =>
"The rate limit is decided per API key/user level, not for specific API method calls. So, you shouldn't exceed the rate limit per second combining all our requests made for that specific interval."
Q] At any given time span of "1sec" there could be at least 3 api calls for a "single user key" like;
a) margins api => 1 attempt
b) place_order api => 1 attempt
c) order_history api => 1 attempt
So in case of a failed response this leaves no room for reattempt of the api within 1 sec since the per user per 1sec max limit is "just 3 calls"
(Well "margins api" can be discounted but still there is no room to reattempt!!!)
Any plans to increase this rate??
Any ways thanks both for crucial guidance.
PS. (Consider this as a part of suggestive enhancement / user's perspective)
1] Frankly speaking this "on_order_update(ws, data)" callback should return the last updated OMS data upon every connect; whether its the 1st connect or subsequent reconnects.
a) On 1st connect => Return NULL
b) On subsequent reconnects => Return NULL or the last updated OMS data
Usage :: We can use this instead of order_history api where requests have rate limits and ultimately loads your system!! Also not good from coding point of view!!!
Why so :: Since even if there is small % chance of websocket disconnection by virtue of any reason (However good a coder is there are other uncontrolled parameters also) we are leaving this loss of "EXTREMELY IMPORTANT DATA" totally unhandled!! This on_order_update is after all "only receive enabled" interrupt (as we call them in embedded).
Do think over this if possible.
Thanks for patient reading
Ohhhh, My wrong interpretation
Hmm.. I got it. A very obvious realistic possible scenario
Well that's so great to be advised!!
Thanks a lot!!!