Data truncation when using Winsock GetData?

[Imanta]

I am using Winsock GetData and it appears that the data being returned is getting truncated. The data is a string and it will appear truncated in the middle of a word or sentence. It seems very simple:

Dim strData As String
wSockUDP.GetData strData, vbString

Any ideas??

Thanks.

[señorbadger]

i dont know if this will help but i just use

Dim strData As String
wSockUDP.GetData strData

[Imanta]

It doesn't seem to make a difference. Is there a certain length that a string can be in general? I can't imagine I am hitting it, but it would explain it. Is there another data type that can be used?

Thanks.

[señorbadger]

variants, i dont like to use them but worth a try ??

eg

Dim strData As variant
wSockUDP.GetData strData

[leinad31]

If the data is large, yes it will be chopped up into multiple sends, hence multiple data arrivals, hence your problem.

At the data arrival side, concatenate getdata for the data arrivals until the entire length has been downloaded. To determine if you've received the entire length; send additional header info (total data length in bytes) at the start of send or send special string on send complete or some other implementation.

[Imanta]

Whoa, that like blew over my head...

Basically I do a SendData and then GetData the response over UDP. I have no idea the length of the response from the server and I will not necessarily know if it is chopped off until I am done processing it.

I am new to Winsock and if there is anyway you could give me a sample of what you are talkling about that would be appreciated.

Thanks for your help.

[ccoder]

I have to agree with leinad31.

At my company, we use a 52 byte header on all of our records that are sent via socket connections. I use the header in all of my C, VB and Java sockets apps.

Among other things, the header contains a long whose value is the sum of the header length and record length. One of my VB apps gets a record from a C server on another platform that is over 18,500 bytes long. As I recall, when I debugging my code, the record came back in blocks of 1460 bytes followed by one smaller block and I had to append the blocks until I had received everything.

Here is the DataArrival routine from that app. Hopefully, it will give you some idea of what we are saying.

Private Sub tcpClient_DataArrival(ByVal bytesTotal As Long)
   ' determine the data type and process it
   
   ' get the buffer contents
   ReDim gbIOBuff(bytesTotal)
   tcpClient.GetData gbIOBuff, vbArray + vbByte, bytesTotal
   
   If copyPtr = 0 Then ' we are at the beginning of a new reply
      ' save size & type of reply
      CopyMemory recLen, gbIOBuff(0), 4     ' get the record length
      recLen = ntohl(recLen)                ' convert to little-endian
      CopyMemory codeCheck, gbIOBuff(52), 2 ' get the reply type
      codeCheck = ntohs(codeCheck)          ' conver to little-endian
      ReDim gbReplyBuff(bytesTotal)         ' clear old data record & start new one
   Else
      ReDim Preserve gbReplyBuff(copyPtr + bytesTotal) ' retain data & bump the size
   End If
      
   ' copy the received data to the work buffer at location referenced by copyptr
   CopyMemory gbReplyBuff(copyPtr), gbIOBuff(0), bytesTotal
   If UBound(gbReplyBuff) = recLen Then
      ' we got the entire file
      If recLen = gilocLen Or recLen = gijobLen Or recLen = giSockRtn Then
         If codeCheck = glLocRequest Then
            Process_Locations        ' called 1 time only at Form_Load
         Else
            If codeCheck = glJobRequest Then
               Process_JobStats      ' called for each chart request
            Else
               Beep
               sbStatus.Panels(2).Text = "Error: " & codeCheck & ", No data returned"
               intTics = 0 ' reset display timer
            End If
         End If
      End If
      copyPtr = 0   ' reset the flag\pointer
   Else
      ' save the current record length\next copy location
      copyPtr = UBound(gbReplyBuff)
   End If
      
End Sub

[Shaggy Hiker]

UDP will chop packets up, but the size of the packet is determined by the network (sort of). Therefore, don't rely on any particular packet size. Sizes can get down to below 512 Bytes, which really isn't much.

Furthermore, UDP doesn't guarantee that any particular packet makes it. Therefore, if you suspect that the data is going to exceed the packet size, you will need to have some mechanism to be sure that you can know whether you have all the data, and a means to re-submit for the missing data.

A header that tells you the total number of bytes helps, since you can determine whether or not you got the whole thing, but it doesn't tell you much about what was lost if something goes away. Solving that isn't all that easy, since you may not know how big the packet size will be. For that reason, UDP is generally used for REALLY small packet situations.

One possibility for larger packets would be to chop each message into very small pieces, number each piece, and send them. The header would include the number of pieces. There fore, the receiveing end can determine which piece is missing (by the number), the number of total packets, and the order of the packets.

[leinad31]

If your concerned about chunks not reaching the destination then use TCP sockets instead.

[Wokawidget]

Here's a nice DLL, source code, that replaces the winsock control.
This uses 2 classes...the cSocket class, that is a direct replacement for the winsock control, and my own class, Socket, which is a wrapper class for the cSocket class.
This wrapper class deals with large amounts of data, and removes the hassel of joining packets together.

There is a very basic small client server test app in the zip file also.

Hope this is of use...

If you have any questions then give me a shout.

Woka

[Imanta]

Was there a file with this? Did I miss a link? Thanks for the help!

[Wokawidget]

I am a fool

Here you go.

Woka