how to open sockets on multiple network adapters..??

[hussain_kiet]

Hi

I have two different network adapters on my PC
1- 3G EVDO USB DEVICE
2- USB WIFI STICK (TP-LINK)
both adapters have internet connection.

Note: this is for client side application

when i open a socket on one adapter when the other is disconnected both of them works fine.
but when both are connected and i open sockets on both of them only the 3G EVDO device socket works.
I have binded both the sockets to their respective adapters local IP. and both of them are connecting to the same remote ip (where server application is running) but on different ports.

please tell me that is there any way that both the sockets can work simultaneously..??
please help me..


Thanks and regards
Hussain Aftab

[hoxsiew]

Binding each socket to its respective adapters should be sufficient. You say one doesn't work. What doesn't work? connect? send/recv? Are there any errors returned and what are their codes?

What does your bind code look like?

[MikeAThon]

Binding each socket to its respective adapters should be sufficient.

I tend to disagree with this, at least with respect to outgoing (i.e., client) connections. For a multi-homed system (i.e., a system with multiple network cards) with a Windows OS, and with respect to outgoing connections, a call to bind() will have no effect on the choice of which card will be used to establish the connection. Rather, the choice of card will be made by the OS using the routing table. The OS will make its decision by comparing the routing table to the destination IP, to choose the card that seems most appropriate for the destination.

See this blog for an example on how to create an entry in the routing table. It's written for WinCE but the principles are similar: "Routing IP traffic via specified adapter" at
http://ce4all.blogspot.com/2007/05/r...specified.html

OTOH, for accepting incoming connections (i.e., via listen() and accept()), a call to bind() works as expected.

Mike

[hoxsiew]

Yes, I see. I was incomplete in my description. The bind must use the adapter address:

    struct sockaddr_in my_addr;

    my_addr.sin_family=AF_INET;
    my_addr.sin_port=0;
    my_addr.sin_addr.s_addr=inet_addr("192.168.1.100");
    bind(sock,(struct sockaddr *)&my_addr,sizeof(my_addr));
    //connect, send,recv,etc.

[MikeAThon]

Yes, I see. I was incomplete in my description. The bind must use the adapter address:

Even with the address of the adapter, my point was that for an outgoing connection, the call to bind() is ignored and will not effectuate a selection of the specified adapter. In Windows, it's the OS that chooses the adapter for outgoing connections, and it does so at the time of the call to connect(), based on a comparison of the IP address of the destination to the information in the routing table.

The address of the destination does not come into play until the call to connect(), such that any prior call to bind() is effectively ignored for outgoing connections on a multihomed system.

[hoxsiew]

I must be having a senior moment or something. I'm confusing bind/listen/accept on the server server side of things. Please ignore anything I've said so far.

[hussain_kiet]

I agree with MikeAThon.
It seems that binding a socket to a network adapters ip doesn't do the trick. because if you see the routing table of windows it shows the Default gateway to the EVDO device and therefore all the packets are being routed towards that adapter..
we need to change the default gateway or something in the routing table as the article on the given link said.
http://ce4all.blogspot.com/2007/05/r...specified.html
but i didn't understand how to use those functions and what i have to include in my code to get access to those functions.?

[MikeAThon]

Before trying to accomplish this programmatically, you might want to confirm that it works if you add an entry to the routing table manually.

See the "Route Add" function: "Route" at http://www.microsoft.com/resources/d....mspx?mfr=true

Add the entry manually, and then see if your program works as expected, i.e., confirm that one card is selected for one destination IP address, and the other card is selected for a second destination IP address.