Intercepting multiple network connections?

FuturShoc

Active member
Joined
Jul 28, 2006
Messages
27
Location
Hot Springs, Arkansas
Programming Experience
3-5
I have a theory on this, but since I'm still very much a newbie at VB, much less .NET, I figured I should ask you fine folks here before flat-out denying the development request I have for it.

We apparently need to somehow intercept an XP user's attempt to establish a second network connection. (ie. Ethernet and, say, wireless). The request asks that this theoretical application/service warn the user with a dialog of some kind, forcing them to either disconnect from one network method before connecting, say, wirelessly, or cancel the new attempt and stay on the existing connection - and vise versa.

Point being, we don't want a user to be able to have two connections going at once because this makes remote troubleshooting a bit trickier for us, the support group.

My theory here is that in order to actively intercept a user's attempt like this, the application we would deploy would need to be a service of some kind. By extension, that service would also have to do so much polling of the user's actions while it waits for that second connection attempt that the service would suck up WAY too much of the OS's resources - making the existence of said service a complete dog on the PC.

Am I out of line with this assumption? Is there some magic I don't know about which would allow a developer (.NET Dude, aka me) to "attach" some kind of action to a user's attempts to intitiate network connections?
 
alternately you could establish knowledge that:

A dialup connection will have metric 1
A wired lan connection will have metric 20
A wireless lan connction will have metric 25

VB.NET:
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 13 ce c9 7a d1 ...... Intel(R) PRO/Wireless 2915ABG Network Connec
0x3 ...00 0a e4 c4 d2 32 ...... Broadcom NetXtreme Gigabit Ethernet - Packet
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.0.0.247       10.0.0.62       25
          0.0.0.0          0.0.0.0       10.0.0.247       10.0.4.69       20
         10.0.0.0      255.255.0.0        10.0.0.62       10.0.0.62       25
         10.0.0.0      255.255.0.0        10.0.4.69       10.0.4.69       20
        10.0.0.62  255.255.255.255        127.0.0.1       127.0.0.1       25
        10.0.4.69  255.255.255.255        127.0.0.1       127.0.0.1       20
   10.255.255.255  255.255.255.255        10.0.0.62       10.0.0.62       25
   10.255.255.255  255.255.255.255        10.0.4.69       10.0.4.69       20
     64.202.189.0    255.255.255.0       10.0.0.247       10.0.4.69       18
        67.15.0.0      255.255.0.0       10.0.0.247       10.0.4.69       18
       67.15.84.0    255.255.255.0       10.0.0.247       10.0.4.69       18
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
        224.0.0.0        240.0.0.0        10.0.0.62       10.0.0.62       25
        224.0.0.0        240.0.0.0        10.0.4.69       10.0.4.69       20
  255.255.255.255  255.255.255.255        10.0.0.62       10.0.0.62       1
  255.255.255.255  255.255.255.255        10.0.4.69       10.0.4.69       1
Default Gateway:        10.0.0.247

within the group. Ths will help determine which interface is being used.. (lower metrics are used preferentially)?
 
Ok, that seems like a good lead on how to do the basics of this, but it would be helpful to know if the basic idea of attaching code to the user's ACT (event) of establishing a network connection is even possible.

?

The long and short of it is that my boss seems to think this is a no brainer, but I don't think a developer is theoretically able to do this. I'd like to be able to back up my claim with at least input from another experienced .NET developer(s).
 
Back
Top