tags:

views:

34

answers:

3

I'm using the VB6 Winsock control. When I do a POST to a server I get back the response as multiple Data arrival events.

How do you know when all the data has arrived?

(I'm guessing it's when the Winsock_Close event fires)

+1  A: 

I have used VB6 Winsock controls in the past, and what I did was format my messages in a certain way to know when all the data has arrived.

Example: Each message starts with a "[" and ends with a "]".

"[Message Text]"

When data comes in from the DataArrival event check for the end of the message "]". If it is there you received at least one whole message, and possibly the start of a new one. If more of the message is waiting, store your message data in a form level variable and append to it when the DataArrival event fires the next time.

dretzlaff17
A: 

No, the Close event doesn't fire when all the data has arrived, it fires when you close the connection. It's not the Winsock control's job to know when all the data has been transmitted, it's yours. As part of your client/server communication protocol implementation, you have to tell the client what to expect.

Suppose your client wants the contents of a file from the server. The client doesn't know how much data is in the file. The exchange might go something like this:

  • client sends request for the data in the file
  • the server reads the file, determines the size, attaches the size to the beginning of the data (let's say it uses 4 bytes) that tells the client how much data to expect, and starts sending it
  • your client code knows to strip the first 4 bytes off any data that arrives after a file request and store it as the amount of data that is to follow, then accumulate the subsequent data, through any number of DataArrival events, until it has that amount

Ideally, the server would append a checksum to the data as well, and you'll have to implement some sort of timeout mechanism, figure out what to do if you don't get the expected amount of data, etc.

raven
+1  A: 

In HTTP, you have to parse and analyze the reply data that the server is sending back to you in order to know how to read it all.

First, the server sends back a list of CRLF-delimited header lines, which are terminated by a blank CRLF-delimited line by itself. You then have to look at the actual values of the 'Content-Length' and 'Transfer-Encoding' headers to know how to read the remaining data.

If there is no 'Transfer-Encoding' header, or if it does not contain a 'chunked' item in it, then the 'Content-Length' header specifies how many remaining bytes to read. But if the 'Transfer-Encoding' header contains a 'chunked' item, then you have to read and parse the remaining data in chunks, one at a time, in order to know when the data ends (each chunk reports its own size, and the last chunk reports a size of 0).

And no, you cannot rely on the connection being closed after the reply has been sent, unless the 'Connection' header explicitally says 'close'. For HTTP 1.1, that header is usually set to 'keep-alive' instead, which means the socket is left open so the client can send more requests on the same socket.

Read RFC 2616 for more details.

Remy Lebeau - TeamB