DislikedPeople on the Mbt API yahoo group are reporting simmilar incidents. (demo as well as live). No answer from the developers so far.Ignored
ycomp -
Did you happen to notice if the level 2 was reflecting the same quote as the FXBoard? If the bid / offer in the level two should the pricing to be accurate and reflect your position you most likely would have no problem closing and executing at that price.
I'll bear that in mind next time. thanks.
Regarding this issue of people getting “logged off by someone else,” it isn’t really happening as described here on the boards. We have verified that essentially people are getting “dropped” or “booted” off of the system randomly due to one of the many internet backbones we use having outages. When the backbone bounces we send disconnect messages, but the wrong message was being sent.
I know some things about programming, and all the programming languages I am familiar with, you create specific error messages pertaining to certain data that is received for particular "if" statements.
For example ... when creating a php form script, if you want certain fields to be required (meaning that the Submitter cannot leave the input field blank), you write your "if" statements into the script something like this:
<?
// Error check for required fields.
if ($_POST['first'] == "" Or $_POST['last'] == "" Or $_POST['address'] == "" Or $_POST['city'] == "" Or $_POST['state'] == "" Or $_POST['zip'] == "" Or $_POST['day'] == "" Or $_POST['email'] == "" Or $_POST['location'] == "")
{
echo "<html><head><title></title></head><body>";
echo "ERROR: You left the following fields blank:<ul>";
if ($_POST['last'] == "") echo "<li>Last Name";
if ($_POST['address'] == "") echo "<li>Address";
if ($_POST['city'] == "") echo "<li>City";
if ($_POST['state'] == "") echo "<li>State";
if ($_POST['zip'] == "") echo "<li>Zip Code";
if ($_POST['day'] == "") echo "<li>Daytime Phone Number";
if ($_POST['email'] == "") echo "<li>Email Address";
echo "</ul>";
echo "Hit your BACK button to return to form";
echo "</body></html>";
exit();
}
if (!strstr($_POST['email'], '@'))
{
echo "<html><head><title></title></head><body>";
echo "ERROR: Please enter a valid email address.";
echo "</body></html>";
exit();
}
?>
Now, if the Submitter does enter data into the "email" field, BUT did not put it in the correct syntax (ex: they entered user.somedomain.com instead of [email protected]) then the "if" statement in RED would trigger and the error message shown in GREEN would popup (NOT the ones in BLUE, because they didn't leave the field blank, they did enter something, just not in the right syntax).
I do not see how the wrong error message could be triggered if the software programming is done right. This just doesn't make sense to me, unless there is someone at MBT sitting there triggering those error messages manually, which then would be just ridiculous, lol.
The programming script should handle all the "if" statements with corresponding error messages automatically unless whoever wrote the scripting code doesn't know what they are doing (which I highly doubt is the case). So you see why I really can't understand how this "wrong error messages sent" is possible and your statement ...
Regarding this issue of people getting “logged off by someone else,” it isn’t really happening as described here on the boards
If you look back at all my posts, I have never complained once about any kind of injustice that was done to me (because I have not encountered any thus far), and my posts are normally mainly suggestions/concerns/issues that I feel are fair and just in bringing up. I actually would have been satisfied with the "monitoring" aspect for an explanation (as long as none of our trades are messed with), because I know that EFX/MBT has a vested interest in not having customers get overextended on their margins/capital, but you're saying that we are monitored without MBT having to login, so I would have to say that if this "someone has logged in as you" error message keeps happening, then somebody needs to look further into it than just saying that the wrong popup message was sent.
Also, the message does not say "logged off by someone else," (as you wrote) it says more like "someone has logged in as you" (there is a difference in logging off and logging in, lol. Yes, logging off could be due to connection being dropped, but logging in is a whole different story, it would require the username and password being used to login, right? Logging off does not require this info to do so).
If you want, when my husband comes home I can have him install a copy of Navigator on his computer and have him login to my account while I'm logged in, then I'll take a screenshot to show you what the exact message looks like if you need to see it. Let me know if you want me to do that.
Also, regarding that log info I mentioned in the other thread where our passwords are not encrypted ... here's the section of the code with the login info in my MSGS0730.log file for today's login (I have replaced my username and actual password with asterisks - but everyone can find this info easily in their own Navigator log files to see their password clearly written there. This is not a good security measure for any type script/program to store non-encrypted passwords in log files. Also, the "hostID" (shown in BLUE) should show an IP address of the user who logged in, again for security reasons, so we can see if the login was done by someone other than ourselves):
[06:00:01.578] MbtNav -T- Login dialog return: user=******, hostid=0
[06:00:01.609] MbtNav -T- CMbtComMgr::CreateClientRun hThread=3d4 tid=678
[06:00:01.609] MbtNav -I- CMbtComMgr::CreateClient, partner id=0
[06:00:01.609] MbtNav -T- MBTClient() 0xdeb548 216.52.236.18:5030 tid=0x678
[06:00:01.625] MbtNav -T- ClientSocket() 0xde5e48 tid=678
[06:00:01.718] MbtNav -T- -ClientSocket() 0xde5e48 tid=678 sock=0x380
[06:00:01.718] MbtNav -T- MBTClient::Open returning true
[06:00:01.718] MbtNav -T- MBTClient() 0xdeb548 return
[06:00:01.718] MbtNav -T- PermClient:ermClient 0xdeb548
[06:00:01.765] MbtNav -T- PermClient::Login...calling mbt_encryptString on **********
[06:00:02.171] MbtNav -I- CMbtComMgr::GotMaxCtrlInfo
These are important security aspects/measures that I feel need to be implemented. I hope they will also be implemented in the Omega project.
Like I said, I have been very happy with EFX/MBT so far and I hope to continue to do my trading with you for a long time. Just please don't falter on your service, honesty, integrity and ethics.
Oh Justin, now how about my question regarding the "now-you-see-it, now-you-don't" candlestick spike (a few posts back), lol? 
Do you know what the story is with that?
Thanks for whatever answer you can give. It was just a little disturbing to see the candlesticks change like that, especially because some of us read candlesticks in our trading systems/strategies.
Do you know what the story is with that?
Thanks for whatever answer you can give
. It was just a little disturbing to see the candlesticks change like that, especially because some of us read candlesticks in our trading systems/strategies.
I'm looking forward to the answer as well as this problem is not isolated to EFX. By the way, I'll share the only response I ever got from the retail broker. They said it was a connection problem and that technical support could ping my machine to help isolate the problem. I have yet to take them up on this as I figure I will try connecting on a different machine at a different location first. Funny, I find this always happens near the close of the daily candle, which is where I like to set my orders. I also rely on the High, low, close for pivots and fibs - very frustrating problem. If you're having this problem, watch closely, I bet you'll start to notice it all over the place.
Oh Justin, now how about my question regarding the "now-you-see-it, now-you-don't" candlestick spike (a few posts back), lol?
Do you know what the story is with that?
Thanks for whatever answer you can give
My business model
Get pips => Keep Pips => Repeat
They said it was a connection problem and that technical support could ping my machine to help isolate the problem. I have yet to take them up on this as I figure I will try connecting on a different machine at a different location first. Funny, I find this always happens near the close of the daily candle,
That wouldn't be the case for my incident, because as my screenshots show, several hours of candlesticks had already passed AND the FREE Intellicharts showed the data without the spike first (after I already saw the spike on my Intellichart) and then the spike reappeared on the FREE Intellicharts later, so something weird happened there and I can't see how it would be diagnosed as a connection problem.
The next time it happens to you, do a ping and tracert on your end instead of waiting to have them do it. The tracert will be more detailed in giving you all the connecting hubs going from your ISP connection to your forex broker's server. If you do not know the servername of your connection feed, then you can enter the IP address of the server it's on. You should have logs with login data that should indicate somewhere the IP address.
If you look at my post above with the MSGS0730.log info, on the 4th line you will see MBT's IP address for the server I login to. I can use that to do pings and tracerts. Hopefully, you have data similar somewhere in your log files. If not, ask your forex broker for the IP address of their data server you login to.
You may already know how to do a ping and tracert, however I am going to post the instructions anyway, just in case you don't (or for anybody else who might need it):
1) Click your "Start" button on the bottom left corner of your computer monitor.
2) Click "Run"
3) Type in --> cmd
4) Click "OK"
5) You will see a DOS window appear. At the flashing cursor, type --> ping <IP address> (do not type in the < >, that's just to show you that the IP address goes there)
6) After you do a ping, to do a tracert ... at the cursor, type --> tracert <IP address>
Example (what I type to ping to MBT's data server) --> ping 216.52.236.18
Example --> tracert 216.52.236.18
If your connection is fine, you will not get any "timeouts" and the ping/tracert will complete.
If you don't get any timeouts, then I can't see how it's your connection that is causing the weird data glitch, as they are stating