A stream, such as TCP, will either hand you data (return >0), tell you
it has none (return -1 and an error of 'would block', timeout or some
kind of real error), or that the stream has been shutdown/closed
(return 0).
If you are receiving from a stream source, you must either know how
much to expect and read that much, read until you see some kind of end
token or indication, or read until the stream is shutdown/closed by
the source.
An HTTP stream will have the length in the header portion. Read until
you have satisfied the length. Depending on the HTTP session type, the
HTTP source will either shutdown/close the socket at the end of the
stream, or wait for you to shutdown/close the socket.
On 9/8/06, Luciano A. Stertz <[EMAIL PROTECTED]> wrote:
Doesn't the HTTP header itself reports the size of the data
contained in the package? In the specific case of HTTP, I would check that.
Luciano
Dmitry Grinberg wrote:
> TCP is a STREAM protocol => there is no END of data, it is one
> continuous stream. To see the end of http packer it seems reasonable
> to call it with a small timout and assume end when you get a timeout.
>
> On 9/7/06, Palm <[EMAIL PROTECTED]> wrote:
>> I am trying to receive an HTTP response from a web server using
>> NetLibReceive and am trying to figure out how to tell when and if all
>> of the
>> data has been received.
>>
>> My understanding is that you should repeatedly call NetLibReceive,
>> passing
>> it a buffer and retrieving the received data from that buffer as
>> NetLibReceive returns the number of bytes received into the buffer.
>> When no
>> more bytes are received, NetLibReceive should return 0, however that
>> is not
>> what I am seeing. I have yet to get a 0 result, and instead always
>> get a -1
>> and timeout error signaled after having to wait for the timeout.
>>
>> For example: if the "number of bytes read" returned by the last call to
>> NetLibReceive is less than the buffer size, how can you know for sure
>> that
>> the sender is not still sending data. I.e. ideally you should make
>> one more
>> call to NetLibReceive and expect to get a 0 back if the sender is done.
>> However, doing this causes a full timeout delay and only raises a
>> timeout
>> error, which makes you have to guess whether this is a real timeout
>> and the
>> sender wasn't able to complete the transfer OR that the sender was
>> indeed
>> finished and shut down the connection.
>>
>> How is this typically handled?
>>
>>
>>
>>
>>
>>
>> --
>> For information on using the PalmSource Developer Forums, or to
>> unsubscribe, please see http://www.palmos.com/dev/support/forums/
>>
>
>
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
--
yisdersomenimororsisasisdenderisorsis?
Jeff Loucks
--
For information on using the PalmSource Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/
