Yes it does have a well defined structure, and it look pretty stable and guess-able in part,
and yes last digits are documented
However it is supplied by IB as a 'string',? IMHO as I not aware of any additional documentation about it's content, I consider that IB may modify it without warning.
IB only responsibility is to make it consistent as a unique string in time and across their various reporting system and API

Just for sake of curiosity why do you want to know the structure ? There are various other id to help identifying the context of the execution.

Also read and consider method #2 with a global stop_threads
This is not the most elegant method as it lack specificity of thread to stop, but it should work since you better stop any thread that handle EReader before restarting a connection
(last suggestion on this site is more elegant)

Again Python is not a language I practice and even? worst I don't use at all the IB Python client, so consider what I write hereafter as suggestion for investigations
in reader.py

??????????? while self.conn.isConnected():
??????????????? global stop_threads???? #<-add on
??????????????? if stop_threads:??????? #<-add on
??????????????????? break?????????????? #<-add on
Steps:
#1- disconnect
#2- then activate the thread killer with global stop_threads = True
#3- wait for thread to stop with self.reader.join? # <-important that you wait until thread is really finished, see a tutorial about join
Should see message "EReader thread finished"
#4- restart
All that from main

But I suspect that it won't be perfect because,? you ought to perfectly know the state of all your pending request in your apps so that you can restart any pending.
Simplest is to stop all activities couple of minutes before restart.
Also be aware if not yet known that there are way to moderate (control) restart.
TWS can be a disconnected state from IB during maintenance but doesn't always need to restart itself, then the connection to your apps may be kept alive.
There is various threads on this site about how to pace down TWS restart and why it should restart. There are couple of good reasons for that, personally I prefer to always daily restart, an ATS should not run unattended.

开云体育

• m_pClient->reqTickByTickData(20004, ContractSamples::EMINI(), "BidAsk", 0, false);

? ??

? ? def orderStatus(self, orderId, status, filled, remaining, avgFullPrice, permId, parentId, lastFillPrice, clientId, whyHeld, mktCapPrice):

? ? ? ? print('orderStatus - orderid:', orderId, 'status:', status, 'filled', filled, 'remaining', remaining, 'lastFillPrice', lastFillPrice)

? ? ? ? global current_fill_price

? ? ? ? global current_orderID

? ? ? ? global current_fill_status

? ? ? ? if status == 'Filled':

? ? ? ? ? ? print('order ID',orderId,' has been filled at price ', lastFillPrice ,'.')

? ? ? ? ? ? current_fill_status = 'Filled'

? ? ? ? ? ? current_fill_price = lastFillPrice

? ? ? ? ? ? current_orderID = orderId

?

? ? ? ? global profit_order_ID

? ? ? ? if orderId == profit_order_ID:

? ? ? ? ? ? print('PRINTING OUT THE AT PROFIT ORDER ID')

开云体育

Limitations?– Additional symbol request can be purchased through a quote booster pack, each quote booster pack provides a 100 market data lines. There is a limit of 10 quote booster packs per account and rest of the market data lines are allocated using equity and commissions.

execId = AAAAAAAA.BBBBBBB.CC.DD

I can only share my understanding, not sure it is accurate, they are murky about that.
'Data lines' are only related to market depth entry, the number of lines depends upon the popularity of the ticker and IB consider the thing by batch.
Doesn't seems many peoples need RT granular ticks,also any ATS based on it require fast computation if you want to consider many tickers at same time.

I don't see any monthly issue in IB method for limitation. (more precisely never see such limits and not really IB philosophy)
IB are primarily concerned by bandwidth and limits on their resources usage, this is what drive them.
BTW sometime they give you more because they can.
Sometime they give less than expected because they can't, I have one case with reqHeadStamp that have it's own undocumented rules, I can understand that because this one need only a call once in the life time of the instrument.

The API is a connection that should be considered keeping TWS needs in mind.
So be careful that they also aggregate TWS in their load calculation, ongoing works on TWS is in many case something that decrease your API alloc. (they does explain that)
however in your case? I don't know how to get the exact?() on TWS, on TWS is made using reqMkdata() BUT maybe opening a book view may impact it
You should conduct your test using Gateway.

Also IB? 'short cut' their explanation about limitations of redirecting user on same page as (which is probably the most IO intensive method)
There is a remote reason, a on B/A should deliver the same data result as a request with 1 as the number of lines, or let say identical as the top line. (should be, never checked, require care to analyze the exchange reported in both)
Does IB account a as a request with an allocated of 399 unused entries ? (what you wonder as what is data line)

But frankly, I apologize but I will come back on my suggestion and agree that you should run with reqMktData unless you have a budget for tick data and a real reason to use it at finest granularity level. Means 250 ms is not fast enough for you.? Your exact limitation depends upon a lot of factors related to your account etc ... at this stage you should initiate a discussion with IB support

I assume that you are not completely locked up, you are not in life/death situation hence the "please helps" is not for an emergency, right ?
so that if you stop your code and restart it, it will work again, right ?

What I understand (please precise it) is that you want to automatically reconnect to a restarted TWS WITHOUT stopping your code. right ?
And you expect disconnect () / reconnect () to do enough to shutdown/spinup to allow this, right ?
But: is your current situation an old issue (it never worked) ? or did it worked but now no longer work ?

Python is not a language I master, but what catch my attention is a generic issue, I see 2 thread numbers (does this reveal 2 <> threads ?)
So that this is probably not a new issue for you, it never worked, right ?

the #16 and the #7 that may be trying to access same resources, your socket,
the #16 did hijack the socket used by your old #7 (which worked in the past but is running blind now)
the #16 seems to have properly started and I won't be surprised if you actually received messages which are properly decoded, but now by the new thread #16
and aside of boring log message, if you do not consider theses messages, the rest of your apps may work. (slower)

Each EReader run in it's own thread, and may require special attention to stop it (kill thread) before you re-initiate a connection sequence. I recommend to disconnect then kill the thread.

isConnected() == true is not enough to guaranty that the running thread have exclusive access to the IO, ,it only say that something in your app is connected to TWS. hence #6 that try it's best to call recvMsg but fail
see that in reader.py
?????????? while self.conn.isConnected(): <- true in both thread
??????????????? data = self.conn.recvMsg()

and look at how simple and across thread does? def isConnected(self): work
Also look at client.py
?? def connect(self, host, port, clientId):
you will see a
??????????? self.reader = reader.EReader(self.conn, self.msg_queue)
??????????? self.reader.start()?? # start thread
This is the thread you need to 'manually' stop, unless there is an exception system I don't know that should trow and kill when socket is invalid (that's beyond what I interpret just from reading the Python code)