oddau
asked on
MS WinSock Control and receive-buffer...
Hi!
I'm doing a VB 5.0 app. in wich I'm using a MS WinSock Control. I send queries to an Socket server, wich in its place chew on some data, and send them in a pre-designed format back to me. This is not any problem for my Socket client as long as the record I receive is less than 8192 bytes long (8k).
However, if it is, the tcpClient.DataArrival event stops after getting this amount, and I have to put in a "DoEvents" to get the rest of the record. The problem that arrises when I do this, is that I no longer can check wich recordtype the second "shipment" of data is, as it's the second part of a record.
Could this be a problem on the server-side, or can I somehow alter the receive-buffer? (I don't use any API-calls for my TCP/IP sessions).
On the server-side there is an C-application, running on an Dec Alpha-machine, and the send-buffer seems to be set to 15000 bytes. (The largest record I have is 14828 bytes).
The guys that has implemented this says they send the whole buffer in one go, so I should be getting 14828 bytes.
Does anyone have a clue what could be wrong, and maybe a hint on how to fix it?
WR
O.E. Auran
I'm doing a VB 5.0 app. in wich I'm using a MS WinSock Control. I send queries to an Socket server, wich in its place chew on some data, and send them in a pre-designed format back to me. This is not any problem for my Socket client as long as the record I receive is less than 8192 bytes long (8k).
However, if it is, the tcpClient.DataArrival event stops after getting this amount, and I have to put in a "DoEvents" to get the rest of the record. The problem that arrises when I do this, is that I no longer can check wich recordtype the second "shipment" of data is, as it's the second part of a record.
Could this be a problem on the server-side, or can I somehow alter the receive-buffer? (I don't use any API-calls for my TCP/IP sessions).
On the server-side there is an C-application, running on an Dec Alpha-machine, and the send-buffer seems to be set to 15000 bytes. (The largest record I have is 14828 bytes).
The guys that has implemented this says they send the whole buffer in one go, so I should be getting 14828 bytes.
Does anyone have a clue what could be wrong, and maybe a hint on how to fix it?
WR
O.E. Auran
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
the method I provided works fine. No matter how correct an answer is, Mrmick always has a problem with it. Are we that point hungry? I think so.
ASKER
Hi, and thanks for the answer!
As it turned out, I didn't have to use this solution after all. I just do a "While less than 14828 bytes received Then DoEvents", and disable further send(data) until the condition is true.
Anyway, the efforts made are appreciated, and should there be any problems with my solution, I'll switch to AnthonyC's, or MrMick's.
Points go to AnthonyC for his quick response this time.
WR
Odd-Egil
As it turned out, I didn't have to use this solution after all. I just do a "While less than 14828 bytes received Then DoEvents", and disable further send(data) until the condition is true.
Anyway, the efforts made are appreciated, and should there be any problems with my solution, I'll switch to AnthonyC's, or MrMick's.
Points go to AnthonyC for his quick response this time.
WR
Odd-Egil
oddau, the problem is that regardless of how large or small a block of data is, it is sent in packets that have a limited size. The data is reconstructed, buffered and passed to your client app in chunks of varying sizes (whatever size the winsock control chooses - can be as small as a few bytes).
The method I use to receive blocks is to begin each transfer with a info header (which you're already doing - contains the recordtype) and include in the header a long integer which specifies how many total bytes make up the transfer. This will provide you with a means of separating the current transfer with subsequent transfers, you won’t have to search for a "marker" and it is independent of the data being sent meaning that this method would work for any combination of bytes.
If you would like a code example exploiting this method, I’ll be happy to give you one. Just send me a note and I’ll reply: mick@owen.wa.com