[RESOLVED] Finding All IP addresses on a local network taking too long

[ctullar]

I am trying to enumerate all of the IP addresses on my local network using SendARP, like so:

For nIndex = 1 To 254
uIPAddr.s_b4 = CByte(nIndex) 'fourth byte of the IP address
LSet uIPAddrCompat = uIPAddr ' Convert 4 bytes into 1 long.
nMacAddrLen = 8 ' Indicate that we are allocating a buffer with 8 bytes.

' Try to find the MAC address for this IP.
If SendARP(uIPAddrCompat.ul, 0&, uMacAddr, nMacAddrLen) = 0 Then
' MAC addresses are 6 bytes long.
If nMacAddrLen = 6 Then
vasLocalIP(3) = CStr(nIndex)
j = j + 1
Text1.Text = Text1.Text & j & ". " & Join(vasLocalIP, ".") & " - " & MacAddrString(uMacAddr, nMacAddrLen) & vbCrLf
DoEvents
End If
End If
Next nIndex

This acts very quickly with IP addresses that are on the network, but far too slow to be practical for IP addresses that are not being used. To go through all 254 possibilities takes a minute or two. Maybe more - I lost interest in timing it.

Is there a faster way? Or is there a way to speed this method up? I was able to enumerate all of the computers on my network with NetServerEnum. Is there a similarly easy way to enumerate all IP addresses?

[si_the_geek]

Simply removing DoEvents should make it noticeably faster, perhaps by a large amount.

If you were using it just so that the textbox would show its changes, you shouldn't... what you should do is tell the textbox to do that, by using: Text1.Refresh

[Schmidt]

Simply removing DoEvents should make it noticeably faster, perhaps by a large amount.

I'd not expect that, because in most network-APIs of that type, requests against a not existing IP (or Hostname)
can take 30secs or up to a minute until they time-out.

I think, that's the problem there too (with the SendARP-function) ...

And as with all those blocking IP-Info-APIs - they will return much faster, when the IP in question *does*
exist on a given Network (the OP noticed that too already).

So, how to get a List of "valid and responsible IPs" on a given SubNet very fast - that's the question -
and one of the answers can be the usage of the asynchronously working ICMPSendEcho2-function.

@the OP:

In the thread-link below, I've posted code, which shows how to use this asynchronous API - and after only
~100msec you will have an answer already (in a Collection), which of the IPs on a given SubNet sent back
a Response-Ping in the just mentioned (100msec) wait-interval (which is adjustable of course - but in practice
rarely needs to be larger than 100msec on a modern LAN, "currently not under much stress").

http://www.vbforums.com/showthread.p...=1#post4476707

Olaf

[si_the_geek]

I'd not expect that, because in most network-APIs of that type, requests against a not existing IP (or Hostname)
can take 30secs or up to a minute until they time-out.

I didn't suggest it would be a total solution, just a step in the right direction - and not just in terms of direct speed, but also in terms of eliminating accidental re-entrancy etc.

