
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
I think the time the terminal takes to realize that a connection to the server is lost depends on exactly where the disconnection occurs. I have just tried "block network traffic" in ESET firewall on my computer and it took over a minute. Whereas when I disable "Local Area Connection" in Windows Control Panel, it took 7 seconds.
I think it would also take over a minute if you physically unplugged the network cable from the computer.
If you logged ticks with an IsConnected() check you'd often see the long price freezes just before IsConnected() = 0 as I've posted above.
HyperDimension,
It is not isConnected()'s fault. You are effectively being constrained by TCP timeout settings. On the firewall, if you "reject" the connection instead of "drop", you should see client respond immediately. Try these tests with the "telnet" application. Open a DOS command prompt (cmd in run and enter) and type 'telnet [HOST] [PORT]'. If it connects it will show you the escape character. To come out, ctrl + ] and quit. Now try all the tests that you did before. Substitute [HOST] and [POST] with your target server and port. In fact you can try telnet tests with any computer as server that has a port listening - all it does is opens a socket.
You can alter the TCP timeouts in the windows registry. But be careful, it can cause problems if you tweak below recommended settings.
In the above tests, you can view the connection by typing 'netstat -na'. It will show you the TCP status, Source, Destination etc of the connected socket. Listening ports are shown as 'LISTEN'.
Cheers
Texto
HyperDimension,
It is not isConnected()'s fault. You are effectively being constrained by TCP timeout settings. On the firewall, if you "reject" the connection instead of "drop", you should see client respond immediately. Try these tests with the "telnet" application. Open a DOS command prompt (cmd in run and enter) and type 'telnet [HOST] [PORT]'. If it connects it will show you the escape character. To come out, ctrl + ] and quit. Now try all the tests that you did before. Substitute [HOST] and [POST] with your target server and port. In fact you can try telnet tests with any computer as server that has a port listening - all it does is opens a socket.
You can alter the TCP timeouts in the windows registry. But be careful, it can cause problems if you tweak below recommended settings.
In the above tests, you can view the connection by typing 'netstat -na'. It will show you the TCP status, Source, Destination etc of the connected socket. Listening ports are shown as 'LISTEN'.
Cheers
Texto
Forgot to mention, if you want to get deeper, install "wireshark", apply filter and trace packets.
For tcp settings - http://support.microsoft.com/kb/170359
http://support.microsoft.com/kb/158474
It is not isConnected()'s fault. You are effectively being constrained by TCP timeout settings. On the firewall, if you "reject" the connection instead of "drop", you should see client respond immediately.
As I wrote earlier, when I blocked all traffic on my firewall the terminal took over a minute to realize that connection was lost. It did not respond immediately. Yet if I ping www.google.com duiring this lost connection I get the "General failure." message withiin a second on each of the 4 attempts.
Try these tests with the "telnet" application. Open a DOS command prompt (cmd in run and enter) and type 'telnet [HOST] [PORT]'. If it connects it will show you the escape character. To come out, ctrl + ] and quit. Now try all the tests that you did before. Substitute [HOST] and [POST] with your target server and port. In fact you can try telnet tests with any computer as server that has a port listening - all it does is opens a socket.
Do you mean try to connect to the broker's server via telnet?
if you want to get deeper, install "wireshark", apply filter and trace packets.
I've tried that before but the stream is encrpyted. What have you found?
What I'm thinking of doing is use ICMP from MQL to ping the server every 5s. I'd expect to get an error message as a response within a second or so if the connection was lost, similar to what I got when I tried to ping after I blocked all traffic via my firewall. I don't think that it would take 60s to get one of these responses:
Destination Unreachable
When a packet is undeliverable, a Destination Unreachable, Type 3, ICMP is generated. Type 3 ICMPs can have a Code value of 0 to 15: