Socket communication on WAN/Internet
I have a Visual Basic 6 program that relies on Winsock for communication in between two computers. I have used the Winsock control for this. While the program now works fine on a LAN, I haven't tried it for clients connecting to the server on a WAN or by a dial up connection. While I've coded for the Internet connection, in case they wish to access the server through a dial-up connection, but I am not very sure of how it is supposed to work. Does the code for the Winsock control need to undergo any changes if the IP Address is not one on the LAN but on a WAN or just an Internet IP address? For those of you who have coded socket communication over the Internet with wininet.dll for the connection and the Winsock control for the communication, please advice me of anything else that needs to be done apart from the routine Winsock methods and a connection to the Internet using <i>InternetAutodial</i>and <i>InternetOpen</i>.
The problem is that I am on a LAN and have a proxy configured for the LAN, so even if I wish to test for a WAN IP, the control always picks up the LAN IP instead. I wanted to test for a dial-up which I currently do not have.
In terms of the TCP/IP stack there is no difference at all, your connection is above the transport layer (the method by which packets are sent).
Thanks, Simon. I wanted someone to confirm this. So I will have the same code no matter what the kind of network as long as I provide the Internet IP address of the server in case they are using the Internet for connectivity?
Be aware, though, that UDP packets get dropped much more often when not on the local LAN, so if you use UDP and didn't take care of that you're going to face lots of trouble.
Thanks. I am using TCP and not UDP for the very reason of distinction between the two - the commercial data in my program needs reliability more than speed and needs to make sure that the data packets all arrive in tact, and in the correct sequence. Although one quirk with TCP is that it when a data packet is corrupted enroute, it tends to send you a duplicate copy of the correct data re-assembled plus also the incomplete data that was corrupted enroute (as a bonus as if), and one has to learn to handle that carefully which I did. Spent a good four hours on the unpacketing routine and rewrote it a handful of times.
Just one more thing. What if the server has a dynamic IP address instead of a static IP?
[Although one quirk with TCP is that it when a data packet is corrupted enroute, it tends to send you a duplicate copy of the correct data re-assembled plus also the incomplete data that was corrupted enroute]
I've just had this situation recently and not just one occurence but it occured over and over again that I got broken as well as reparied data packets and that too in an order where sometimes the broken packets followed the repaired complete ones.
Well, I guess I've never used the Winsock control, but I've used the winsock libraries. The thing I don't understand is that you keep talking about packets, whereas TCP provides a stream. Anything built on top of TCP doesn't deal with packets at all. Are you sure you aren't using UDP? Or maybe HTTP and by packets you mean individual HTTP requests?
Oops! I was refering to my own message delimited by a certain rule as a packet.
Fog Creek Home