Fog Creek Software
Discussion Board




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>.

Sathyaish Chakravarthy
Wednesday, September 10, 2003

*lol*

The easiest way to answer your question is to TRY!

You obviously have an internet connection, or you wouldn't be able to post in this forum.

HeWhoMustBeConfused
Wednesday, September 10, 2003

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.

Sathyaish Chakravarthy
Wednesday, September 10, 2003

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).

In other words, if you have a network, regardless of what that network is composed of, and that network uses TCP/IP anything using Winsock or any other TCP/IP stack will work.

Simon Lucy
Thursday, September 11, 2003

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?

Sathyaish Chakravarthy
Thursday, September 11, 2003

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.

And in your testing, check what happens when you disconnect either machine from the ethernet jack. A similar situation is more common on a WAN, and your software should be prepared to handle that.

Ori Berger
Thursday, September 11, 2003

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.

Also, as you mentioned about a connection breaking in between, I've taken care to handle that very early in my development. I knew the peculiarity of winsock errors and the dearth of documentation on them ever since I began my first winsock project 2.5 years back. So before this project, I was once bitten was careful enough to sit through layer upon layer of MSKB on Winsock oddities and provide error handling for all the conditions they mentioned - Address In Use, Connection Timed Out, Bad Connection State, Non-Blocking Socket, Connection Terminated, Data abandoned, data not sent completely etc.

Thanks for spending your time on my concern and for your valuable help.

Sathyaish Chakravarthy
Thursday, September 11, 2003

Just one more thing. What if the server has a dynamic IP address instead of a static IP?

Sathyaish Chakravarthy
Thursday, September 11, 2003

[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]

Uh, no it doesn't.  TCP provides a reliable data stream, with everything in the order it was sent.  Always.

Ken
Thursday, September 11, 2003

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.

I did not expect that as I'd read about TCP being reliable in packaging and routing data correctly. May be the Berkley Standard Document on Windows Sockets defines that the default behaviour of any implementation of Winsock must, if built on TCP, carry only reliable data once but I just realized that the MS Winsock Control 6.0 is not so obedient.

Sathyaish Chakravarthy
Thursday, September 11, 2003

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?

Ken
Thursday, September 11, 2003

Oops! I was refering to my own message delimited by a certain rule as a packet.

Sathyaish Chakravarthy
Thursday, September 11, 2003

*  Recent Topics

*  Fog Creek Home