3
votes

Legacy product's VB6 WinSock Tcp clients simply "miss" half of the message sent to them.

I'm going to be working on a server project where an old legacy application written in VB6 will be required to connect to the C# TCP server.

TCP client/server programming has always been easy when both endpoints are .NET thanks to System.Net.TcpClient. However it looks like the VB6 group will be stuck with VB6 WinSock control (is this as bad as I heard it is?).

Are there any caveats or tips leading into this so that any avoidable landmines or obstacles can be taken care of?

A current implementation has a server (c#.net) that sends messages in the following way:

private bool SendToStream(NetworkStream clientStream, string message)
      {
         try
         {
            message = Crypto.Encrypt(message);
            message = message + "\r\n";
            byte[] buffer = System.Text.Encoding.ASCII.GetBytes(message.ToCharArray());
            if (clientStream != null)
            {
               StreamWriter blah = new StreamWriter("lastsent_a.txt");
               blah.WriteLine("[some clientStream]" + Environment.NewLine + Environment.NewLine + message + Environment.NewLine + Environment.NewLine + Crypto.Decrypt(message));
               blah.Close();

               clientStream.Write(buffer, 0, buffer.Length);
               clientStream.Flush();
               return true;
            }
            return false;
         }
         catch (Exception e)
         {
            ProcessDebugLog("ERROR - SendToStream: " + e.Message.ToString());
            return false;
         }
      }

Where clientStream is the NetworkStream associated with the TcpClient that was built from a TcpListener.

The client receives messages in the following way (VB6 WinSock style):

Private Sub wskConnect_DataArrival(ByVal bytesTotal As Long)
   Dim sBuff As String
   wskConnect.GetData sBuff, vbString       '-- Retrieve sent value
   ProcessMessage sBuff                     '-- Process the value
End Sub

EDIT: When I want to debug Tcp clients in C# I use a TcpListener's NetworkStream and do .Receive synchronously. Clearly this hogs the processor, but it let's me get every single byte coming down the line, instead of having to just trust that an async socket event will fire. Would switching the VB6 code to do this synchronously and remove that blind trust in an event firing be a good place to start?

2
I always liked doing winsock in vb6. The only thing I can think of is data structures. I would suggest making sure you're using a common binary format or maybe XML.Dustin Davis
What is the problem/question exactly? You may want to look at the TCP/IP COM objects from Catalyst instead of the MS Winsock one, it exposes more functionality. (Depends on your needs). Also FYI, calling Flush on a network stream doesn't do anything.tcarvin
The problem is that the VB6 Tcp client simply misses half its incoming messages. None of my .NET clients do that.user1110648
Is that pseudo / sample VB6 code or the real VB6 code in the DataArrival handler? What does ProcessMessage do?tcarvin
@tcarvin Yeah that's copy/paste code. Process message takes the string that is sBuff and parses it and takes further action based upon what the message was. ProcessMessage only gets hit after a message has come in.user1110648

2 Answers

4
votes

TCP is TCP and more specifically even the .NET TcpClient class is built on the same socket infrastructure as VB6 WinSock. The communication should be straight forward, but as DustinDavis commented, beware of short comings of using VB6 (such as data structures and binary formatting).

EDIT: Given your update, ensure that you only read bytesTotal from the socket in the VB6 client because otherwise you can end up grabbing part of all of the next packet (or only part of the current packet). This is a problem because the DataArrival Event only triggers when new data is available to read. This is especially prominent in high traffic systems.

0
votes

When I was younger and had to do VB3 and VB6 development we always used to use IP*Works!

The license fee was well worth the immense reduction in hassle getting classic VB to play nice with networking.

Disclosure : I do not work for the manufacturer or have any association with them. I am merely a satisfied previous user of the product.