In DTK's code you discovered AMT machines by using asynchronous operation for connecting socket, is there any particular reason for doing this, can't we use regular socket connect (C++, not C#) operation for connecting, infact I am using connect() (C++) for sockets, and in another thread, monitoring the socket, if does't connect in 500ms I do a closesocket on it. Shouldn't this work, it works to some extent but after 10 openings it stops for some time (around 20 sec) and then moves on.
There is a Discovery sample in the SDK also... it is not written in C# and might provide a clue in some fashion as to your delima. Perhaps a quick code walk thru that example may be helpful... perhaps not... just a thought. BTW, what does it mean when you say "it then moves on"? Does it move on to discover more systems? Are all of the systems on the same network resolvable by the same DNS, etc...?
Where is Discovery Sample in SDK ... ?
By "it then moves on" means that processing moves on.
Actually when I do a closesocket in the monitor thread for a socket (lets say s1), the connect( for s1 ) blocking call returns immediately but, after 10 sockets it takes around 22 secs and doesn't return immediately.
I patched windows xp and increased this 10-connection limitation to 50, then it returns immediately after 10 sockets, but I dont want to patch XP.
The URL of patch http://www.lvllord.de/download.php?url=en/EvID4226Patch223d-en.zip
Yes, in the Intel AMT DTK I have a class called "AMTDiscovery.cs" that does discovery and I just used async-sockets instead of lots of threads. Both are good options. John is right that ever since Windows XP SP2, there is a limit on the number of bad connections an application can make and so, it is not possible to make discovery faster by making more TCP connections.
If you are searching for computers in the same subnet, you could ARP the computer first and only try TCP connections on computers that respond to ARP. This is much faster, but it only works within the same subnet.
Ylian (Intel AMT Blog)