Detecting "remote-ness" (WAN/LAN/etc) and/or speed of a UNC share
-
Does anyone have any ideas on how to detect from a UNC share how remote (or fast) it is, i.e. is it on LAN or WAN etc? I need to be able to look at a list of UNCs and determine the fastest accessible one, to use for storing some temporary files for fast access by client apps. I have tried using MultinetGetConnectionPerformance to determine the connection speed, but it doesn't return sensible results.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
-
Does anyone have any ideas on how to detect from a UNC share how remote (or fast) it is, i.e. is it on LAN or WAN etc? I need to be able to look at a list of UNCs and determine the fastest accessible one, to use for storing some temporary files for fast access by client apps. I have tried using MultinetGetConnectionPerformance to determine the connection speed, but it doesn't return sensible results.
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
Other than doing a ICMP ping to the target box, there's no real way to do this. No matter what you use though, there is nothing that takes into account the load on the target box. So, you may have a quick TCP/IP path to it, but the box is too busy to respond in a timely fashion.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Other than doing a ICMP ping to the target box, there's no real way to do this. No matter what you use though, there is nothing that takes into account the load on the target box. So, you may have a quick TCP/IP path to it, but the box is too busy to respond in a timely fashion.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Thanks for your reply. This makes perfect sense - I hadn't taken into account the time for a machine to pull it's finger out and get around to responding! I had another couple of thoughts though: Given that all I want to do is to offer a user a reasonably sensible default server share to use for storing 'local-ish' cached data, from a list of admin-configured possibilities, what about either finding out where the server is geographically, and seeing which is closest to the client, or even finding out the server's time zone, and using the one with the smallest offset from the client? Not sure if either of these are possible or feasible. Any ideas?
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
-
Thanks for your reply. This makes perfect sense - I hadn't taken into account the time for a machine to pull it's finger out and get around to responding! I had another couple of thoughts though: Given that all I want to do is to offer a user a reasonably sensible default server share to use for storing 'local-ish' cached data, from a list of admin-configured possibilities, what about either finding out where the server is geographically, and seeing which is closest to the client, or even finding out the server's time zone, and using the one with the smallest offset from the client? Not sure if either of these are possible or feasible. Any ideas?
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)
Well, timezone doesn't guarantee localness. A method that I though about would be to generate a table of primary and alternate cache servers using IP network information. The application could get it's own IP address and subnet, figure out it's network address, then lookup in this table what the closest cache server would be and use that. If the first cache server fails, the alternate could be used. Or, the list of cache server could be used so the client could tracert to each server and figure out the closest server by hop count, and alternatively, by response time of the pings going to it. Maybe even a weighted evaluation of connection quality. This, of course, would take a considerable amount of time compared to other schemes, but is possible to do with shorted cache server lists, maybe even limited by the user picking a geographic region.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
Well, timezone doesn't guarantee localness. A method that I though about would be to generate a table of primary and alternate cache servers using IP network information. The application could get it's own IP address and subnet, figure out it's network address, then lookup in this table what the closest cache server would be and use that. If the first cache server fails, the alternate could be used. Or, the list of cache server could be used so the client could tracert to each server and figure out the closest server by hop count, and alternatively, by response time of the pings going to it. Maybe even a weighted evaluation of connection quality. This, of course, would take a considerable amount of time compared to other schemes, but is possible to do with shorted cache server lists, maybe even limited by the user picking a geographic region.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Many thanks for the info. It gives us some other things to play with, though given that we're only in practice looking at two or three alternative servers, I think for now we'll probably just ask the user to choose which one to use the first time they need it!
"The way of a fool seems right to him, but a wise man listens to advice" - Proverbs 12:15 (NIV)