I would expect async methods to have a more significant impact on the speed (but rarely had a need for network APIs etc myself, so wasn't sure which methods etc), but that doesn't mean that leaving DoEvents in there is sensible.



ctullar, what is your reason for doing this anyway? Depending on what you are actually trying to achieve, there may be a significantly better method (perhaps even running almost instantly).

[Schmidt]

I didn't suggest it would be a total solution, just a step in the right direction - and not just in terms of direct speed, but also in terms of eliminating accidental re-entrancy etc.

As for "eliminating accidental re-entrancy" - that's always a good reason, why DoEvents should only be used sparsely (or Not at all).

What I had a problem with was your: "removing DoEvents should make it noticeably faster".

Can you explain, where in a routine which according to the OP:
"To go through all 254 possibilities takes a minute or two. Maybe more ..."

the "significant speedup" shall be coming from, just by leaving out DoEvents (which in itself has a call-overhead of perhaps only a few micro-seconds).

The Loop is a very small one - here re-written in principle:

For nIndex = 1 To 254

   If SendARP(...) = successful Then

       Text1.Text = SomeNonExpensiveResultFormatting
       DoEvents 'to allow the TextBox some "breathing-room" for Refreshing - though better would be Text1.Refresh in this case ...

   End If
Next nIndex

Or expressed in other terms:

Dim nIndex

  'this will happen "in no time"
  For nIndex = 1 To 254
     If True Then
        Text1.Text = "SomeNonExpensiveResultFormatting"
        Text1.Refresh
     End If
  Next nIndex
  
  'but this as well (despite having the Text1.Refresh replaced with DoEvents)
  For nIndex = 1 To 254
     If True Then
        Text1.Text = "SomeNonExpensiveResultFormatting"
        DoEvents
     End If
  Next nIndex

Just fighting a myth here, that using DoEvents is somehow "magically slowing down your Application significantly" -
DoEvents is "known to be evil" (not recommended) for other reasons - but not because it is causing SlowDowns.

Olaf

[Niya]

I can see where Si is coming from. DoEvents orders all messages logged in the main thread's message queue to be processed. Paints, mouse moves, keystrokes, clicks. You are going to take some kind of performance hit by doing this repeatedly inside a loop.

[Niya]

Here I found a neat little article about DoEvents and performance.

[si_the_geek]

Just fighting a myth here, that using DoEvents is somehow "magically slowing down your Application significantly" -
DoEvents is "known to be evil" (not recommended) for other reasons - but not because it is causing SlowDowns.

I did not say or imply that removing DoEvents would eliminate the majority of the time in this case, I even made it clear that the effect would probably be small.

The time that DoEvents takes to run varies significantly (depending on a wide variety of things about the application, the computer it is running on, other applications/services that are running, and the entire Windows environment at the time), but will clearly be slower than just refreshing a single control.

I don't know all of the causes for it being slower in some cases (one odd case I remember seeing was due to antivirus software, which somehow made it take about 10 seconds per call), but the reasons don't really matter as the solution is far easier than attempting to even work out what the causes are, let alone attempt to work around them somehow.

For just 254 iterations the slowdown could be as little as a few milliseconds, but it could also be over 20 seconds - and there have been many cases on this site over the years where the slower end of the spectrum has occurred (and of course many more like the article Niya linked to where there is a loop with more iterations, in which case the speed effect of DoEvents can be huge).

[Niya]

The time that DoEvents takes to run varies significantly (depending on a wide variety of things about the application, the computer it is running on, other applications/services that are running, and the entire Windows environment at the time), but will clearly be slower than just refreshing a single control.

Services and other applications are actually less important than you think. DoEvents only deals with what is happening on the calling thread. It pumps the thread's messages so any slowdown could only come from the processing of these messages. The AV slowdown you described probably happened because the AV is sending messages to that app so when DoEvent pumps, those messages, whatever they are, will be processed thereby consuming their share of CPU cycles..

[si_the_geek]

Other applications/services will generally have little or no effect, but the antivirus example is just one of those where it has been a significant issue (and if I were to guess the cause, I would probably have come to the same idea of what was going on).


Anyway, that is enough debate about how much effect DoEvents is likely to have for the OP - lets keep this on topic folks.

[Schmidt]

Anyway, that is enough debate about how much effect DoEvents is likely to have for the OP - lets keep this on topic folks.

Perhaps you're right and this is not the place to dive deeper into that topic - so, in case you want to discuss further, I've opened a new thread here:
http://www.vbforums.com/showthread.p...nd-Performance

And as in most controversial discussed cases, I've underlined my claims (that DoEvents has not the slightest performance-issues) with concrete test-code
(meant as a friendly hint for you ).

Olaf

[ctullar]

Oops! I never got a notification that anyone had responded to this thread, and didn't find all of these responses until last week. Still not getting anywhere on this problem. But I realized I had not communicated the problem correctly. The real lag is not finding the IP addresses, but finding the MAC addresses. I am still relatively new to MAC addresses, so I'm not sure if there are other resources that I can use that can determine MAC addresses, but all I have used so far is SendARP().

Schmidt, I did use your code from the thread you suggested, and it found all of the IP addresses on the network very quickly, but then I realized that I need to find MAC addresses for all of those and I was stuck with the time hog routine again.

[westconn1]

I need to find MAC addresses for all of those and I was stuck with the time hog routine again.

why?
it was very easy to use the code from http://vbnet.mvps.org/index.html?cod...ressremote.htm to work with the code schmidt posted in other thread, only for the found ip addresses

@schmidt
i really liked the ping code but i got erratic results, changing the timeout helped a bit, initially i only got ping returns from my own machine and WAP, but far from good, do you have any thoughts on this, see results from immediate window below

got ping-answers from: 2 machines
192.168.1.1 00-60-64-09-72-15
192.168.1.28 00-22-5F-D0-28-93
got ping-answers from: 8 machines
192.168.1.1 00-60-64-09-72-15
192.168.1.2 00-14-78-ED-1E-1C
192.168.1.10 00-30-6E-FD-78-75
192.168.1.20 00-27-22-5C-C3-35
192.168.1.22 00-27-22-5C-C5-D8
192.168.1.28 00-22-5F-D0-28-93
192.168.1.102 00-0C-29-8F-DF-57
192.168.1.105 00-1D-7D-99-E1-A3
got ping-answers from: 9 machines
192.168.1.1 00-60-64-09-72-15
192.168.1.2 00-14-78-ED-1E-1C
192.168.1.10 00-30-6E-FD-78-75
192.168.1.14 DC-2B-61-81-10-B8
192.168.1.20 00-27-22-5C-C3-35
192.168.1.22 00-27-22-5C-C5-D8
192.168.1.28 00-22-5F-D0-28-93
192.168.1.102 00-0C-29-8F-DF-57
192.168.1.105 00-1D-7D-99-E1-A3
got ping-answers from: 6 machines
192.168.1.1 00-60-64-09-72-15
192.168.1.2 00-14-78-ED-1E-1C
192.168.1.10 00-30-6E-FD-78-75
192.168.1.20 00-27-22-5C-C3-35
192.168.1.22 00-27-22-5C-C5-D8
192.168.1.28 00-22-5F-D0-28-93
got ping-answers from: 13 machines '// i believe 12 would be the correct result
192.168.1.1 00-60-64-09-72-15
192.168.1.2 00-14-78-ED-1E-1C
192.168.1.10 00-30-6E-FD-78-75
192.168.1.14 DC-2B-61-81-10-B8
192.168.1.15 90-18-7C-6B-3F-0E
192.168.1.20 00-27-22-5C-C3-35
192.168.1.22 00-27-22-5C-C5-D8
192.168.1.28 00-22-5F-D0-28-93
192.168.1.102 00-0C-29-8F-DF-57
192.168.1.105 00-1D-7D-99-E1-A3
192.168.1.253 00-0C-76-A9-A2-E9
192.168.1.254 00-50-7F-1A-7C-F3
192.168.1.255 00-50-7F-1A-7C-F3
got ping-answers from: 9 machines
192.168.1.1 00-60-64-09-72-15
192.168.1.2 00-14-78-ED-1E-1C
192.168.1.10 00-30-6E-FD-78-75
192.168.1.14 DC-2B-61-81-10-B8
192.168.1.20 00-27-22-5C-C3-35
192.168.1.22 00-27-22-5C-C5-D8
192.168.1.28 00-22-5F-D0-28-93
192.168.1.102 00-0C-29-8F-DF-57
192.168.1.105 00-1D-7D-99-E1-A3
got ping-answers from: 8 machines
192.168.1.2 00-14-78-ED-1E-1C
192.168.1.20 00-27-22-5C-C3-35
192.168.1.22 00-27-22-5C-C5-D8
192.168.1.28 00-22-5F-D0-28-93
192.168.1.102 00-0C-29-8F-DF-57
192.168.1.253 00-0C-76-A9-A2-E9
192.168.1.254 00-50-7F-1A-7C-F3
192.168.1.255 00-50-7F-1A-7C-F3
got ping-answers from: 9 machines
192.168.1.1 00-60-64-09-72-15
192.168.1.2 00-14-78-ED-1E-1C
192.168.1.14 DC-2B-61-81-10-B8
192.168.1.20 00-27-22-5C-C3-35
192.168.1.22 00-27-22-5C-C5-D8
192.168.1.28 00-22-5F-D0-28-93
192.168.1.253 00-0C-76-A9-A2-E9
192.168.1.254 00-50-7F-1A-7C-F3
192.168.1.255 00-50-7F-1A-7C-F3
got ping-answers from: 9 machines
192.168.1.1 00-60-64-09-72-15
192.168.1.2 00-14-78-ED-1E-1C
192.168.1.10 00-30-6E-FD-78-75
192.168.1.20 00-27-22-5C-C3-35
192.168.1.22 00-27-22-5C-C5-D8
192.168.1.28 00-22-5F-D0-28-93
192.168.1.253 00-0C-76-A9-A2-E9
192.168.1.254 00-50-7F-1A-7C-F3
192.168.1.255 00-50-7F-1A-7C-F3

no machines were turned on or off during testing, of course 255 is not a valid result and i have now removed that from loop

[ctullar]

Whoa. Sorry guys - that does work really well. Not enough sleep.

I am able to find all the MAC addresses on my network in under five seconds every time now. It had been taking over a minute. Thanks for the responses - I'll mark resolved.