is there a maximum size for a packet i send thru Winsock in VB 6 ?#im stucK! pls help

[prophecy]

hi
i just wanted to knw is there a maximum size for a packet i send thru Winsock in VB 6 ? coz im tryin to send a txt file thru a winsock connection but the problem is it does not send the whole file. Only nearly half of it is sent while a part of it is not sent...

wat ive done is on server the txt file is loaded in txtbox(Multiline) and then it the textbox contents are sent to client.

and on client i have a txtbox where u put the data recieved but it does not work. A part of the data does not arrive. Its not a huge file but a small txt file

pls help!

[CVMichael]

Winsock sends the data in packets, it could be anywhere from 1K to ~8K.

When you receive the data, you will have more than one call to the DataArrival, you will have to append to the previous call.

[prophecy]

k thx so the max is 8 kb... illl try it now brb

[Pino]

But stick with packets around 3-4kb its safe that way.

Also please use the network programming section for this kind of question

[Pino]

Taken from www.winsockvb.com,

People often say to me:

"I loaded the entire 100KB file into one variable, and sent it.
Only half of it arrived. Why didn't that work?"

The answer is simple - the Winsock control messed it up. It can't seem to handle large chunks of data being fed to it, so, we (as the programmer) will have to break the data up ourselves. This means we will read and send the file in pieces of approx 2-5KB, depending on your situation (test with different chunk sizes to find optimal speed). This isn't as complex as you might think, but it involves one more VB file statement

so 2-5kb is best

[CVMichael]

You should not set a constant number on the maximum size... it could be diferent depending on many things.
That's not how you should design your program.
First send a number on how much you plan to send next (total length), then send the data
When you receive data, read the number (total length), now you know how much you will receive. Then append data to what you have until you reach the total length.

That's how you transfer data over winsock... don't depend on any maximum values !
There are sample codes in the CodeBank on this, why don't you look to see how it's properly done.

[ccoder]

FWIW, I send/receive records as large as 27KB on a regular basis. TCP/IP will break the records up into smaller packets (typically 1500 bytes) and reassemble them on the receiving end. I have never had any problems.

As CVMichael suggested, let the receiving side know how much data to expect. All of my records are preceeded by a header structure that starts with a Long containing the total byte size (header + data). My DataArrival code appends the current buffer to any previously received data until the entire record is received.

[milind_7001]

Hello CCODER,
My vb client is connected to java server, java server sends data in XML format. At my end i have to identify valid xml start and end tags only after then i send this data for processing and remove this data from original string and append next incoming data to the end of original string. But i m facing some problems while parsing the data.
Can u please show me sample code how to handle dataarrival based on packet size ( According to your post)

[ccoder]

milind_7001

I posted the DataArrival code here

[ccoder]

Things have been a bit slow right now, so I thought I would look into some of the claims that I have been reading on this forum regarding VB not being able to send very large chunks of data. Since I have been receiving large record structures from my various servers (all are written in ANSI C and running on another platform) with no problems, I thought I would see if VB can send the same structure that it has been receiving. I am posting what I have found so far, for anyone that may be interested.

I ripped some code from the app mentioned earlier in this thread and created a small C\S app with one form being the client and another being the server. The server sends the structure to the client.

This structure is defined as: (note: the comments are the equivalent C declarations)

Public Type dclStdHeader                          ' current length - 52
            ttl_len             As Long           ' long  ttl_len;
            msgtype             As Long           ' long  msgtype;
            orig_id             As Long           ' long  orig_id;
            seq_num             As Long           ' long  seq_num;
            tran_type           As Long           ' long  tran_type;
            curr_wndw           As Long           ' long  curr_wndw;
            curr_req            As Integer        ' short curr_req
            user_def(25)        As Byte           ' char  user_def[26];
       End Type
