recv in loop

[LMZ]

i think that learn winsock is most useful for me,
because i can port than more simply my programs in bsd (i think :))

but i'll will read about http windows functions, thx

[QvasiModo]

I don't understand what you mean, ..but, if there is alternative method for checking size of data waiting to be read from socket, i would appreciate hearing about it.
I know of SELECT() but, what is the alternative you reccomend??

I'm afraid there is no method at all... not a 100% reliable one that is. The application at the other endpoint of the TCP connection has to tell you how many bytes to expect. You should be able to handle the cases when it's sent too much or too little.

surely the operating systems tcp/ip driver would take care of how packets are buffered, not the API itself.

I know, but that's not what I mean. It's just that you might not get the whole reply from the web server in a single recv() call, and  ioctlsocket will only tell you how much you can read in the next call (not how much has the server truly sent).

I already acknowledged this fact in first post, and also mentioned that it is in unusual circumstances that such a server would behave this way.

I was only pointing out that the only validation worth making with ioctlsocket is to allocate a read buffer, not to replace the Content-Length header altogether.

And you're absolutely right that it would be unusual, tipically you get the whole thing in just one recv() call. I'm being picky that's all. :)

[P1]

I'm being picky that's all. :)

I would not call that 'picky'.  Your just trying to get him to realize the consequences of the circumstances he is expect to program to. 

Then there is the hackers who send crafted headers to crash your software.

Welcome to Internet Programming Realities 101 !!!   :dance:

Regards,  P1  :8)

[James Ladd]

You could also check out FASt Server here: www.jamesladdcode.com
It uses overlapped socket IO which is very fast indeed.
rgs, James (striker).

[bozo]

I'm afraid there is no method at all... not a 100% reliable one that is. The application at the other endpoint of the TCP connection has to tell you how many bytes to expect. You should be able to handle the cases when it's sent too much or too little.

I don't mean to offend you, but this is a nonsensical statement.
Unless a server were processing RAW packets, ioctlsocket() should not "miss" anything at all, as it is the underlying TCP/IP driver which buffers the "unread" data from the socket..

Do you mean, processing RAW packets? that there is no reliable way?
Fair enough, I don't know.

Using ioctlsocket with FIONREAD simply peeks at the socket buffer, to see if anything is there, and returns the size of the buffer (if anything, else return zero), thats my understanding of it.

I'm not that experienced with TCP/IP, but what you say just doesn't make any sense.
And you say there is not 100% reliable way..

To me, that would mean TCP/IP is broken and unreliable, which you and I know is not 100% accurate.

As TCP/IP stack of Windows 2000 and upwards is based on FreeBSD code, I would say its pretty reliable.

[QvasiModo]

We're talking of two different things. I seem to be having a problem to express myself this days, my apologies. :(

I didn't mean to use raw packets at all. I never meant to say TCP was unreliable. I don't imply that ioctlsocket fails to reckong how many bytes there are in the buffer. You are absolutely right.

What I mean that there is no way to know in advance how many bytes will the whole stream take. You can only know how many are ready to be obtained in the next recv() call. That's why you need to use the Content-Length header when processing HTTP streams, you can't expect to know the size of the whole stream, just how much has been buffered already by the TCP/IP stack. HTTP clients and servers can't be reliably implemented if they ignore the Content-Length header.

Hope I've made myself clear this time, I don't want to confuse LMZ  :toothy

PS: Whenever you see I stop making sense, don't hesitate to tell me so. I won't get offended for being corrected. :wink