I'm not sure if this is a bug yet or not, but I am currently using world.Export ?ping topic to find out if a server is "live" or not and it takes WAY too long to return... I don't remember this behavior taking this long a few versions back, especially when I was testing the link() transferring bug... (it used to return instantly but perhaps it is slower with real-world ip addresses)
I guess this leaves me with asking something about what happens here, because I'm not seeing why this takes so long to return when the target destination is dead. For example: I will call world.Export("my_own_ip_address:unused_port?ping") and it will take almost a full 30 seconds to a minute to return 0.
ID:1322754
 Jul 12 2013, 10:45 pm (Edited on Jul 12 2013, 11:43 pm)
(See the best response by Stephen001.)
|
|
|
Jul 12 2013, 11:41 pm
|
|
Eternal_Memories
 |
I think you should post this on Bug Reports or something, to me it's always been a bit laggy, I used a VPS in the past with some remote procs and I needed some seconds for simple procs, maybe you have to use spawn() or something like when you get information from HUB. I hope somebody gives a good answer because I'm interested too.
|
The TCP connection is timing out, basically. Depending on your firewall configuration, the target machine / router may either return a TCP RST to cause a connection reset, an ICMP destination unreachable, or simply ignore the request and cause the TCP connection to time out on the sender's end.
TCP RST and ICMP destination unreachable should give you a response in about the same time as it took to send the request, so across the web say ... 2 or 3 seconds tops, on a slow connection. The timeout case is much slower, as the target machine sends no such response. The timeout on that will depend on the sending machine/application's settings, and can easily be measured in minutes, but usually is 30 seconds. A lot of home firewalls are configured to "stealth" ports, by not sending an appropriate reset response, as such, they'll exhibit this behaviour. Within a local network context, usually Windows machines send an appropriate reset. Hence you saw instantaneous response locally I assume. | |
I see. I've decided to go with the master-server approach and just keep a list of who exists and ask the master-server if a particular server is alive or not. This will be much faster. The master-server can keep up to date on server life by pinging it AFTER its alive, which will then be much more acceptable to take a while if it dies after that.
| |