Public Type dclDevData                            ' current length - 1738
            Timeouts            As Integer        ' size_t Timeouts;
            BestMin             As Integer        ' size_t BestMin;
            WorstMin            As Integer        ' size_t WorstMin;
            BestAvg             As Integer        ' size_t BestAvg;
            WorstAvg            As Integer        ' size_t WorstAvg;
            BestMax             As Integer        ' size_t BestMax;
            WorstMax            As Integer        ' size_t WorstMax;
            BGColor             As String * 8     ' char   BGColor[8];
            SeriesIP            As String * 16    ' char   SeriesIP[16];
            SeriesData          As String * 1700  ' char   SeriesData[1700];
       End Type
Public Type dclIPCJobRep                          ' current length - 27330
            StandardHeader      As dclStdHeader   ' StdHdrDef  StdHdr;
            repID               As Integer        ' short      RepCode;
            SampleCnt           As Integer        ' short      RepSampleCnt;
            SeriesCnt           As Integer        ' short      RepSeriesCnt;
            MaxYAxis            As Integer        ' short      RepMaxYAxis;
            SampleLbls          As String * 696   ' char       RepSampleLbls[696];
            SeriesLbls          As String * 240   ' char       RepSeriesLbls[240];
            ColorSet            As String * 120   ' char       RepColorSet[120];
            GridSet             As String * 144   ' char       RepGridSet[144];
            Series(14)          As dclDevData     ' SeriesDef  RepSeries[15];
End Type

and in the app, the UDT is defined as:

Public JobIPC As dclIPCJobRep

What I found is that VB threw the error Too many local, nonstatic variables when trying to execute the line

CopyMemory gbIOBuff(0), JobIPC, girepLen

This line copies the UDT to a byte array prior to the SendData command.

Why this error is occurring is not clear to me. According to the information at MSDN I am within the 64K data segment limitation. And on the receiving end, I have no problem copying the byte array input buffer to the same type UDT. Since VB is not my primary development language, my guess is that something is happening behind the scene that I am not aware of. Anyone have any thoughts on this?

I next attempted to copy the UDT in smaller chunks. I copied the header followed by the 4 integers and 4 strings as a single chunk. Then I started copying the Series structures one at a time. During the copy of Series(3), I got the same Too many local, nonstatic variables error.

For the third attempt, I used a VarPtr to the UDT in the CopyMemory call:

   udtPtr = VarPtr(JobIPC)
   CopyMemory gbIOBuff(0), ByVal udtPtr, girepLen

This worked and the client received the expected number of bytes, however, the data was not what the client expected. It did show, however, that VB can send at least 27330 bytes in 1 send with no problems.

CopyMemory has some built in smarts, in that it will compress the 16 bit characters in the strings to 8 bits. This is ideal for my needs since my C servers work with 8 bit characters. It also greatly reduces my records, which are mostly string data fields, as you can see from the output of 2 Debug.Print statements that I put in one of the Form_Load subs.
LenB JobIPC = 54392
Len JobIPC = 27330
That is almost a 50% reduction.

The problem with using the VarPtr is that CopyMemory no longer knows that the data at the address in the VarPtr is a UDT and it copies everything. So, 2 things happened in the copy; 1) the first 27330 of the 54392 bytes were copied and, 2) the strings that were copied were not compressed.

All of the following is output of Debug.Print statements in the client's DataArrival sub. The first time the sub was called, I extracted and displayed the contents of ttl_len in the header. I then displayed the value of bytesTotal.
Record size = 27330
Bytes received = 8192

On subsequent calls to DataArrival, I again display the value of bytesTotal.
Bytes received = 8192
Bytes received = 8192
Bytes received = 2754

The sum of the 4 bytesTotal values equals 27330, the value that was in ttl_len proving that the server did in fact send the expected number of bytes in the 1 call to SendData.

Once the entire record was received, I displayed some of its contents to see what was received. The first 4 numeric values were correct, but the following strings were double-spaced because the original strings had not been compressed.
200
15
1
2
S a m p l e L b l s


That's it so far. I plan to keep working on this as time permits. If anyone out there would like to take a shot at getting this to work or at least determining why VB is throwing the error, I will gladly upload the entire project. It only comes to about 17K (uncompressed) in size.