q721kjh
asked on
Accessing same Internet host through multiple DUN connections
For some specialized test software, I need to access an Internet host through multiple Dial-Up Networking connections through multiple modems and multiple ISPs on Windows 95.
The test host has multiple COM ports, each with a different modem attached. There are multiple DUN Connections defined, one for each modem, each to a different ISP.
This is how I am thinking the software will work:
The client software on the test host has one thread or instance for each DUN Connection. The client establishes the connection, then learns the IP address (which is accessible through the RAS API) for that connection. It creates a TCP connection, binding the interface address of the DUN connection it established as the local IP address (instead of letting the OS pick one for it.)
But, will Windows 95 actually route the client's TCP traffic through the interface created by the DUN connection the client just established?
I am not certain if Windows 95 will let it. I suspect Windows 95 will try to send the traffic for all clients out only one of the interfaces.
Typically this would be the connection associated with the default route.
If I create a default route (or, a route to the Internet host) for each DUN connection, and each client binds to the interface address associated with the DUN connection it wants to use for IP traffic, will Windows 95 route that traffic through the desired connection? Or will it force it through the first default route it encounters in the routing table? Or, is there something else I should do to make this work?
I have assigned extra points to this question because I am looking for a specific answer by someone who has done this and can tell me the configuration to make it work. If I am breaking routing rules, a reference to the applicable RFC or Microsoft Knowledge Base article or similar profound piece of work will get the points. Similarly, higher grades will be assigned when references to applicable articles showing how it should work are made. If you plan to post an answer, please check the "email notification" box as I expect a few clarification comments to be exchanged.
I would like to avoid a solution where the Internet host is configured with multiple IP addresses, and each client specifies a different IP address, and a route is created to that IP address through the interface address associated with the DUN connection the client established. I would like the Internet host to have only one IP address. It is most desirable for the Internet host to have one IP address.
I suspect I could also initiate the TCP connections from the Internet host, to each of the interface addresses on the test host (the Internet host would somehow have to be told these addresses, since most will be dynamically assigned.) This will force the traffic to travel at lease one direction, but I'm afraid the reverse traffic may still pass through only one of the interfaces, unless it is possible to set this beast up this funky way.
The test host has multiple COM ports, each with a different modem attached. There are multiple DUN Connections defined, one for each modem, each to a different ISP.
This is how I am thinking the software will work:
The client software on the test host has one thread or instance for each DUN Connection. The client establishes the connection, then learns the IP address (which is accessible through the RAS API) for that connection. It creates a TCP connection, binding the interface address of the DUN connection it established as the local IP address (instead of letting the OS pick one for it.)
But, will Windows 95 actually route the client's TCP traffic through the interface created by the DUN connection the client just established?
I am not certain if Windows 95 will let it. I suspect Windows 95 will try to send the traffic for all clients out only one of the interfaces.
Typically this would be the connection associated with the default route.
If I create a default route (or, a route to the Internet host) for each DUN connection, and each client binds to the interface address associated with the DUN connection it wants to use for IP traffic, will Windows 95 route that traffic through the desired connection? Or will it force it through the first default route it encounters in the routing table? Or, is there something else I should do to make this work?
I have assigned extra points to this question because I am looking for a specific answer by someone who has done this and can tell me the configuration to make it work. If I am breaking routing rules, a reference to the applicable RFC or Microsoft Knowledge Base article or similar profound piece of work will get the points. Similarly, higher grades will be assigned when references to applicable articles showing how it should work are made. If you plan to post an answer, please check the "email notification" box as I expect a few clarification comments to be exchanged.
I would like to avoid a solution where the Internet host is configured with multiple IP addresses, and each client specifies a different IP address, and a route is created to that IP address through the interface address associated with the DUN connection the client established. I would like the Internet host to have only one IP address. It is most desirable for the Internet host to have one IP address.
I suspect I could also initiate the TCP connections from the Internet host, to each of the interface addresses on the test host (the Internet host would somehow have to be told these addresses, since most will be dynamically assigned.) This will force the traffic to travel at lease one direction, but I'm afraid the reverse traffic may still pass through only one of the interfaces, unless it is possible to set this beast up this funky way.
j2
This is utterly impossible under W95, since no mather HOW you route it, you will still (eventually) be pointing all to the same target IP, this will mean that the first of the routes that handles the target IP will take over all traffic.
ASKER
But won't an explicit bind to the interface implicitly tell the routing software that I want to use that interface, if a route to the destination host exists for that interface?
The first route on the list is NOT always the first route chosen. The first route on (almost) every list is the default route. But if you have a second card to a local network, and a route to that network through the card, you don't go through the default route to get to that network, you use the direct route.
I realize the difference here is that I'm talking about a host NOT connected to a local network, and the example I've just given is a host CONNECTED to a local network. But my point is that there are exceptions to the "pick the first route to the host" rule. And this leaves me wondering if binding to an interface's address will also create an exception to this rule, if a route to that remote host exists through that interface, even if there are other interfaces with the same route.
That's why I'm looking for a reference from Microsoft Knowledge Base or an RFC stating that this will or won't work. If no one can provide this reference, then I will have to run the test myself. I will then award all the points to the person who has been the most helpful. (Right now that is you, j2, because you have provided the only answer.) (Creating the test may take a while, but I *will* award the points, by posting a comment asking that person to post an answer. That's why I made it 300 points - now 325 - to make it worth the wait. And, for the record, I promise to assign an "A".)
The first route on the list is NOT always the first route chosen. The first route on (almost) every list is the default route. But if you have a second card to a local network, and a route to that network through the card, you don't go through the default route to get to that network, you use the direct route.
I realize the difference here is that I'm talking about a host NOT connected to a local network, and the example I've just given is a host CONNECTED to a local network. But my point is that there are exceptions to the "pick the first route to the host" rule. And this leaves me wondering if binding to an interface's address will also create an exception to this rule, if a route to that remote host exists through that interface, even if there are other interfaces with the same route.
That's why I'm looking for a reference from Microsoft Knowledge Base or an RFC stating that this will or won't work. If no one can provide this reference, then I will have to run the test myself. I will then award all the points to the person who has been the most helpful. (Right now that is you, j2, because you have provided the only answer.) (Creating the test may take a while, but I *will* award the points, by posting a comment asking that person to post an answer. That's why I made it 300 points - now 325 - to make it worth the wait. And, for the record, I promise to assign an "A".)
This really should work. I am quite certain it at least works under Windows NT.
My computer has a dial-up connection to the internet, and a network card attached to a local LAN. I run WinNT 4.0.
When binding my socket to the local LAN IP address, I am unable to connect to Internet hosts - the first default route in the routing table is not used.
When binding to INADDR_ANY or the IP address of the ISP connection, I am able to connect.
My computer has a dial-up connection to the internet, and a network card attached to a local LAN. I run WinNT 4.0.
When binding my socket to the local LAN IP address, I am unable to connect to Internet hosts - the first default route in the routing table is not used.
When binding to INADDR_ANY or the IP address of the ISP connection, I am able to connect.
ASKER
Thank you, y96andha;
You're suggesting that binding to a specific address is essentially binding to a specific interface. You're suggesting that the routing table would be used to determine the correct interface to bind to, based on the destination address, if you used INADDR_ANY, and therefore, the routing effectively would occur at bind time. But that when you're binding to a specific address, you're implicitly binding to the interface which uses that IP address?
That would make *sense* - however, I know different OSs implement these things differently (for example, some versions of Linux will let you assign the same IP address to multiple interfaces - a really bad idea!) I have heard that the Windows NT and Windows 95 networking subsystems are very similar, but I'm not sure this extends down to the level of routing; for example, Windows 95 is apparently capable of IP forwarding, but it's not really documented.
Your experience leads me to think it may work, but there are enough differences -
- windows 95 vs NT
- ethernet and ras VS two DUN connections
- dual routes to the same Internet host
- that force me to put this question back out there for more specifics, or, a reference to an RFC or KB article or snippet of network code or something indicating that this is indeed how it should work.
So, I goofed when I tried to adjust the points last time, so I will raise them again (now, 350 x A.)
You're suggesting that binding to a specific address is essentially binding to a specific interface. You're suggesting that the routing table would be used to determine the correct interface to bind to, based on the destination address, if you used INADDR_ANY, and therefore, the routing effectively would occur at bind time. But that when you're binding to a specific address, you're implicitly binding to the interface which uses that IP address?
That would make *sense* - however, I know different OSs implement these things differently (for example, some versions of Linux will let you assign the same IP address to multiple interfaces - a really bad idea!) I have heard that the Windows NT and Windows 95 networking subsystems are very similar, but I'm not sure this extends down to the level of routing; for example, Windows 95 is apparently capable of IP forwarding, but it's not really documented.
Your experience leads me to think it may work, but there are enough differences -
- windows 95 vs NT
- ethernet and ras VS two DUN connections
- dual routes to the same Internet host
- that force me to put this question back out there for more specifics, or, a reference to an RFC or KB article or snippet of network code or something indicating that this is indeed how it should work.
So, I goofed when I tried to adjust the points last time, so I will raise them again (now, 350 x A.)
You can note that when specifying routes in both Win95 and WinNT, the indication of what interface to use is the IP address of the interface.
Effectively, when using INADDR_ANY, the bind to a specific IP address occurs when first connecting instead of when calling bind. This bind is based on the routing table. It is documented in the Winsock specification that when binding to INADDR_ANY, you cannot get the address bound to until after you have made the connection on it.
I could try it with compiling my program and rebooting in Win95 mode, and perhaps even with a LAN connection and dial-up connection simultaneously, but I don't think I'll be able to find a machine to try dual DUN connections on.
Effectively, when using INADDR_ANY, the bind to a specific IP address occurs when first connecting instead of when calling bind. This bind is based on the routing table. It is documented in the Winsock specification that when binding to INADDR_ANY, you cannot get the address bound to until after you have made the connection on it.
I could try it with compiling my program and rebooting in Win95 mode, and perhaps even with a LAN connection and dial-up connection simultaneously, but I don't think I'll be able to find a machine to try dual DUN connections on.
ther is a point on the settings for each DUN connection named 'use default geatway on remote site'
in case of you have checked this point the default route wil be automaticaly added on established connection. to ensure that this interface wil be used, you have to remove all default gateway entries inside the networksetup because only the first default is used.
this means setup all paramters for dialing adaptor and all network adaptors whithout default gateway and dns servers.
select on setup of DUN connection to assign gateway and DNS servers.
if you have a preferred ISP then setup this connection as default internet connection. if not, setup LAN should be used.
in all cases your not connected to a default site, you have to establish the connection manually and then this connection can be used as a normal LAN.
much more diffical is the setup of different proxies. but this is not your problem (i think)
good luck Heiko
in case of you have checked this point the default route wil be automaticaly added on established connection. to ensure that this interface wil be used, you have to remove all default gateway entries inside the networksetup because only the first default is used.
this means setup all paramters for dialing adaptor and all network adaptors whithout default gateway and dns servers.
select on setup of DUN connection to assign gateway and DNS servers.
if you have a preferred ISP then setup this connection as default internet connection. if not, setup LAN should be used.
in all cases your not connected to a default site, you have to establish the connection manually and then this connection can be used as a normal LAN.
much more diffical is the setup of different proxies. but this is not your problem (i think)
good luck Heiko
ASKER
Hello Heiko,
Disabling all default gateways is an interesting idea. The problem is that you still need a route to the destination. Since I need to connect to the same host through each DUN interface, there has to be a route to that host through every DUN interface. So, we're back to the question of whether or not the stack will pick the first route it encounters.
y96andha has suggested that binding to a local address in NT seems to cause the packets to leave the interface associated with that address. His tests indicated that for NT, it might work. When he bound to a local LAN address and tried to send to an Internet host, it did not work. (Did the traffic actually go out on the LAN, though? I use tcpdump on a Unix box to look at this, since it is easier to use than the Windows NT packet monitor.)
I read about INADDR_ANY in my Winsock book, and it does provide hope that binding to the local address may get you the interface, but there's still the issue of implementation.
I am attempting to write a piece of code to test his theory (I wanted to avoid this.) I will leave this question out there until either we can get a more definitive answer or I discover the answer through my testing, then we'll deal with the points. I've raised them in case someone wants to test this themselves.
Disabling all default gateways is an interesting idea. The problem is that you still need a route to the destination. Since I need to connect to the same host through each DUN interface, there has to be a route to that host through every DUN interface. So, we're back to the question of whether or not the stack will pick the first route it encounters.
y96andha has suggested that binding to a local address in NT seems to cause the packets to leave the interface associated with that address. His tests indicated that for NT, it might work. When he bound to a local LAN address and tried to send to an Internet host, it did not work. (Did the traffic actually go out on the LAN, though? I use tcpdump on a Unix box to look at this, since it is easier to use than the Windows NT packet monitor.)
I read about INADDR_ANY in my Winsock book, and it does provide hope that binding to the local address may get you the interface, but there's still the issue of implementation.
I am attempting to write a piece of code to test his theory (I wanted to avoid this.) I will leave this question out there until either we can get a more definitive answer or I discover the answer through my testing, then we'll deal with the points. I've raised them in case someone wants to test this themselves.
ASKER
Adjusted points to 400
I suggest that you can have at least two IP connections. You will have to have two seperate IP address's bound to two modems, or two NIC's or one modem and one NIC. I have only done this with one modem and one nic, but you should be able to do the same with two modems, and if two work, I imagine you could get three to work also.
Be sure to use DHCP, and if you do, you will have two gateway addresses, the default on each dialed up connection. Be sure the bindings are correct.
Also, you say you are accessing the same network on both ports? I'm pretty sure you will have trouble with that in the same way I can not dialup to my own network with creating a network conflict. Two different networks should be ok.
Joe
Be sure to use DHCP, and if you do, you will have two gateway addresses, the default on each dialed up connection. Be sure the bindings are correct.
Also, you say you are accessing the same network on both ports? I'm pretty sure you will have trouble with that in the same way I can not dialup to my own network with creating a network conflict. Two different networks should be ok.
Joe
I don't have any good network monitor, but the SD/RD lamp on the card flashed. I am the only one using the network at this time.
ASKER
Hi Joe,
>I suggest that you can have at least two IP connections. You
>will have to have two seperate IP address's bound to two
>modems, or two NIC's or one modem and one NIC. I have only done
>this with one modem and one nic, but you should be able to do
>the same with two modems, and if two work, I imagine you could
>get three to work also.
Sorry, but I've already established that I can have multiple network interfaces to my machine. That part is easy. I also know several ways the routing table might look, and how to set it up. What we're looking for here is some documentation or actual experience regarding whether or not the Windows 95 networking components between the Winsock and the adapter will fulfill the need stated in the original question. y96andha has the most experience in this so far, having conducted a similar test, albeit with a different configuration and on an OS whose networking components are better hammered out.
>Be sure to use DHCP, and if you do, you will have two gateway
>addresses, the default on each dialed up connection. Be sure
>the bindings are correct.
Sorry, we've already been here too. Setting up the adapters is not the issue, unless a specific configuration is the recipe for success.
y96andha, the fact that your ethernet adapter signal flashed was a good indicator that at least traffic was dropped onto the network. Had you had a gateway to the Internet on that network (other than your host) it might have worked.
I will reopen this question until I finish the test SW or someone can come up with some literature... raising points from 400 to 425.
>I suggest that you can have at least two IP connections. You
>will have to have two seperate IP address's bound to two
>modems, or two NIC's or one modem and one NIC. I have only done
>this with one modem and one nic, but you should be able to do
>the same with two modems, and if two work, I imagine you could
>get three to work also.
Sorry, but I've already established that I can have multiple network interfaces to my machine. That part is easy. I also know several ways the routing table might look, and how to set it up. What we're looking for here is some documentation or actual experience regarding whether or not the Windows 95 networking components between the Winsock and the adapter will fulfill the need stated in the original question. y96andha has the most experience in this so far, having conducted a similar test, albeit with a different configuration and on an OS whose networking components are better hammered out.
>Be sure to use DHCP, and if you do, you will have two gateway
>addresses, the default on each dialed up connection. Be sure
>the bindings are correct.
Sorry, we've already been here too. Setting up the adapters is not the issue, unless a specific configuration is the recipe for success.
y96andha, the fact that your ethernet adapter signal flashed was a good indicator that at least traffic was dropped onto the network. Had you had a gateway to the Internet on that network (other than your host) it might have worked.
I will reopen this question until I finish the test SW or someone can come up with some literature... raising points from 400 to 425.
ASKER
Adjusted points to 425
Hi,
TCP/IP is a protected mode component, win95 provides the capability to support several concurrent connections provided they are protected mode components. MPR multiple provider router mpr.dll receives API calls and routes them with the specific SPI service provider interface.
If this is what you have in mind I will continue.
Good Luck
Rob
TCP/IP is a protected mode component, win95 provides the capability to support several concurrent connections provided they are protected mode components. MPR multiple provider router mpr.dll receives API calls and routes them with the specific SPI service provider interface.
If this is what you have in mind I will continue.
Good Luck
Rob
ASKER
FNNGroup,
Where does MPR.DLL fit into the Microsoft TCP/IP stack? Does it provide the NDIS interface that adapters attach to? I am not aware of the various components (other than Winsock and the NDIS interface that adapters use) which make up the Microsoft TCP/IP stack, and lie below the "client/adapter/protocol/s
Where does MPR.DLL fit into the Microsoft TCP/IP stack? Does it provide the NDIS interface that adapters attach to? I am not aware of the various components (other than Winsock and the NDIS interface that adapters use) which make up the Microsoft TCP/IP stack, and lie below the "client/adapter/protocol/s
Well all I have to say is
You have exceded the limit of the operating system.
There prehaps is some special software that could make this possable. I will go look it up. But I've tried to do stuff like this before and its esentally impossable without rewriting the os.
You have exceded the limit of the operating system.
There prehaps is some special software that could make this possable. I will go look it up. But I've tried to do stuff like this before and its esentally impossable without rewriting the os.
In my experience the Winsock included with WIN95 is rather criplled, No raw socket support, strong limitations regarding multiple cuncurrent IP addreses, etc.
From what I have seen, the only workarround that sort of works on 95 is to use a proxy server to handle the multiple IP's.
For your kind of testing, I would suggest you use an NT server eddition. It has support for multiple RAS and multiple IP integrated into the OS.
Hope this comment helps some.
From what I have seen, the only workarround that sort of works on 95 is to use a proxy server to handle the multiple IP's.
For your kind of testing, I would suggest you use an NT server eddition. It has support for multiple RAS and multiple IP integrated into the OS.
Hope this comment helps some.
The following article should take you well on your way. See the Microsoft Knowledge Base Q166288. As an example, here's an example of a test run from windows 95 OSR 2 on a Pent II with 3 Hayes 56k modems. Microsoft's IE 3.02 was installed to 3 separate directories. PPTP was installed and 3 dialup connections developed. Since I did not have the benefit of specialized single instance software for multiple connections, I created multiple instances of IE 3.02 connecting dialing through 3 dialup connections to the same ISP and all 3 routed to the typical Microsoft URL. From here I was able to manipulate the connection to go virtually anywhere on any of the three connections or back to the same site on all 3 instances of IE3.02. The only drawback will be the enormous resource drain.
Hope this helps you get where your going!
Best regards,
Dennis.
Hope this helps you get where your going!
Best regards,
Dennis.
ASKER
Dennis,
This looks pretty much the same as what I'm attempting. When you say you "manipulated the connections" so that traffic would go through any of the dial-up connections, did you do that by using "route" commands to manipulate the routing table? How were you able to tell each instance of IE3.02 to go through its own modem to get to the Microsoft site, or was the traffic from any one browser spread across all three modems (multilink enabled?)
This looks pretty much the same as what I'm attempting. When you say you "manipulated the connections" so that traffic would go through any of the dial-up connections, did you do that by using "route" commands to manipulate the routing table? How were you able to tell each instance of IE3.02 to go through its own modem to get to the Microsoft site, or was the traffic from any one browser spread across all three modems (multilink enabled?)
The secret is in the naming of the separate connections. I right click on the IE icon and changed each IE connection to the individual DUN I setup, eg: Internet one, Internet 2 and Internet 3. And yes, it is multilink capable. Furthermore, your ISP doesn't need to support multilink with either Unix or NT.
ASKER
Could you see (through modem LEDs, perhaps) that each instance of IE used its own modem, and none of the others, when all instances were running, and when multilink was disabled?
You don't need modem LEDs to determine independent connections. In order to invoke multilink, (with it enabled) you would make the first connection and windows automatically makes the second one. I have already used one browser to go to the MS OEM site, one to come here and the other to download from an FTP. Give it a try!. Like I said earlier, the only problem that I notice is the drain on system resoruces.
ASKER
Hi Dennis,
Sorry to keep this going (but I am still adding points). Let me explain why I'm asking you all these questions. My test program has multiple clients, each of which communicates to the same server, but over different modems. That is, I need all the traffic from one client to travel over only one modem. I do NOT want that client's traffic to be spread across the other modem connections, and don't want the traffic of the other clients to appear on any modem connection but their own.
There is a one-to-one mapping of clients and modems. I suspect that the solution you're presenting is one where multilink is used to allow traffic for one or more clients to travel across *all available* modem connections. However, what I am trying to do is bind the clients (and set up routes) in such a way that the traffic for each client goes out only on the interface specified for that client, and not on any other client's interfaces. Are we talking about the same thing?
Sorry to keep this going (but I am still adding points). Let me explain why I'm asking you all these questions. My test program has multiple clients, each of which communicates to the same server, but over different modems. That is, I need all the traffic from one client to travel over only one modem. I do NOT want that client's traffic to be spread across the other modem connections, and don't want the traffic of the other clients to appear on any modem connection but their own.
There is a one-to-one mapping of clients and modems. I suspect that the solution you're presenting is one where multilink is used to allow traffic for one or more clients to travel across *all available* modem connections. However, what I am trying to do is bind the clients (and set up routes) in such a way that the traffic for each client goes out only on the interface specified for that client, and not on any other client's interfaces. Are we talking about the same thing?
We are both going in the same direction, however what I have described involves naming convention issues not multilink. Let's separate issues here for simplicity sake.
Issue #1: Multiple modems with separate PPTP dial-up for each modem.
Issue #2: Multilink.
Issue #3: Multi-session software or multiple instances of alternate programs.
Let's deal with Issue #1 first. By developing, through the use of PPTP, independent DUN connections (eg; Connection #1, #2 and #3) with separate ID's we cause Windows, with the PPTP protocol, to use 3 independent modems, dial-up procedures and thereby 3 separate connections in lieu of a multilink connection. In doing so, we could (in theory assuming that there were 3 separate installations of IE in 3 separate subdirectories) cause each IE to function independently of the other three using the tunneling protocol. Since you would be using a specialized software, the last aspect of the above would be unnecessary as the software would be capable of handling separate sessions, although it would have to be able to recognize the naming conventions of the 3 separate DUN setups.
Issue #2: Multilink. Multilinking is a function invoked by windows when two modems are setup *identically* with the same DUN setup and identical naming conventions and your identification, during the multilink setup, of the *second* connection. This would then enable windows to establish the second connection on it's own once the first was established. Since we are not setting up multilink, but rather multiple DUN's on separate modems, multilinking issues are moot.
As for Issue #3, you would have to make sure that your specialized software is truly capable of handling the multiple *independent* DUN and modem connections. Keep in mind, you are only using that part of the DUN/PPTP necessary to establish the connection and direct tunnel to the IP address of your choice, not invoke multilink. Your software would point to the IP and establish the connection to that address, which is what I have done using multiple instances of IE 3.02. Of course,
other issues to come to the forefront, such as hardware capabilities etc.
Issue #1: Multiple modems with separate PPTP dial-up for each modem.
Issue #2: Multilink.
Issue #3: Multi-session software or multiple instances of alternate programs.
Let's deal with Issue #1 first. By developing, through the use of PPTP, independent DUN connections (eg; Connection #1, #2 and #3) with separate ID's we cause Windows, with the PPTP protocol, to use 3 independent modems, dial-up procedures and thereby 3 separate connections in lieu of a multilink connection. In doing so, we could (in theory assuming that there were 3 separate installations of IE in 3 separate subdirectories) cause each IE to function independently of the other three using the tunneling protocol. Since you would be using a specialized software, the last aspect of the above would be unnecessary as the software would be capable of handling separate sessions, although it would have to be able to recognize the naming conventions of the 3 separate DUN setups.
Issue #2: Multilink. Multilinking is a function invoked by windows when two modems are setup *identically* with the same DUN setup and identical naming conventions and your identification, during the multilink setup, of the *second* connection. This would then enable windows to establish the second connection on it's own once the first was established. Since we are not setting up multilink, but rather multiple DUN's on separate modems, multilinking issues are moot.
As for Issue #3, you would have to make sure that your specialized software is truly capable of handling the multiple *independent* DUN and modem connections. Keep in mind, you are only using that part of the DUN/PPTP necessary to establish the connection and direct tunnel to the IP address of your choice, not invoke multilink. Your software would point to the IP and establish the connection to that address, which is what I have done using multiple instances of IE 3.02. Of course,
other issues to come to the forefront, such as hardware capabilities etc.
ASKER
Adjusted points to 580
Have you tried it yet? Will the choice of making a certain RAS connection from IE really make that copy of IE transfer all of its data that way, or will all IE's use the connection last made?
ASKER
I was travelling and was not able to respond.
Issue 1:
I am not using PPTP. I am just setting up (lets say three) DUN connections. I have three applications. I want each to talk to the same remote host. I want to "bind" each application to its own DUN connection so that it uses it exclusively and none of the other DUN connections. See, I know I can bind to the address of a particular interface, but I don't know if that guarantees that Microsoft's IP stack will actually route through that interface, or if it will just make that address the source address of my packets, and instead route through the first interface it finds in the routing table with a route to the remote host. I guess that is the answer I am looking for, whether or not Microsoft's IP ignores the source address when deciding which interface to use when making routing decisions. Does IP ignore the source address? If there are three host routes (not default route table entries, but routing table entries specifying the host), each through different interfaces, does it pick the first it finds, or does it pick the one matching the IP address the application bound the socket to?
Issue 2:
yes, I am not multilinking.
Issue 3:
My software can easily fire up a DUN connection. But, as far as I know, you can't cause a piece of software to "own" the DUN connection it fires up. An application can fire up or kill any DUN connection, but generally, once the connection is up, all control of it (ie routing) reverts to the TCP-IP subsystem. I am looking for a way to force traffic for a particular application to use a particular DUN connection (interface in Unix language.) I suspect that I can do this by binding my socket to the IP address of the DUN connection (instead of INADDR_ANY) and making sure there is a route to the remote host for that interface. But what I'm trying to find out is,
Did you confirm that IE did anything more than fire up individual DUN connections? I would suspect that, when opening a socket, IE would bind to INADDR_ANY to avoid problems with picking an address for there was improper routing. Does each instance of IE actually send and receive all its traffic on the interface that it set up, and none other? Does it still, if each is directed to the same URL? If so, a "netstat -nr" would tell me how the routing table should (would) look.
To perhaps clarify the reason I'm asking if such a ridiculous setup can be done, I will explain that I am throughput testing a network medium which uses Dial-Up Networking to establish the connection. I am stress-testing the network, so I have to have multiple connections going through it. I initially described this as "dialing into seperate ISPs" since this is effectively what is happening. I could simply use one PC per connection to get the multiple connections, but this would require many PCs, so I want to minimize the number of PCs by having multiple instances of the test software running on each PC using its own connection. Since I need to load each connection, I need to ensure that each instance of the test application uses its own connection. So, I need to know if binding to the interface address is sufficient, or if there is more that I need to do, or if someone has done (or, for the number of points here, will do) this test and let me know the answer to the question: how do I write multiple instances of an application such that the data generated by each passes through its "own" network interface, when the remote host address is the same for all applications?
Issue 1:
I am not using PPTP. I am just setting up (lets say three) DUN connections. I have three applications. I want each to talk to the same remote host. I want to "bind" each application to its own DUN connection so that it uses it exclusively and none of the other DUN connections. See, I know I can bind to the address of a particular interface, but I don't know if that guarantees that Microsoft's IP stack will actually route through that interface, or if it will just make that address the source address of my packets, and instead route through the first interface it finds in the routing table with a route to the remote host. I guess that is the answer I am looking for, whether or not Microsoft's IP ignores the source address when deciding which interface to use when making routing decisions. Does IP ignore the source address? If there are three host routes (not default route table entries, but routing table entries specifying the host), each through different interfaces, does it pick the first it finds, or does it pick the one matching the IP address the application bound the socket to?
Issue 2:
yes, I am not multilinking.
Issue 3:
My software can easily fire up a DUN connection. But, as far as I know, you can't cause a piece of software to "own" the DUN connection it fires up. An application can fire up or kill any DUN connection, but generally, once the connection is up, all control of it (ie routing) reverts to the TCP-IP subsystem. I am looking for a way to force traffic for a particular application to use a particular DUN connection (interface in Unix language.) I suspect that I can do this by binding my socket to the IP address of the DUN connection (instead of INADDR_ANY) and making sure there is a route to the remote host for that interface. But what I'm trying to find out is,
Did you confirm that IE did anything more than fire up individual DUN connections? I would suspect that, when opening a socket, IE would bind to INADDR_ANY to avoid problems with picking an address for there was improper routing. Does each instance of IE actually send and receive all its traffic on the interface that it set up, and none other? Does it still, if each is directed to the same URL? If so, a "netstat -nr" would tell me how the routing table should (would) look.
To perhaps clarify the reason I'm asking if such a ridiculous setup can be done, I will explain that I am throughput testing a network medium which uses Dial-Up Networking to establish the connection. I am stress-testing the network, so I have to have multiple connections going through it. I initially described this as "dialing into seperate ISPs" since this is effectively what is happening. I could simply use one PC per connection to get the multiple connections, but this would require many PCs, so I want to minimize the number of PCs by having multiple instances of the test software running on each PC using its own connection. Since I need to load each connection, I need to ensure that each instance of the test application uses its own connection. So, I need to know if binding to the interface address is sufficient, or if there is more that I need to do, or if someone has done (or, for the number of points here, will do) this test and let me know the answer to the question: how do I write multiple instances of an application such that the data generated by each passes through its "own" network interface, when the remote host address is the same for all applications?
ASKER
y96andha's comment, will all IEs use their own connection or the one last made, is the same one I have, and if they all use their own, what are they doing with Winsock and the routing table to ensure they all use their own connection? Binding to the address of the interface (unix term for DUN connection) they just set up? Or are they binding to INADDR_ANY?
As I suggested already, I think. You can not connect one Win95 machine to one server through two different connections, now connecting one machine to two networks is a different story. You have limitations in Win95 that you won't have in NT. You could call Microsoft and get that verified for about $175, an then I could wait a month or so and give you the technet article on it. I didn't find any other articles that describe your exact situation, but I have done similar things , so that is how I learned of some of Win95 limitations, I did't read about it until much later.
Q: I understand where your going, which is why I set up the testing and gave your the information drived from it. I think it's a bit unfair to go down the road with this issue now and change the direction, eg: " I initially described this as "dialing into seperate ISPs" since this is effectively what is happening". This can, indeed, be accomplished as described previously. Can it be done, Yes! Is it practical NO. Is it efficient, NO. Frankly, if I were faced with the same circumstances I would build a small router out of a cheap Pentium or a cheap server/router out of a cheap Pentium and use that to handle the traffic. As for Y96 and Joe, yes WIN95 has limitations, however if you thoroughly understand those limitations you can create the workaround. As an example, by test machine is a Pentium Pro 200/512 with a 5G hard drive partitioned into 4 partitions, 3 modems, 3 instances of IE 3.02 and PPTP. Each instance of IE 3.02 makes it's own Winsock call from a separate winsock in that partition and connects to a preassigned modem. To accomplish this, each install of IE 3.02 has it's own naming convention so that windows recognizes each instance separately. This took some work, especially in the registry. Beyond this, you must use the MS PPTP protocol efficiently. As an example, most addresses are multiples, such as this site and can be accessed either randomly or with an address range preassigned. Therefore, if I instruct IE 3.02, by default, to access a lead address, it will read through the available chain for that group and make the connection. Now, since each instance of IE is independent of the other two and each has it's own dedicated modem, the traffic will flow either way through the preassigned modem. The traffic is a bit much to monitor as a smaller machine with lesser processor capability and insufficient memory resources may get bogged down with the cpu intensive load. The cpu load at times reaches approximately 37% of the total on each connection. You don't have to be a math major to realize that that's 111% of the CPU. Obviously, this could be handled more efficiently by a small 3 or 6 line router. Beyond this, the cache hits average about 30% with average traffic, and this doesn't allow for the efficient handling of bandwith on each socket. I hope this more clearly lays out what you asked, what your up against doing it this way as well as what would be required to handle something like this. As Joe indicated, NT (actually NT Server) may be a more efficient OS, given it's ability to layer CPU load, cache hits, socket utilization and multiple communication panels.
Your input would be helpful!
Best regards,
Dennis
Your input would be helpful!
Best regards,
Dennis
ASKER
Adjusted points to 585
I am online.
I just had to jump in here...
| Beyond this, you must use the MS PPTP protocol efficiently.
Why use PPTP? That's for VPNs. For providing a secure tunnel through the Internet to a VPN gateway machine on the border of a secure corporate network. Q said s/he was not using PPTP.
| As an example, most addresses are multiples,
| such as this site and can be accessed either randomly
| or with an address range preassigned.
Did I miss something in Networking 101? I thought that each host had a single IP address (except for some hosts which are multihomed.) Sure, some sites will have many machines serving one web address (I doubt Microsoft serves the world on one NT server at www.microsoft.com) but this is often handled using DNS and I doubt Q has more one host out there that s/he is connecting to.
| Therefore, if I instruct IE 3.02, by default,
| to access a lead address,
What is a lead address?
| it will read through the available chain for that group
Chain? Group? I have never heard of these terms used in IP networking. Is this something new? Is this some new secret voodoo science using a mystical magical networking protocol that was transmitted to earth on a scroll from the planet Beexelborp?
Q ought to dump the Windows 95 stack and use one like WRQ's Reflection stack, which supports multihoming, and has technical support which does not cost a million bucks a minute.
| Beyond this, you must use the MS PPTP protocol efficiently.
Why use PPTP? That's for VPNs. For providing a secure tunnel through the Internet to a VPN gateway machine on the border of a secure corporate network. Q said s/he was not using PPTP.
| As an example, most addresses are multiples,
| such as this site and can be accessed either randomly
| or with an address range preassigned.
Did I miss something in Networking 101? I thought that each host had a single IP address (except for some hosts which are multihomed.) Sure, some sites will have many machines serving one web address (I doubt Microsoft serves the world on one NT server at www.microsoft.com) but this is often handled using DNS and I doubt Q has more one host out there that s/he is connecting to.
| Therefore, if I instruct IE 3.02, by default,
| to access a lead address,
What is a lead address?
| it will read through the available chain for that group
Chain? Group? I have never heard of these terms used in IP networking. Is this something new? Is this some new secret voodoo science using a mystical magical networking protocol that was transmitted to earth on a scroll from the planet Beexelborp?
Q ought to dump the Windows 95 stack and use one like WRQ's Reflection stack, which supports multihoming, and has technical support which does not cost a million bucks a minute.
ASKER
I've decided that it is time to close out this question. I appreciate Dew's knowledge of the application layer; however, y96andha's in-depth knowledge of Windows Sockets has shed more light on a possible solution. His suggestion that I bind to the interface address of the DUN connection instead of INADDR_ANY, and making the proper routing table entries, is the key to getting this work on Windows 95, if it is to work at all. Furthermore, his tests indicated that it works on NT, as indicated by seeing network activity during the tests. Thank you all for participating, I wish I could assign points to everyone. y96andha, please post an answer to get your points.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks, y96andha. I decided to close this because it was quickly degenerating into a flame session.
I appreciate your help, your knowledge, and especially your patience through all my questions. The signs of a great consultant. Enjoy the points!
I appreciate your help, your knowledge, and especially your patience through all my questions. The signs of a great consultant. Enjoy the points!
ASKER
Status report: I have not gotten far enough in my project to test this solution. However, RFC1122 states that stacks should respect an application's choice of interfaces. The app chooses the interface by binding explicitly to its IP address, rather than letting the stack provide the interface address. This is referenced in the RFC in the sections under TCP and UDP Multihoming.
Additionally, there is a flag used with the winsock Send and SendTo calls, called "MSG_DONTROUTE". The literature is very weak in this area, but this option tells the stack not to use its routing mechanism to route a packet. If RFC1122 were adhered to, one would not need this flag?? However, adherence to RFC1122 can cause a problem if default routes change, and the interface a socket is using goes down - presumably, a smart stack could reroute the packets to the proper interface using the routing table. Perhaps that's what many stacks do, and DONTROUTE is there to force them to use the specified interface. Who knows, except the guys who had these discussions during the Winsock spec development. My source on RFC1122 was pretty close to these developments, and he didn't know. Perhaps I should just write to Stardust Labs, who have been very involved in the development of the Winsock specifications.
Additionally, there is a flag used with the winsock Send and SendTo calls, called "MSG_DONTROUTE". The literature is very weak in this area, but this option tells the stack not to use its routing mechanism to route a packet. If RFC1122 were adhered to, one would not need this flag?? However, adherence to RFC1122 can cause a problem if default routes change, and the interface a socket is using goes down - presumably, a smart stack could reroute the packets to the proper interface using the routing table. Perhaps that's what many stacks do, and DONTROUTE is there to force them to use the specified interface. Who knows, except the guys who had these discussions during the Winsock spec development. My source on RFC1122 was pretty close to these developments, and he didn't know. Perhaps I should just write to Stardust Labs, who have been very involved in the development of the Winsock specifications.