Authorization Licence issue
-
- Posts: 74
- Joined: 25 Aug 2007
- Been thanked: 6 times
Authorization Licence issue
Today I came home while the system was on autotrading. All of a sudden the authorization had somehow failed during the day? This means all trading was stopped. Fortunately I was not in the middle of a trade. I find it unacceptable that midday checks are performed during real autotrading on IB
- TJ
- Posts: 7743
- Joined: 29 Aug 2006
- Location: Global Citizen
- Has thanked: 1033 times
- Been thanked: 2222 times
That is a huge concern to me. One that frankly I dont think MC has addressed very well. So far, all has been OK, but it could be likely that some kind of failure is coming at some point. (they always do) I fully understand that the risk is on me if I want to auto trade, but still I think this whole DRM thing is a little silly. I just dont like having to rely on their servers being 100% functional for MC to work.2. the authorization server was down
<getting off soapbox. for now.>
Yes, mine just went down a few minutes ago in the middle of trading. THIS IS NOT ACCEPTABLE!!!!!Yes, I am, this is ridiculous, first you have to worry about you brokers data staying up, now the authorization server can go down????
I repeat, THIS IS NOT ACCEPTABLE and it MUST BE FIXED PERMANENTLY ASAP!!!!
Furthermore, this must have 24x7 support. It must include weekends since people use simulations over weekends for testing. I don't care if they have backup servers or not, there must be someone who is informed of the problem immediately and have it fixed. If this is not possible then get rid of the DRM idea at once!
Hi I got the same problem !!!!
I got an error message telling me that MC couldn't get the authorization from the server !!!!!
(see attachement)
it is 9:45 PM eastern time canada the 10 January 2010
And then it stop all real time data !!!! I can not believe this.
Furthermore I get the message : "waiting status from server" without any answer
This is really a serious problem, I was trading, and in between, I loose real time data
I don't think MC should stop real time data as soon as we don't received the authoriazation.
MC must continu to work at least 24 hour after we loose authorization, because it is sunday, there is nobody to fix the problem at tssupport !
And how do we work in between ?
I called TSSupport but no one answer , only answering machine.
We know that MC work well usually and you have a good quality services , So TSSuuport what is happening with those authorization server ?
Emmanuel
I got an error message telling me that MC couldn't get the authorization from the server !!!!!
(see attachement)
it is 9:45 PM eastern time canada the 10 January 2010
And then it stop all real time data !!!! I can not believe this.
Furthermore I get the message : "waiting status from server" without any answer
This is really a serious problem, I was trading, and in between, I loose real time data
I don't think MC should stop real time data as soon as we don't received the authoriazation.
MC must continu to work at least 24 hour after we loose authorization, because it is sunday, there is nobody to fix the problem at tssupport !
And how do we work in between ?
I called TSSupport but no one answer , only answering machine.
We know that MC work well usually and you have a good quality services , So TSSuuport what is happening with those authorization server ?
![Question :?:](./images/smilies/icon_question.gif)
![Question :?:](./images/smilies/icon_question.gif)
Emmanuel
- Attachments
-
- Error message ahtorization problem.doc
- (34.5 KiB) Downloaded 179 times
Note too that the more times this happens the more likely it will put off new customers. I repeat; a suitable approach is to allow a period of grace so that MC can continue to be fully operational without any DRM server. I recommend 5 days to take into account long weekends and other holidays. However, if they can guarantee that a server will always be available somewhere in the world, then a grace of say 24 hours should be more than sufficient. If as I suspect real-time data collection stops immediately when connectivity is broken to a DRM sever, then it's a VERY BAD APPROACH, and I would be very surprised if this what happens. There MUST be at least a small period of grace to take into account very short outages.
Hi Janus
Last time TSSupport told us they put 3 server to cover the problem , and obviously it is not working.
On my side I loose as well precious data, and all my server are down as well waiting for TSSupport to fix the problem.
I agree totaly with Janus, I recommend 5 day as well , this should cover the week end.
When you work all the year long with TSSupport, 5 days of grace is not much specially in case of emergency like that.
Last time TSSupport told us they put 3 server to cover the problem , and obviously it is not working.
On my side I loose as well precious data, and all my server are down as well waiting for TSSupport to fix the problem.
I agree totaly with Janus, I recommend 5 day as well , this should cover the week end.
When you work all the year long with TSSupport, 5 days of grace is not much specially in case of emergency like that.
-
- Posts: 407
- Joined: 01 Jan 2008
- Been thanked: 3 times
Authorization server was down for 30 minutes. MC failed to reconnect automatically, manual authorization was required.
It is unreasonable to have real time chart stopped during Authorization server outage. Perhaps any stoppage should be limited to autotrading - and even then, there should be sufficient grace period to allow the operator to exit the autotrading.
It is unreasonable to have real time chart stopped during Authorization server outage. Perhaps any stoppage should be limited to autotrading - and even then, there should be sufficient grace period to allow the operator to exit the autotrading.
- Attachments
-
- 2010-01-10_224000.gif
- (4.83 KiB) Downloaded 5472 times
If that's true then there should not have been an outage at all unless all three went down at the same time. Perhaps they are too close together and there was a localized network outage. We need to know the specifics so we can come up with a better solution, which wouldn't be that hard. As was suggested several times, a simple solution is to allow a grace period.Hi Janus
Last time TSSupport told us they put 3 server to cover the problem , and obviously it is not working.
Mine went down as well,notwithstanding still being connected to Internet
This means no trading can occur as MC wont update live data
Why such sudden death attitude--please give traders some leeway or grace period before disconnecting live data feed
Whats a couple of hours to MC ?
Please consider
Milton
This means no trading can occur as MC wont update live data
Why such sudden death attitude--please give traders some leeway or grace period before disconnecting live data feed
Whats a couple of hours to MC ?
Please consider
Milton
This is why I keep MC 2.1.999.999 and always will. I can get myself back up in 30 minutes. You have to make sure you have a copy of the workspaces for it and the data as well.
You have to do this. Who knows what could happen to TSS itself. I am lucky that I can live with MC 2.1.999.999 if I have to although MC 6.0 is way better when DRM is running.
You have to do this. Who knows what could happen to TSS itself. I am lucky that I can live with MC 2.1.999.999 if I have to although MC 6.0 is way better when DRM is running.
DRM servers down, no access!
A significant problem for automated trading systems running on MultiCharts. Unacceptable in a production environment. There are enough acts of god to deal with, we don't need this.
Regards,
Tom
Regards,
Tom
MC should be programmed to know the server is down (very doable if a ping plotter type app is built in since pingplotter can pinpoint exactly where the problem is) and it should adapt and keep running. So if MC can not get its signal it fires up the built in pingplotter app and figures out where the disconnect is (it only runs it if it needs to). If need be TSS might consider contacting these people to get them to help with it. This approach would also protect users from a TSS failure too (could be a long time before a buyer comes in to manage the firm).
http://www.pingplotter.com
http://www.pingplotter.com
Last edited by bowlesj3 on 11 Jan 2010, edited 2 times in total.
-
- Posts: 38
- Joined: 11 Jun 2006
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Dear Users,
Please accept our apologies for the service interruption that you experienced.
One of our providers experienced technical difficulties:
However, today the failover did not perform as designed and some users experienced technical difficulties with the DRM system during this period.
At this moment we are investigating this issue and we will inform you about the steps taken to prevent this happening again in the future once the investigation is completed.
Please accept our apologies for the service interruption that you experienced.
One of our providers experienced technical difficulties:
The MultiCharts DRM system has several backup redundancy servers with different providers just in case one of the servers is unavailable.Dear Andrey Kirillov,
Please accept our apologies for the interruption in service that you experienced.
At about 9:14 PM Eastern we experience a partial network outage due to a failed network switch. The automatic failover did not occur as designed. Our network technicians investigated this issue and once they determined what happened were able to re-route the traffic through another switch.
Service was restored at about 10:13PM Eastern.
Sincerely,
eApps Hosting
However, today the failover did not perform as designed and some users experienced technical difficulties with the DRM system during this period.
At this moment we are investigating this issue and we will inform you about the steps taken to prevent this happening again in the future once the investigation is completed.
MultiCharts disabled due to DRM outage.
Andrew, thanks for the update. Please understand it is impossible to prevent network outages like the one you describe here. There is always going to be some risk of failure.
The remedy for the problem for us users of MultiCharts lies in the behavior of the MultiCharts software when DRM authentication is interrupted. This part of our "service interruption" is 100% preventable.
I will not be reassured by anything short of a solution based on the response of the MultiCharts software during a DRM outage.
Regards,
Tom
The remedy for the problem for us users of MultiCharts lies in the behavior of the MultiCharts software when DRM authentication is interrupted. This part of our "service interruption" is 100% preventable.
I will not be reassured by anything short of a solution based on the response of the MultiCharts software during a DRM outage.
Regards,
Tom
-
- Posts: 407
- Joined: 01 Jan 2008
- Been thanked: 3 times
Thanks Andrew for the update. As I suspected it was a network issue out of your hands. This is reason enough to modify the current behavior as it's not acceptable. I'm actually surprised you haven't bothered to consider this possibility in the first place. Anyone who uses the Internet knows that these things can and do happen. Given trading is such a time sensitive issue, this makes it critical that an appropriate solution be implemented ASAP, and it must be done for 6.0, not to a later release. As suggested many times, the most logical approach is to have a grace period. The only question is how long. 24 hours might be enough as long as you can recognize the other possibility when all the actual DRM servers go down and someone fixes at least one of them within 24 hours. A more sophisticated approach is to use the other suggestion of making it aware that it can't reach any of the servers so MC must remain fully operational until it can reach one. The only drawback with this one from your point of view is a sophisticated person can set up a firewall rule to prevent MC from ever contacting a DRM server thus working around this feature permanently. So, the best approach overall is just to have a grace period. It's very easy as well which makes it even more appropriate (unless someone fiddles with he computer time but then it will upset the timestamps on the data thus rendering it useless anyway).
Hi Andrew,
Thank you for your update,
It is clear, that we need a grace period in case of failure of the server.
otherwise you are trading with a gun ready to shot on your head at any time
We are trading with real money, with real data, and we need a realiable MC.
It is clear that Multichart is an excellent software, and you have a very good quality service, it is obvious that you need to check the licence of the user.
And it is clear that a grace period is necessary, it would allow to TSSupport ot check the licence, and it would increase the reliability of the Multicharts.
When we trade with real money, we need efficency with security
Multichart is a professional software, we plan to buy more licence in the future. And it is clear that the grace period is needed here
(or maybe a secondary solution ?)
When you build the future on strong basis, you need reliability before anything else.
Safety always come first
I don't think the grace period would be to complecated when you consider the potential of loss of money at any time. When you least expect it.
I can accept loosing money when it is my mistake, It is more difficult to accept to lose money because of a partner, and it compleatly inacceptable
when you loose money for something like an authorisation.
Andrews, We ask that you take our request in consideration, specially because Multichart have always been a real tool for real professional trader ,
Multicharts is the best tool , it is safe, secure, reliable, inovative, always improving and for all thoses reason, the grace periode is absolutely necessary if considere safety as a necessary component for success.
Emmanuel
Thank you for your update,
It is clear, that we need a grace period in case of failure of the server.
otherwise you are trading with a gun ready to shot on your head at any time
We are trading with real money, with real data, and we need a realiable MC.
It is clear that Multichart is an excellent software, and you have a very good quality service, it is obvious that you need to check the licence of the user.
And it is clear that a grace period is necessary, it would allow to TSSupport ot check the licence, and it would increase the reliability of the Multicharts.
When we trade with real money, we need efficency with security
Multichart is a professional software, we plan to buy more licence in the future. And it is clear that the grace period is needed here
(or maybe a secondary solution ?)
When you build the future on strong basis, you need reliability before anything else.
Safety always come first
I don't think the grace period would be to complecated when you consider the potential of loss of money at any time. When you least expect it.
I can accept loosing money when it is my mistake, It is more difficult to accept to lose money because of a partner, and it compleatly inacceptable
when you loose money for something like an authorisation.
Andrews, We ask that you take our request in consideration, specially because Multichart have always been a real tool for real professional trader ,
Multicharts is the best tool , it is safe, secure, reliable, inovative, always improving and for all thoses reason, the grace periode is absolutely necessary if considere safety as a necessary component for success.
Emmanuel
The grace period for live trading would need a count down. Some like myself may not use the status bar so a popup system makes sense (one that can be turned of once seen so the count down value can be referenced). Maybe for some it needs an email alert as well. Maybe in time a reserve word could notify an automated system of the count down so the system could close out positions (at a profit hopefully while it still has some control).
-
- Posts: 117
- Joined: 08 Nov 2005
- Been thanked: 3 times
hi
I think the best way is when we run MC ,MC make only one request to yours server (only one request authorization )....any time we run MC after we shutdown MC
When we run MC and make only one authorization and you save in your basedate ours Nº of client is online.
when we shutdown MC, MC send to yours server we get out and you save in your basedate ours Nº of client is offline.
if we are online no problem if append any thing w your serve![Smile :-)](./images/smilies/icon_smile.gif)
if we are offline(shutdown MC ) and rum MC w problems in your server.. well we dont have date in real time
(We use another software ) or MC work in realtime (about) only 2 hours or 8 hours...and same time MC try to get authorization from your server and when get authorization save in your basedate ours nª of client is online
imo
thanks
jo
I think the best way is when we run MC ,MC make only one request to yours server (only one request authorization )....any time we run MC after we shutdown MC
When we run MC and make only one authorization and you save in your basedate ours Nº of client is online.
when we shutdown MC, MC send to yours server we get out and you save in your basedate ours Nº of client is offline.
if we are online no problem if append any thing w your serve
![Smile :-)](./images/smilies/icon_smile.gif)
if we are offline(shutdown MC ) and rum MC w problems in your server.. well we dont have date in real time
![Sad :-(](./images/smilies/icon_sad.gif)
imo
thanks
jo
Last edited by gregorio123456 on 11 Jan 2010, edited 1 time in total.
Yes, a countdown as such would be useful but if the grace period is long enough it would be extremely unlikely to be necessary. In any case, it's worth having the countdown as a last resort if the DRM servers for some reason are all not reachable for beyond the grace period but the brokers system is still reachable. For a grace period of say several days I think this would be almost impossible to happen but as we all know, expect the unexpected and prepare for it accordingly just in case. On-line automatic trading is such a critical practice, all possible scenarios no matter how unlikely must be taken care of. So, yes by all means have a countdown but we must have the grace period for starters ASAP.The grace period for live trading would need a count down.
Hi
It could be interesting to use a dungle like Aladdin to protect MC.
Like that you can continu to use it even without a server.
This could be an idea.
http://www.aladdin.com/HASP/srm.aspx
or
http://www.ftsafe.com/products/rockey.html
What do you think ?
Emmanuel
It could be interesting to use a dungle like Aladdin to protect MC.
Like that you can continu to use it even without a server.
This could be an idea.
http://www.aladdin.com/HASP/srm.aspx
or
http://www.ftsafe.com/products/rockey.html
What do you think ?
![Question :?:](./images/smilies/icon_question.gif)
Emmanuel
Doesn't TS still use that method? Not sure it's better though. What if you lose it or for some reason it stops working? There's a huge delay in getting a replacement, far worse than the current issue. Don't forget, we must take into account all possible scenarios no matter how remote. I prefer the current method as long as a grace period is applied.
Hi
I don't think TS use the dungle,
It may be interesting to have the a dungle, as a secondary identification for MC.
Like that we have more reliability, MC could use the dungle to make sure that we have the licence even disconnected.
we can have more reliability , and MC can still use the server to check the licence with more flexibility in case the server is down.
I think the idea of period of grace should be enough , if it is applied to multicharts.
Emmanuel
I don't think TS use the dungle,
It may be interesting to have the a dungle, as a secondary identification for MC.
Like that we have more reliability, MC could use the dungle to make sure that we have the licence even disconnected.
we can have more reliability , and MC can still use the server to check the licence with more flexibility in case the server is down.
I think the idea of period of grace should be enough , if it is applied to multicharts.
Emmanuel
Regarding Janus's comments:
I agree with Janus that DRM is probably the best. My question is why is this DRM not already rotating all 3 servers during every 3 authorizations such that it is in effect already self testing itself constantly. I am assuming that a few employee's are always on call with a computer running with a DRM variant to be notified of DRM failures (server failures, provider failures, etc). I am assuming the alarm notice on this variant is very loud and maybe pagers are being used? If all this was done properly a grace period should not be needed at all and the worst would be the need to add more servers in different locations. (actually the worst is TSS going out of business but we won't talk about that since MC is great and it probably won't happen right?).
Regarding grace periods and count down I am thinking TSS will want a grace period as short as possible since it could be used over and over again could it not? Could a user not restart the grace period every day with a zonealarm block? How would that be stopped? It would need internal programming (hackable). A short grace period would make it very inconvenient to do the over and over thing.
I temporarily forgot that zonealarm can block outgoing data to an IP address and I have never set up a firewall so I didn't realize these could do that as well. I have never had a problem with invasion of my computer (I shouldn;t have said that right! - Besides, Invaders would ge bored, fall asleep and vow to never do that again!). (Admittedly a lot of work and probably not as good as DRM) but could MC not provide its own fire wall and refuse to run if other methods of blocking an IP address were detected. Again hackable I would assume.
IB's security device idea is probably very reliable but a bit of a pain. My understanding is that the plug in things (dongle is it?) can be duplicated.
My guess is TSS will perfect the DRM fast since if they don't a lot of users are going to drop MC really fast. If I get stung I will go back to MC 2.1.999.999 first then come back when I see a few months with no DRM problems on the forum and they advertize openly how it is very secure (I think this is really important now). I was lucky and missed this one.
It gets the programmers thinking at least![Very Happy :D](./images/smilies/icon_biggrin.gif)
I agree with Janus that DRM is probably the best. My question is why is this DRM not already rotating all 3 servers during every 3 authorizations such that it is in effect already self testing itself constantly. I am assuming that a few employee's are always on call with a computer running with a DRM variant to be notified of DRM failures (server failures, provider failures, etc). I am assuming the alarm notice on this variant is very loud and maybe pagers are being used? If all this was done properly a grace period should not be needed at all and the worst would be the need to add more servers in different locations. (actually the worst is TSS going out of business but we won't talk about that since MC is great and it probably won't happen right?).
Regarding grace periods and count down I am thinking TSS will want a grace period as short as possible since it could be used over and over again could it not? Could a user not restart the grace period every day with a zonealarm block? How would that be stopped? It would need internal programming (hackable). A short grace period would make it very inconvenient to do the over and over thing.
I temporarily forgot that zonealarm can block outgoing data to an IP address and I have never set up a firewall so I didn't realize these could do that as well. I have never had a problem with invasion of my computer (I shouldn;t have said that right! - Besides, Invaders would ge bored, fall asleep and vow to never do that again!). (Admittedly a lot of work and probably not as good as DRM) but could MC not provide its own fire wall and refuse to run if other methods of blocking an IP address were detected. Again hackable I would assume.
IB's security device idea is probably very reliable but a bit of a pain. My understanding is that the plug in things (dongle is it?) can be duplicated.
My guess is TSS will perfect the DRM fast since if they don't a lot of users are going to drop MC really fast. If I get stung I will go back to MC 2.1.999.999 first then come back when I see a few months with no DRM problems on the forum and they advertize openly how it is very secure (I think this is really important now). I was lucky and missed this one.
It gets the programmers thinking at least
![Very Happy :D](./images/smilies/icon_biggrin.gif)
DRM servers down, no access!
I don't think a "grace period" could be abused when the only time it is honored by the TS Support network is when one or more DRM servers are down.
The grace period would only be in effect when there was an outage, until the technician resolved the outage and reset the grace period to "off".
So, the data servers and other non DRM servers would "know" when their sister DRM server failed and they would trip the grace period before they denied access to us. When the technicians resolved the outage of the DRM server(s) then they simply reset the other servers to the "no grace" state.
It is typical in a server farm that the servers communicate with each other.
Just my .02
Regards,
Tom
The grace period would only be in effect when there was an outage, until the technician resolved the outage and reset the grace period to "off".
So, the data servers and other non DRM servers would "know" when their sister DRM server failed and they would trip the grace period before they denied access to us. When the technicians resolved the outage of the DRM server(s) then they simply reset the other servers to the "no grace" state.
It is typical in a server farm that the servers communicate with each other.
Just my .02
Regards,
Tom
An expert programmer probably can get around any system. I don't' see a problem using a grace period to cover the unlikely but possible scenario that MC loses contact with all 3 DRM servers but still has contact with the broker's system. I can imagine such a scenario even if the 3 servers are dispersed across the world, albeit extremely unlikely. Given the possibility of this is not zero, and given any interruption to an auto-trading tool is super critical, I can't see any other easy way other than having a grace period. The only question is how long. I think it should be at least 3 days given users are located all over the world whereas TSS does not offer a 24x7 support service.
As bowlesj3 commented, it's possible to overcome this by triggering a false "outage" multiple times using a suitable firewall rule. However, I thought the purpose of the DRM servers is to check that the MC license is valid, and if it isn't valid MC would be prevented from running in real-time even when the DRM servers are reachable. If the DRM servers are not used for this purpose, and are used simply to prevent multiple copies being run with the same license then that's another issue. In that case the user shouldn't be able in the first place to have multiple copies running at the same time since each new instance of MC must be able to reach a DRM server to start up in real-time mode. However, this introduces another dilemma. What if the user is starting up the first and only one but the DRM servers are all unreachable? Should MC still be able to run in real-time? I think the answer is no. This is not such a problem. The real problem occurs when MC is already running and it loses contact with all 3 DRM servers in the middle of a trade. I'm prepared to accept the situation where I can't start up MC in real-time mode if the DRM servers are not available. I just don't want it to stop working in real-time mode once it has started OK, at least for a long enough period to allow the problem to be rectified.
As bowlesj3 commented, it's possible to overcome this by triggering a false "outage" multiple times using a suitable firewall rule. However, I thought the purpose of the DRM servers is to check that the MC license is valid, and if it isn't valid MC would be prevented from running in real-time even when the DRM servers are reachable. If the DRM servers are not used for this purpose, and are used simply to prevent multiple copies being run with the same license then that's another issue. In that case the user shouldn't be able in the first place to have multiple copies running at the same time since each new instance of MC must be able to reach a DRM server to start up in real-time mode. However, this introduces another dilemma. What if the user is starting up the first and only one but the DRM servers are all unreachable? Should MC still be able to run in real-time? I think the answer is no. This is not such a problem. The real problem occurs when MC is already running and it loses contact with all 3 DRM servers in the middle of a trade. I'm prepared to accept the situation where I can't start up MC in real-time mode if the DRM servers are not available. I just don't want it to stop working in real-time mode once it has started OK, at least for a long enough period to allow the problem to be rectified.
Okay so why not this solution?The real problem occurs when MC is already running and it loses contact with all 3 DRM servers in the middle of a trade.
MC is programmed to know you are in a trade and it will not come down (or stop the data feed) until you are out of the trade. In effect this is the count down. If the user is not in a trade it is immediate and if they are it is when the leave the trade. My guess is it would not be too hard to put this in.
I my case I don't get the benefit because I trade outside of MC but if you auto trade (which seems to be the really big concern) then this fixes that issue. Actually maybe I should check into MC 6.0 to see if it can detect if I have a trade running even though I issued it from IB's TWS.
As an aside I think Andrew said one of the servers is in New York.
Last edited by bowlesj3 on 12 Jan 2010, edited 1 time in total.
My guess is the biggest abuse concern of TSS is a single trader trading real time during the day on one machine and doing backtests on another machine with another copy at the same time (real tempting for a non visual fully automated trader). And for the rich trader why not 10 backtesting machnes? What I don't understand is apparently the offline grace period is 30 days so if that is true how do they get protection from this. They must be updating a file on every use of MC and checking it on the reconnect to update the grace period. Now that would make sense and they sure won't advertize where that data is stored.are used simply to prevent multiple copies being run with the same license then that's another issue.
Last edited by bowlesj3 on 12 Jan 2010, edited 2 times in total.
Regarding Tom's comments, I think the grace period is hard coded into MC itself and is triggered when all 3 servers can not be accessed. This is why I say MC should be doing its every 10 minutes authorize (or whataver the period is) on a rotational basis just to ensure that it can get at them and if it can not a signal should (PROBABLY) be sent somewhere to notify someone (support staff on call or even designers and software testers). Software testers may want to analyse the stats on the number of bad connects for future plans.
Real interesting. Later after trading.
Real interesting. Later after trading.
- RobotMan
- Posts: 375
- Joined: 12 Jul 2006
- Location: Los Altos, California, USA
- Has thanked: 31 times
- Been thanked: 13 times
- Contact:
I went to the grocery store the other day to buy apples. I walked right in the front door and picked up the apples and went to the cashier and paid for them and walked right out. I was amazed! I thought to myself, anyone can just walk in and take apples and then sneak out the front door if they really wanted to.It is somewhat naive for developers to think they can combat piracy via this particular "phone-home" method.
I asked the store manager about this and he said that it is true.
He said that there are many security protocols in place, but that they are not trying to prevent EVERYONE from stealing. 90% of his customers would never steal even if there were no safeguards in place. He said that if someone is determined to steal apples they would find a way to do so and there is simply nothing he could do short of putting the apples in a vault. But that the ones that MIGHT be tempted to steal apples are the ones that are most greatly dissuaded by the inconvenience of the existing but unobtrusive security measures already in place. He said his security measures were only meant for the 9.99% and he just had to forget about the .01% that do steal apples or he would lose honest customers due to inconvenience. (Kinda like what the TSA has done to the airline business in the US.) But then again, people stealing apples are not carrying bombs.
Yes, as I said before a smart programmer (or computer wizard) can hack through just about anything. This makes the idea of a grace period even more sensible for the majority of users who are honest. Otherwise, we will find ourselves in the ridiculousness situation when the same problem occurs that all honest users can't trade but the dishonest ones that have found a way around the DRM check still trading!
MC already has a grace period. It is 30 minutes judging by the chronology of the Sunday night stoppage. MC decided that their authorization servers will never be down for more than 30 minutes - a wrong assumption.
How about just changing the grace period to 2-3 hours. It will take no time to program. A better solution is to inform the operator that there is no contact with the authorization servers (after losing connection for >5 min) and that MC will stop real time operation in xx minutes.
How about just changing the grace period to 2-3 hours. It will take no time to program. A better solution is to inform the operator that there is no contact with the authorization servers (after losing connection for >5 min) and that MC will stop real time operation in xx minutes.
Dear Andrey Kirillov,
Please accept our apologies for the interruption in service that you experienced.
At about 9:14 PM Eastern we experience a partial network outage due to a failed network switch. The automatic failover did not occur as designed. Our network technicians investigated this issue and once they determined what happened were able to re-route the traffic through another switch.
Service was restored at about 10:13PM Eastern.
Sincerely,
eApps Hosting
Exactly. Set the grace period to at least 24-48hrs with the servers and phone home to each server completely independent. This should be a very simple implementation.How about just changing the grace period to 2-3 hours. It will take no time to program. A better solution is to inform the operator that there is no contact with the authorization servers (after losing connection for >5 min) and that MC will stop real time operation in xx minutes.
Are you running MC 2.1 and MC 6.0 with the same computer? ....... I don't have MC 2.1 but 3 and 4. Any of the two without DRM?This is why I keep MC 2.1.999.999 and always will. I can get myself back up in 30 minutes. You have to make sure you have a copy of the workspaces for it and the data as well.
You have to do this. Who knows what could happen to TSS itself. I am lucky that I can live with MC 2.1.999.999 if I have to although MC 6.0 is way better when DRM is running.
Sa
Hi Spaceant,
I am now running MC 6.0 beta 2 on both the main machine and notebook (at different times of course). I was running MC 2.1.999.999 on the notebook for a while but that makes the transfer too complex (I use "Comparator" to transfer and there are just too many conflicts between versions I have to worry about so the process is too slow). I am keeping MC 2.1.999.999 just incase something happens to TSS and DRM stops me from trading (maybe 30 minutes to install is too short, for sure less than one hour - it is the compile of the studies that slows it down). Although MC 6.0 has a problem with displaying the charts it actually never bombs on the recalculate command where as MC 2.1.999.999 would bomb on this every 1 or 2 weeks. MC 6.0 is better in a few other areas too (not to mention the fact that the replay is very useful).
I am going to post what I think TSS should be doing regarding DRM. It is different than all the above posts in that it deals with the 30 days of offline use grace period.
John.
I am now running MC 6.0 beta 2 on both the main machine and notebook (at different times of course). I was running MC 2.1.999.999 on the notebook for a while but that makes the transfer too complex (I use "Comparator" to transfer and there are just too many conflicts between versions I have to worry about so the process is too slow). I am keeping MC 2.1.999.999 just incase something happens to TSS and DRM stops me from trading (maybe 30 minutes to install is too short, for sure less than one hour - it is the compile of the studies that slows it down). Although MC 6.0 has a problem with displaying the charts it actually never bombs on the recalculate command where as MC 2.1.999.999 would bomb on this every 1 or 2 weeks. MC 6.0 is better in a few other areas too (not to mention the fact that the replay is very useful).
I am going to post what I think TSS should be doing regarding DRM. It is different than all the above posts in that it deals with the 30 days of offline use grace period.
John.
Here is my 50 cents. I would say 2 cents but this is kind of long
. I think it covers everything would keep most happy that are honest. I thought through the Senarios below to create the summary which is next.
I may update this a bit to keep the ideas all in one spot. I need to trade right now. I am sure it will spawn more thoughts preferrably with TSS.
Summary of suggested solutions (IMHO):
1/ The Grace Period is controlled by MC. It kicks in only if all 3 servers are down and the grace period is the length of time the trader is in a trade and MC itself controls this by detecting the broker still has the trade that MC submitted (it should have a realistic max). If the trader is not in a trade there is no grace period at all (if will never happen if #2 is done properly and I am sure DRM will be almost perfect soon). Discretionary traders do not need any of this. Maybe hackers can figure out how to trick MC into thinking it has a trade but I sure can't nor can most.
2/ TSS ensures the servers are totally separate (separate cities, providers, countries) and MC is constantly rotating its authorization checks and reporting any failures to staff who are always on call. TSS is down to only 2 servers for a minimum amount of time and probably never down to zero (once every 500 or 1000 years maybe). A minimum of two staff cover each server (one on call at a time for 24 hours response if the server goes down but they are notified by an external system via MC itself or by some other backup system if no MC is connected anywhere in the world). If branch offices are not available for this then it is contracted out.
3/ Dishonest MC users can only do one month of offline backtesting one Machine B while at the same time trading live on Machine A. They are detected by matching records batch processing which executes when the 30 day offline grace period build into MC is detected. TSS does not immediately cut them off. Instead a sales pitch is given by recorder voice to try and persuade them buy a second copy of MC and if they refuse then they are cut off (TSS is smart to have a bit of a heart here since Trading is not an easy business and these people may actually be loosing money overall). I am not an expert on how TSS would program to protect the matching records file(s) but I am sure they can stop most traders from finding these files and do it in a way that it can not become a common knowledge item to easily break. I am thinking random naming and random copies throughout the computer and changing the method they use with each new release (or maybe even every install somehow – that would keep hackers busy). Years back I wrote a matching records routine for 5 or 10 files. The routine could handle any number of input files. On each monthly checkin for authorization MC would ship its files down to the head office and the files would be gathered for the matching run (machine ID number is picked up - only one MC allowed per machine). The user would be told what is going on but the wait should not be that long. If it fails the sales pitch is given and maybe a followup phone call makes sense.
It is unfortunate Hackers exists.
Scenarios used to create the summary above.
#1 User has a 1 MC license and tries to backtest on a second copy off line but it records it and when the 30 days are up they have to log in to get the renewal and TSS knows because it pulls down the records (matching records processing detects they were using MC to backtest at exactly the same time they were using MC live). A TSS sales person talks to the user and talks them into a second copy (it works since they are in habit now). It helps us get better support from TSS.
#2 User disconnects computer, copies files to notebook and gets 3 0 days on vacation to review charts on a notebook or backtest. Only one copy of MC is being used at a time. This renews with each live attach to DRM. DRM is smart enough to know this did not happen while the live copy was being using (matching record processing is used as described above).
#3 User has a 1 MC license and tries to trade with a second MC live but can not even get in because of the DRM.
#4 User has a 1 MC license, is in a live trade and all 3 servers are down but are still managing their trade and they do not even know all 3 servers are down. They try to get in to live trade but they can not because there is no grace period because they are not in a live trade yet on the second machine.
#4b. Same as #4 above but the trader does not submit orders from MC. They submit them via the broker software. I guess MC would stop if all 3 servers are down and the trader would have to manage it without the charts. I have never investigated to see if MC 6.0 can detect a trader is in a trade this way. Maybe someone can fill me in on this. If it can maybe TSS would want to allow MC to give a notice that it is coming down or something.
#5 User is not in a trade and tries to bring up MC with a legit copy of MC but all 3 servers are down. They can not run MC. This is just not going to happen, if there are 3 servers in different cities with different providers and MC is constantly rotating its checks with these. The whole Internet would need to be out to stop the user and if that is the case the broker will be out too. They will always get in and because of the rotation TSS will know of problems fast (if TSS do their job correctly and have people on call that is).
#6 User is in a long trade, MC tires server #1 and can not get through, it tries server #2 and keeps running but at the same time it notifies someone via server 2 or some other server that server #1 is down and action is taken for a fix within 3 hours. The user never knew it happened since MC kept rotating the remaining 2 servers with each check until finally the 1st server came back up. MC always rotates servers likes this but because one was down it just did it a bit faster and added in a notification call.
#7 User is in a trade and for some bizarre reason all 3 servers are down. MC is programmed to know they are in a trade and it stays up until they are out of the trade and then DRM blocks them from getting into another trade (unless the server problem was fixed during that trade of course). The grace period is the length of their trade (tailored exactly to their needs at the moment and not that hard to program).
#8 like Scenario #3 the user has a One MC license. MC is running on machine #1 but the power supply fails/spikes/fries and the machine looses power and the machine can not start again (this has happened to me two times in real life and both times I had to go to the shop with the machine to get a new power supply installed). Okay lets say I remember this and create a backup machine #2 (maybe my notebook). I bring up everything on the notebook to try and get out of the trade at a profit before I take machine #1 to the shop (according to Andrew DRM does not need access to the first machine to clear way for the use of MC on the second machine. The DRM simply logs the first MC out of the system on the DRM server allowing the second MC to run. If there was an MC on the first machine it would be stopped).
![Rolling Eyes :roll:](./images/smilies/icon_rolleyes.gif)
I may update this a bit to keep the ideas all in one spot. I need to trade right now. I am sure it will spawn more thoughts preferrably with TSS.
Summary of suggested solutions (IMHO):
1/ The Grace Period is controlled by MC. It kicks in only if all 3 servers are down and the grace period is the length of time the trader is in a trade and MC itself controls this by detecting the broker still has the trade that MC submitted (it should have a realistic max). If the trader is not in a trade there is no grace period at all (if will never happen if #2 is done properly and I am sure DRM will be almost perfect soon). Discretionary traders do not need any of this. Maybe hackers can figure out how to trick MC into thinking it has a trade but I sure can't nor can most.
2/ TSS ensures the servers are totally separate (separate cities, providers, countries) and MC is constantly rotating its authorization checks and reporting any failures to staff who are always on call. TSS is down to only 2 servers for a minimum amount of time and probably never down to zero (once every 500 or 1000 years maybe). A minimum of two staff cover each server (one on call at a time for 24 hours response if the server goes down but they are notified by an external system via MC itself or by some other backup system if no MC is connected anywhere in the world). If branch offices are not available for this then it is contracted out.
3/ Dishonest MC users can only do one month of offline backtesting one Machine B while at the same time trading live on Machine A. They are detected by matching records batch processing which executes when the 30 day offline grace period build into MC is detected. TSS does not immediately cut them off. Instead a sales pitch is given by recorder voice to try and persuade them buy a second copy of MC and if they refuse then they are cut off (TSS is smart to have a bit of a heart here since Trading is not an easy business and these people may actually be loosing money overall). I am not an expert on how TSS would program to protect the matching records file(s) but I am sure they can stop most traders from finding these files and do it in a way that it can not become a common knowledge item to easily break. I am thinking random naming and random copies throughout the computer and changing the method they use with each new release (or maybe even every install somehow – that would keep hackers busy). Years back I wrote a matching records routine for 5 or 10 files. The routine could handle any number of input files. On each monthly checkin for authorization MC would ship its files down to the head office and the files would be gathered for the matching run (machine ID number is picked up - only one MC allowed per machine). The user would be told what is going on but the wait should not be that long. If it fails the sales pitch is given and maybe a followup phone call makes sense.
It is unfortunate Hackers exists.
Scenarios used to create the summary above.
#1 User has a 1 MC license and tries to backtest on a second copy off line but it records it and when the 30 days are up they have to log in to get the renewal and TSS knows because it pulls down the records (matching records processing detects they were using MC to backtest at exactly the same time they were using MC live). A TSS sales person talks to the user and talks them into a second copy (it works since they are in habit now). It helps us get better support from TSS.
#2 User disconnects computer, copies files to notebook and gets 3 0 days on vacation to review charts on a notebook or backtest. Only one copy of MC is being used at a time. This renews with each live attach to DRM. DRM is smart enough to know this did not happen while the live copy was being using (matching record processing is used as described above).
#3 User has a 1 MC license and tries to trade with a second MC live but can not even get in because of the DRM.
#4 User has a 1 MC license, is in a live trade and all 3 servers are down but are still managing their trade and they do not even know all 3 servers are down. They try to get in to live trade but they can not because there is no grace period because they are not in a live trade yet on the second machine.
#4b. Same as #4 above but the trader does not submit orders from MC. They submit them via the broker software. I guess MC would stop if all 3 servers are down and the trader would have to manage it without the charts. I have never investigated to see if MC 6.0 can detect a trader is in a trade this way. Maybe someone can fill me in on this. If it can maybe TSS would want to allow MC to give a notice that it is coming down or something.
#5 User is not in a trade and tries to bring up MC with a legit copy of MC but all 3 servers are down. They can not run MC. This is just not going to happen, if there are 3 servers in different cities with different providers and MC is constantly rotating its checks with these. The whole Internet would need to be out to stop the user and if that is the case the broker will be out too. They will always get in and because of the rotation TSS will know of problems fast (if TSS do their job correctly and have people on call that is).
#6 User is in a long trade, MC tires server #1 and can not get through, it tries server #2 and keeps running but at the same time it notifies someone via server 2 or some other server that server #1 is down and action is taken for a fix within 3 hours. The user never knew it happened since MC kept rotating the remaining 2 servers with each check until finally the 1st server came back up. MC always rotates servers likes this but because one was down it just did it a bit faster and added in a notification call.
#7 User is in a trade and for some bizarre reason all 3 servers are down. MC is programmed to know they are in a trade and it stays up until they are out of the trade and then DRM blocks them from getting into another trade (unless the server problem was fixed during that trade of course). The grace period is the length of their trade (tailored exactly to their needs at the moment and not that hard to program).
#8 like Scenario #3 the user has a One MC license. MC is running on machine #1 but the power supply fails/spikes/fries and the machine looses power and the machine can not start again (this has happened to me two times in real life and both times I had to go to the shop with the machine to get a new power supply installed). Okay lets say I remember this and create a backup machine #2 (maybe my notebook). I bring up everything on the notebook to try and get out of the trade at a profit before I take machine #1 to the shop (according to Andrew DRM does not need access to the first machine to clear way for the use of MC on the second machine. The DRM simply logs the first MC out of the system on the DRM server allowing the second MC to run. If there was an MC on the first machine it would be stopped).
Last edited by bowlesj3 on 14 Jan 2010, edited 13 times in total.
John,Hi Spaceant,
I am now running MC 6.0 beta 2 on both the main machine and notebook (at different times of course). I was running MC 2.1.999.999 on the notebook for a while but that makes the transfer too complex (I use "Comparator" to transfer and there are just too many conflicts between versions I have to worry about so the process is too slow). I am keeping MC 2.1.999.999 just incase something happens to TSS and DRM stops me from trading (maybe 30 minutes to install is too short, for sure less than one hour - it is the compile of the studies that slows it down). Although MC 6.0 has a problem with displaying the charts it actually never bombs on the recalculate command where as MC 2.1.999.999 would bomb on this every 1 or 2 weeks. MC 6.0 is better in a few other areas too (not to mention the fact that the replay is very useful).
I am going to post what I think TSS should be doing regarding DRM. It is different than all the above posts in that it deals with the 30 days of offline use grace period.
John.
Do you mean you have installed two versions on the same computer or in separate ones?
Sa
p/s can u give me a copy of 2.1 just in case..... ? u know what I mean!
Hi Spaceant,
I have only ever had one copy of MC on one computer. I think maybe some are putting more than one MC on one machine but I am not sure. I think we are still suppose to uninstall the old version before installing the new version. If going backwards you have to clear the data and workspaces for sure and have backups of your old versions.
John.
I have only ever had one copy of MC on one computer. I think maybe some are putting more than one MC on one machine but I am not sure. I think we are still suppose to uninstall the old version before installing the new version. If going backwards you have to clear the data and workspaces for sure and have backups of your old versions.
John.
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Dear customers,
I appreciate all suggestions.
Let me explain why we need DRM. DRM is required to grow our revenues and develop the product. Unfortunately it is a fact that people don’t purchase the second license even if they have to. Usually they just install it on the second, third and so on pc. We had customers who use the software on over than 70 computers and paid us for $1500 for one license. That being said if you are going to condemn the existing DRM all you get is a failure of our company in a long run and your personal loss since the system will be not be developed in the future. I’m sure nobody wants it. MC 6 was a result of the DRM. Otherwise wouldn’t be able to invest so much in development of it.
I deleted a post about a pirate version as a good alternative because I consider it offensive to discuss such illegal alternatives on the developer’s home site.
5 day grace period will not work since it allows cheater to block our program by any firewall software and get it working for 5 days without any problems. Thus you can you use it on as many computers you need all you need is to spend 5 minutes once a week.
We do have a grace period and it is 30 minutes. Usually it is enough to cover all short term outages. This time it was enough because the main server hadn’t the internet connection for 60 minutes.
Please keep in mind that not all customers experienced the issue since majority of them has been switched to redundant servers. However some of them did have the issue since our second and the third server couldn’t process so many simultaneous requests and denied it and it was in a loop. It was our miscalculation since we couldn’t emulate such a high load from different pcs when we developed the system. So it is good that we got this bad experience and we can improve the system to avoid such failures in the future.
Thank you for your patience.
I appreciate all suggestions.
Let me explain why we need DRM. DRM is required to grow our revenues and develop the product. Unfortunately it is a fact that people don’t purchase the second license even if they have to. Usually they just install it on the second, third and so on pc. We had customers who use the software on over than 70 computers and paid us for $1500 for one license. That being said if you are going to condemn the existing DRM all you get is a failure of our company in a long run and your personal loss since the system will be not be developed in the future. I’m sure nobody wants it. MC 6 was a result of the DRM. Otherwise wouldn’t be able to invest so much in development of it.
I deleted a post about a pirate version as a good alternative because I consider it offensive to discuss such illegal alternatives on the developer’s home site.
5 day grace period will not work since it allows cheater to block our program by any firewall software and get it working for 5 days without any problems. Thus you can you use it on as many computers you need all you need is to spend 5 minutes once a week.
We do have a grace period and it is 30 minutes. Usually it is enough to cover all short term outages. This time it was enough because the main server hadn’t the internet connection for 60 minutes.
Please keep in mind that not all customers experienced the issue since majority of them has been switched to redundant servers. However some of them did have the issue since our second and the third server couldn’t process so many simultaneous requests and denied it and it was in a loop. It was our miscalculation since we couldn’t emulate such a high load from different pcs when we developed the system. So it is good that we got this bad experience and we can improve the system to avoid such failures in the future.
Thank you for your patience.
couldnt agree with you more Andrew. I thought that post was very inappropriate.I deleted a post about a pirate version as a good alternative because I consider it offensive to discuss such illegal alternatives on the developer’s home site.
I appreciate TSS stand on the DRM issue. I knew this issue would happen at some point. I guess we will have to accept it and build it into our trading plans. I do appreciate this software and what your company does.
A "good alternative"? Wow, how completely disingenuous! So when someone makes an observation about how easy it is for these criminals to by-pass security, and took the time to research & bring awareness to what they are doing, how on earth does such an observation equate to insinuating a "good alternative" ???!!!! Are you kidding me??? Read more carefully next time. I completely agree with the idea to remove the details to said post after now realizing this forum is readable to the public. Originally thought it was a closed forum with only legitimate/paid users allowed to read/post as is the case during my days @ TS. But to even remotely insinuate my intent is anything by honest, is extremely obnoxious and angering.Dear customers,
I appreciate all suggestions.
I deleted a post about a pirate version as a good alternative because I consider it offensive to discuss such illegal alternatives on the developer’s home site.
Last edited by PioTrek on 13 Jan 2010, edited 1 time in total.
Sounds good to me Andrew. They must think we are unwise. TSS is doing a great job overall (and for sure an honest job) and the pirate vendors think we are going to trust them after they are ripping off TSS. They would eventually do it to their customers at least indirectly.I deleted a post about a pirate version as a good alternative because I consider it offensive to discuss such illegal alternatives on the developer’s home site.
Thanks Andrew for the update. Two points.
1. Re the removal of the post describing a hack; I agree with your action to remove it. However, the damage was done before that post. Clearly a hack is available so I hope you can find a way to block it.
2. Re the discovery that when one of the DRM servers went offline, the other two couldn't support the load and failed to work. Glad to hear you are on top of this and that you will prevent it from happening again as this is a major failing of the system and must be fixed ASAP. Please keep us informed of the progress. Perhaps we can participate in some trials. During the weekend when the markets are closed we can participate in a test. First, send a message to all subscribers to warn them of the test and the reason why. This will maximize the number who will participate by leaving their systems running. Then disconnect one of the DRM servers to see what happens.
1. Re the removal of the post describing a hack; I agree with your action to remove it. However, the damage was done before that post. Clearly a hack is available so I hope you can find a way to block it.
2. Re the discovery that when one of the DRM servers went offline, the other two couldn't support the load and failed to work. Glad to hear you are on top of this and that you will prevent it from happening again as this is a major failing of the system and must be fixed ASAP. Please keep us informed of the progress. Perhaps we can participate in some trials. During the weekend when the markets are closed we can participate in a test. First, send a message to all subscribers to warn them of the test and the reason why. This will maximize the number who will participate by leaving their systems running. Then disconnect one of the DRM servers to see what happens.
Hi Andrew,
I agree with you and Janus,
Thank you for your answer, and we are glade to see that you take this challenge seriously. This is really important .
I understand now why you can not give a period of grace of 5 days, you are right 5 minute of connection could give 5 day of using the software.
Andrew, if you need any customer to do some testing on the network, on the weekend to help you, we are available to help.
Andrew, may I propose another idea ? What about purchasing to TSupport, a buffer of time on the licence ?
Example :
I would like to have an extra security on one of licence:
1/ I buy a 2 week licence to TSSUPPORT.
2/ in exchange you give me a code (I enter it in the optional text box in the authorization dialog box of MC)
3/ MC check the code on the TSSUPPORT server, to make sure it is correct and not use on another computer. MC validate this code for a limited use time, let say 2 weeks.
4/ And now have a buffer time of 2 weeks in case of disconnection.
The good thing about this idea, is the buffer can only be use on one computer per code because the code is validated by the server. This code can only be used once (like the phone card number)
2 weeks of extra time would cover failure probably for more than 2-3 years.
It give more security to the us.
Andrews, if you add this feature in the authorization dialog box of MC,
the customer will have the option to use it, the people who want more security can have it , and can buy time as much as they want. And TSSupport can not loose money on it,
This feature will give an extra safety to the customer and cleary improve the reliability of Multicharts.
If you add this feature, you can count me in, I am willing to buy the buffer of time right now.
Emmanuel
I agree with you and Janus,
Thank you for your answer, and we are glade to see that you take this challenge seriously. This is really important .
I understand now why you can not give a period of grace of 5 days, you are right 5 minute of connection could give 5 day of using the software.
Andrew, if you need any customer to do some testing on the network, on the weekend to help you, we are available to help.
Andrew, may I propose another idea ? What about purchasing to TSupport, a buffer of time on the licence ?
Example :
I would like to have an extra security on one of licence:
1/ I buy a 2 week licence to TSSUPPORT.
2/ in exchange you give me a code (I enter it in the optional text box in the authorization dialog box of MC)
3/ MC check the code on the TSSUPPORT server, to make sure it is correct and not use on another computer. MC validate this code for a limited use time, let say 2 weeks.
4/ And now have a buffer time of 2 weeks in case of disconnection.
The good thing about this idea, is the buffer can only be use on one computer per code because the code is validated by the server. This code can only be used once (like the phone card number)
2 weeks of extra time would cover failure probably for more than 2-3 years.
It give more security to the us.
Andrews, if you add this feature in the authorization dialog box of MC,
the customer will have the option to use it, the people who want more security can have it , and can buy time as much as they want. And TSSupport can not loose money on it,
This feature will give an extra safety to the customer and cleary improve the reliability of Multicharts.
If you add this feature, you can count me in, I am willing to buy the buffer of time right now.
Emmanuel
Last edited by Emmanuel on 14 Jan 2010, edited 1 time in total.
I don't understand why we need to pay for this extra "buffer". Why not just extend the grace period for all valid users that connect to a DRM server in the first place. Any user that connects will be verified if the user has a legitimate license or not. Those that don't have a valid license or have another copy already running will not get real-time data unless the other one is stopped. Those that don't connect for offline use won't matter. Those that illegally circumvent it won't matter. Why penalize the honest users by forcing them to pay extra? Perhaps I'm missing something here.
The thing I don't understand is why does DRM have to keep checking so often? Why is it not on startup of MC only. I am thinking of the IB security device here. I do it once at 5am and that is it and we are talking about protecting accounts that I assume are worth many millions in some cases (much more attactive to organized crime than MC). I am assuming that the IB security device approach is basically unhackable as well since each one is preprogrammed to the specific user before it is sent out as well as the entry code being different every single time. Maybe an expert can clear up this area of confusion for some of us. If the IB device is better I personally would rather go that route than have any risk of MC going down due to load etc.
Hi,
bowlesj3, that's why I was speaking about a dungle (above) or a kind of personal code, where you can use it in case of emergency. A buffer of time could be once per licence.
Janus,I understand you,
what happen, is even if you don't have real time data on a illegitimate MC, you can still start it and use it for other job like simulation, working on historical data.
As said Andrew, you could start on 5 computer with one licence only one at a time. then use it for simulation or other job.
If you put the grace period, you could put it for every instance, as many as you want. This is not good.
But if you put a unique grace period per licence, like a buffer period, in this case you can use it only once by incident.
This is the best for TSsupport and this is the best for us.
Tssupport have the garantie , it can not be missused, and we are sure to
stay connected as long as necessary.
Janus, I agree with you the honest people who pay the licences, which support the developpment should not pay for the other guy.
Emmanuel
bowlesj3, that's why I was speaking about a dungle (above) or a kind of personal code, where you can use it in case of emergency. A buffer of time could be once per licence.
Janus,I understand you,
what happen, is even if you don't have real time data on a illegitimate MC, you can still start it and use it for other job like simulation, working on historical data.
As said Andrew, you could start on 5 computer with one licence only one at a time. then use it for simulation or other job.
If you put the grace period, you could put it for every instance, as many as you want. This is not good.
But if you put a unique grace period per licence, like a buffer period, in this case you can use it only once by incident.
This is the best for TSsupport and this is the best for us.
Tssupport have the garantie , it can not be missused, and we are sure to
stay connected as long as necessary.
Janus, I agree with you the honest people who pay the licences, which support the developpment should not pay for the other guy.
Emmanuel
As an example Australian markets trade 9:49am to 4:30pm and then 5:10 to 8am
“If the DRM decided to disconnect” during the day session, then I would expect the DRM to allow Real time data into MC for the balance of this first session, with a warning that the DRM will be disconnecting RT data at end of this session
Same principle “if DRM wants to disconnect “during night session
At least then we have known time to protect trades during the session that the “DRM wants to disconnect” .By the end of the session then Support would/may have sorted the problem (Its their problem that caused the DRM to disconnect in first place, which is not the not the traders problem—for those of us who abide by MC rules)
This is not an unreasonable amount of grace period
I don’t believe we need inordinate amount of grace, 30 minutes is certainly not enough, particularly without warning and converseley 8 +hours is insufficient without warning
We need to be told about impending disconnection, otherwise how can we take action to cover live positions no matter how much grace is given
Grace without warning is useless because we never know when it starts or finishes ?? from a real time perspective.
Thanks
Milton
“If the DRM decided to disconnect” during the day session, then I would expect the DRM to allow Real time data into MC for the balance of this first session, with a warning that the DRM will be disconnecting RT data at end of this session
Same principle “if DRM wants to disconnect “during night session
At least then we have known time to protect trades during the session that the “DRM wants to disconnect” .By the end of the session then Support would/may have sorted the problem (Its their problem that caused the DRM to disconnect in first place, which is not the not the traders problem—for those of us who abide by MC rules)
This is not an unreasonable amount of grace period
I don’t believe we need inordinate amount of grace, 30 minutes is certainly not enough, particularly without warning and converseley 8 +hours is insufficient without warning
We need to be told about impending disconnection, otherwise how can we take action to cover live positions no matter how much grace is given
Grace without warning is useless because we never know when it starts or finishes ?? from a real time perspective.
Thanks
Milton
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Thank you for the support. We will fix the discovered this issue and it will work 100%. I’m confident.couldnt agree with you more Andrew. I thought that post was very inappropriate.I deleted a post about a pirate version as a good alternative because I consider it offensive to discuss such illegal alternatives on the developer’s home site.
I appreciate TSS stand on the DRM issue. I knew this issue would happen at some point. I guess we will have to accept it and build it into our trading plans. I do appreciate this software and what your company does.
Note: Before you read this, Andrew gave the answer and apparently DRM can handle this situation. Specifically, if you have a 1 MC license and if your first machine running MC suddenly looses power and you can not restart the machine then a second machine can start up MC and it just logs the first session off even though it is not there and the second machine runs MC no problem. That is basically it except I am suggesting a FAQs for DRM which has senarios in it and maybe even a grid of senarios and options with the advantages/disadvantages of each option and the reason at the bottom why DRM was used.
=====================================
I think that TSS needs to comment on this because I don’t want to run the test to get the answer. I am wondering if the dongle (USB port plug in device) is the only really good solution to this Scenario #8 issue, which I describe below. Note that I numbered my scenarios in the post above #1 to #7. Also I am thinking that TSS needs to create a FAQs for DRM since it is fairly complex subject with a lot of confusion surrounding it.
Scenario #8 – like Scenario #3 in my post above the user has a One MC license. MC is running on machine #1 but the power supply fails/spikes/fries and the machine looses power and the machine can not start again (this has happened to me two times in real life and both times I had to go to the shop with the machine to get a new power supply installed). Okay lets say I remember this and create a backup machine #2 (maybe my notebook). I bring up everything on the notebook to try and get out of the trade at a profit before I take machine #1 to the shop (trading my system properly on the notebook is not possible because I need two big screens at least).
Here is what I think might happened with Scenario #8 and DRM.
The DRM system server thinks MC is still running on the Machine #1 (I assume this is the case and I can test this by shutting off machine #1 while MC is running but I am hoping TSS can tell me instead). MC on the second machine gets the valid license check okay but DRM prevents MC from running on the second machine because it thinks MC is still running on the first machine due to the sudden loss of power.
Lots of unanswered questions arise from this scenario and maybe should be part of a FAQs for DRM.
1/ How does the DRM clear the first copy of MC from the DRM table so the user can run MC on the second machine.
2/ Do I have to go to the shop to get it fixed and start MC on the main machine again so the machine ID is available to DRM for a valid MC shut down so the DRM can clear its tables on the DRM server?
3/ Where is the machine ID stored and can it get destroyed by a power supply spike? Bear in mind my first power supply failure caused 7 components to go and I seem to remember that one of them was the mother board, in addition to the two disk drives. I had a second incident where I could not boot because of a power supply not giving enough power. I can not remember if it shut down while I was using it. I also had a 3rd failure on another machine where it actually caught on fire while I was using it and my daughter did a mad scramble for the fire extinguisher but turning it off stopped the fire. It was old and used for games only so I just through the machine out. I do not know if it was a power supply problem but it likely was. (note: I had mentioned these incidents in a post a long time ago long before I new what DRM was actually).
4/ What if the mother board is fried and I can not start it with the same machine ID? Do I have to buy another MC when I should only have to buy another machine?
In conclusion (If my concerns are correct) moving the dongle to the second machine would be a very easy way to deal with Scenario #8 (assuming it did not get destroyed by the power supply spike).
Note: As I tried to think out why DRM needs to check up on MC so often by running through scenarios #1 through #7 in my mind I think I figured out why and also I realized that the IB security device will not work either to allow MC to run on different machines at separate times with one license where as the dongle will. (more topics for the DRM FAQs).
So maybe a grid of senarios and options needs to be in the FAQs (row for senarios and columns for options and where they interest comments about advantages and disadvantages of each leading to the final conclusion at the bottom).
=====================================
I think that TSS needs to comment on this because I don’t want to run the test to get the answer. I am wondering if the dongle (USB port plug in device) is the only really good solution to this Scenario #8 issue, which I describe below. Note that I numbered my scenarios in the post above #1 to #7. Also I am thinking that TSS needs to create a FAQs for DRM since it is fairly complex subject with a lot of confusion surrounding it.
Scenario #8 – like Scenario #3 in my post above the user has a One MC license. MC is running on machine #1 but the power supply fails/spikes/fries and the machine looses power and the machine can not start again (this has happened to me two times in real life and both times I had to go to the shop with the machine to get a new power supply installed). Okay lets say I remember this and create a backup machine #2 (maybe my notebook). I bring up everything on the notebook to try and get out of the trade at a profit before I take machine #1 to the shop (trading my system properly on the notebook is not possible because I need two big screens at least).
Here is what I think might happened with Scenario #8 and DRM.
The DRM system server thinks MC is still running on the Machine #1 (I assume this is the case and I can test this by shutting off machine #1 while MC is running but I am hoping TSS can tell me instead). MC on the second machine gets the valid license check okay but DRM prevents MC from running on the second machine because it thinks MC is still running on the first machine due to the sudden loss of power.
Lots of unanswered questions arise from this scenario and maybe should be part of a FAQs for DRM.
1/ How does the DRM clear the first copy of MC from the DRM table so the user can run MC on the second machine.
2/ Do I have to go to the shop to get it fixed and start MC on the main machine again so the machine ID is available to DRM for a valid MC shut down so the DRM can clear its tables on the DRM server?
3/ Where is the machine ID stored and can it get destroyed by a power supply spike? Bear in mind my first power supply failure caused 7 components to go and I seem to remember that one of them was the mother board, in addition to the two disk drives. I had a second incident where I could not boot because of a power supply not giving enough power. I can not remember if it shut down while I was using it. I also had a 3rd failure on another machine where it actually caught on fire while I was using it and my daughter did a mad scramble for the fire extinguisher but turning it off stopped the fire. It was old and used for games only so I just through the machine out. I do not know if it was a power supply problem but it likely was. (note: I had mentioned these incidents in a post a long time ago long before I new what DRM was actually).
4/ What if the mother board is fried and I can not start it with the same machine ID? Do I have to buy another MC when I should only have to buy another machine?
In conclusion (If my concerns are correct) moving the dongle to the second machine would be a very easy way to deal with Scenario #8 (assuming it did not get destroyed by the power supply spike).
Note: As I tried to think out why DRM needs to check up on MC so often by running through scenarios #1 through #7 in my mind I think I figured out why and also I realized that the IB security device will not work either to allow MC to run on different machines at separate times with one license where as the dongle will. (more topics for the DRM FAQs).
So maybe a grid of senarios and options needs to be in the FAQs (row for senarios and columns for options and where they interest comments about advantages and disadvantages of each leading to the final conclusion at the bottom).
Last edited by bowlesj3 on 14 Jan 2010, edited 9 times in total.
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
You discussed the illegal alternatives here. It is inappropriate. I can’t understand your offence sir.A "good alternative"? Wow, how completely disingenuous! So when someone makes an observation about how easy it is for these criminals to by-pass security, and took the time to research & bring awareness to what they are doing, how on earth does such an observation equate to insinuating a "good alternative" ???!!!! Are you kidding me??? Read more carefully next time. I completely agree with the idea to remove the details to said post after now realizing this forum is readable to the public. Originally thought it was a closed forum with only legitimate/paid users allowed to read/post as is the case during my days @ TS. But to even remotely insinuate my intent is anything by honest, is extremely obnoxious and angering.Dear customers,
I appreciate all suggestions.
I deleted a post about a pirate version as a good alternative because I consider it offensive to discuss such illegal alternatives on the developer’s home site.
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Janus,Thanks Andrew for the update. Two points.
1. Re the removal of the post describing a hack; I agree with your action to remove it. However, the damage was done before that post. Clearly a hack is available so I hope you can find a way to block it.
2. Re the discovery that when one of the DRM servers went offline, the other two couldn't support the load and failed to work. Glad to hear you are on top of this and that you will prevent it from happening again as this is a major failing of the system and must be fixed ASAP. Please keep us informed of the progress. Perhaps we can participate in some trials. During the weekend when the markets are closed we can participate in a test. First, send a message to all subscribers to warn them of the test and the reason why. This will maximize the number who will participate by leaving their systems running. Then disconnect one of the DRM servers to see what happens.
The pirate software always was and I don’t think something will be changed in the future. All programs could be cracked. It is not a question. The DRM system is for honest people who “forget’ to buy the licenses for other pcs
![Smile :)](./images/smilies/icon_smile.gif)
You idea is really good and this is what we are going to do maybe this weekend.
- Andrew Kirillov
- Posts: 1589
- Joined: 28 Jul 2005
- Has thanked: 2 times
- Been thanked: 31 times
- Contact:
Dear Customers,
I think the “time buffer” is not solution. The system must just work always. It is not the 3d fault. It is the first failure after we started it in the production mode. It was beta before. It worked with 99.99% up time and it is achievable to get 100% up time. Otherwise we wouldn’t spend our efforts to fix it. The dongle looks like a good solution if we can’t make the DRM work properly, but I’m confident we can.
About the DRM logic. If you run it on the second pc you will simply logoff the first user. You can test it. We don’t sore the PC Id since we ping server every x seconds and see which account is occupied. It works perfectly. You don’t need to fix anything so all other concerns are irrelevant.
Thank you all who commented. We are going to make shutdown tests this weekend if you don’t mind. Probably you will not notice it thanks to the grace period.
I think the “time buffer” is not solution. The system must just work always. It is not the 3d fault. It is the first failure after we started it in the production mode. It was beta before. It worked with 99.99% up time and it is achievable to get 100% up time. Otherwise we wouldn’t spend our efforts to fix it. The dongle looks like a good solution if we can’t make the DRM work properly, but I’m confident we can.
About the DRM logic. If you run it on the second pc you will simply logoff the first user. You can test it. We don’t sore the PC Id since we ping server every x seconds and see which account is occupied. It works perfectly. You don’t need to fix anything so all other concerns are irrelevant.
Thank you all who commented. We are going to make shutdown tests this weekend if you don’t mind. Probably you will not notice it thanks to the grace period.
Thanks Andrew. When you mention the PC ID I guess you read my last post about having three PC power supply failures and my concerns there regarding exactly how the DRM works and what will happen (I have been too busy with the replay to test DRM actually). I went back to my post and put the answer at the top that you gave to save the user's the time of reading it.About the DRM logic. If you run it on the second pc you will simply logoff the first user. You can test it. We don’t sore the PC Id since we ping server every x seconds and see which account is occupied. It works perfectly.
I still think a DRM FAQs is a good idea. If done the inclusion of senarios in such a FAQs is a good idea so users know what to do or expect. Maybe senarios if worded properly could also be a good sales item (my experience can be used if you want).
So maybe a grid of senarios and options needs to be in the FAQs (row for senarios and columns for options and where they intersect there would be short comments about advantages and disadvantages of each leading to the final conclusion as to why the DRM was used at the bottom below the grid).
Not that it matters to me much but I really think you need to be careful about cutting MC off when a trader is in a trade with an automated system (especially if they just got in and are hooked before a move to a profit). Maybe that loss wipes out their ability to buy more MC licenses. You never know. Again this senario and how MC handles it with DRM might be a good sales item.
John.
Hi Milton,Hi Bowlesj3
Your scenario does not cover those who stiill trade using real time data that dont use automated orders directly to broker from MC .
Regards
Milton
Thanks for mentioning that. LOL Gee, it took me long enough to notice your post. I noticed it when I put Senario #8 in there.
Yah I was wondering about that because I am in that situation. It isn't as serious as full autotrading which I guess means stop order in the system would not be available and that is not good (could wipe an account out I guess). I guess I will go back and read that post again.
I am not really sure what to put in there (long day). Here is a try copied out of that post.
#4b. Same as #4 above but the trader does not submit orders from MC. They submit them via the broker software. I guess MC would stop if all 3 servers are down and the trader would have to manage it without the charts. I have never investigated to see if MC 6.0 can detect a trader is in a trade this way. Maybe someone can fill me in on this. If it can maybe TSS would want to allow MC to give a notice that it is coming down or something.
John.
Yes, I've noticed this before. I also noticed that if MC crashes (due to my dll's) and I then start up MC again on the same PC it warns me that I'm already logged on and asks for confirmation to log me off the previous session before logging back on.About the DRM logic. If you run it on the second pc you will simply logoff the first user. You can test it.
I actually prefer the DRM system compared to a dongle approach. Dongles can have their own issues, and if it's lost or broken it's a major disaster. At least the DRM system has redundancy. We only need to sort out how to prevent the recent event from occurring again. If the 3 DMR servers are using different service providers, and are situated at different locations then it should be good enough. We just need to fix the reason why the fail over didn't work properly. If as Andrew stated it was a load issue, then I'm sure something can be done to avoid it happening again. Perhaps the unusually high number of requests coming to the live DMR server(s) could be queued up to avoid overloading the server in the first place, but an acknowledgment is sent back at the same time to inform MC that it's in the process of being verified but there will be a delay and the grace period is automatically extended for a little while for this time only.
Last edited by janus on 14 Jan 2010, edited 1 time in total.
In addition to what Janus suggested it really should be possible for MCs (all over the world) to rotate the server calls in such a way that they do not accidentally start calling the same one at the same time. I am not sure how you would do it exactly but it is definitely doable and doable such that if the server count is down to two of them it divides this properly too. Here is a simple attempt.
MC Users are grouped 1,2,3 when they are sold. If the calls were every 20 minutes then group 1 would be divided into 20 and they would be forced to call at specific times within that first 20 minutes (splitting the load). Upon rotation they would simply shift to the second 20 minutes within the hour and on third rotation they would shift to the 3rd 20 minutes within the hour.
When down to two servers it would rework itself somehow (they would be assigned 1 and 2 as well when they are sold (based upon user ID I suppose).
It could be such that this in itself creates the 30 minute grace period (roughly).
Maybe this has to be much shorted than an Hour. I don't know.
The more I think about it there really is no way you can get around doing this. You have to have complete control of it. You need to force the PC clock to be accurate to the atomic clock too.
MC Users are grouped 1,2,3 when they are sold. If the calls were every 20 minutes then group 1 would be divided into 20 and they would be forced to call at specific times within that first 20 minutes (splitting the load). Upon rotation they would simply shift to the second 20 minutes within the hour and on third rotation they would shift to the 3rd 20 minutes within the hour.
When down to two servers it would rework itself somehow (they would be assigned 1 and 2 as well when they are sold (based upon user ID I suppose).
It could be such that this in itself creates the 30 minute grace period (roughly).
Maybe this has to be much shorted than an Hour. I don't know.
The more I think about it there really is no way you can get around doing this. You have to have complete control of it. You need to force the PC clock to be accurate to the atomic clock too.
Hi Andrew
There seems to be two scenario’s of events
Scenario 1= User does something illegal.
Scenario 2= DRM fails-no fault of user.
In Scenario1, cancel privileges as the user is at fault.
In Scenario2, do not cancel Real Time data, as fault is with MultiCharts,not the user,so dont penalise user in this scenario.
Regards
Milton
There seems to be two scenario’s of events
Scenario 1= User does something illegal.
Scenario 2= DRM fails-no fault of user.
In Scenario1, cancel privileges as the user is at fault.
In Scenario2, do not cancel Real Time data, as fault is with MultiCharts,not the user,so dont penalise user in this scenario.
Regards
Milton