Not receiving everything

Im making a small set of socket classes and i was testing a piece of code to see if ReadLine() works. Here's the code that works:

Code:

    TcpSocket sock;

    if(sock.Connect(IpAddress::ResolveHost("www.google.com.au"), 80))
    {
        char recvBuff[4096];
        sock.Write("GET / HTTP/1.1\n");
        sock.Write("Host: www.google.com.au\n");
        sock.Write("Connection: close\n");
        sock.Write("\n");

        while(sock.ReadLine(recvBuff, sizeof(recvBuff)))
            printf("Line: %s\n", recvBuff);
    }
    return 1;

I figured it should also work if i change the size of "recvBuff" to 10, but it only receives part of the header (instead of both header and data) before the programs finishes. The output is this:

Code:

Line: HTTP/1.1
Line: 200 OK
Line: Cache-Con
Line: trol: pri
Line: vate, max
Line: -age=0
Line: Date: Wed
Line: , 11 Jun
Line: 2008 04:1
Line: 6:06 GMT

The read line code that i wrote is this:

Code:

bool soxTcpReadLine(unsigned int socketId, char* out, size_t outLen)
{
    size_t recvCount = 0;
    while(recvCount < outLen - 1)
    {
        char byte;

        if(recv(socketId, &byte, 1, 0) > 0)
        {
            if(byte != '\n')
                out[recvCount++] = byte;
            else break;
        } else break;
    }

    if(recvCount)
    {
        //Trim line
        while(recvCount)
        {
            if(out[recvCount - 1] < ' ')
                out[--recvCount] = 0;
            else break;
        }

        //Null terminate
        out[recvCount] = 0;
        return true;
    }
    return false;
}

Do you have a non-blocking socket?

In which case, recv() can return an error, and the error code will be something like EAGAIN, which means there's nothing right now, come back later.

Nope, it's blocking.

you need to be check the return value of recv. if it does return an error, the data is basically useless to your program *anyway* - it would probably be a good idea to throw an exception at that point (possibly unpacking errno into some user-friendly message as well). another thing I noticed is that you treating '\n' as your eol. remember that HTTP uses '\r\n' to delineate lines. also, single-transfer connections are typically shutdown after reading/writing the entire message. finally, reading a single byte from a TCP connection is horribly inefficient. I would recommend reading the entire message into a buffer before parsing each line out.

Originally Posted by Sebastiani

you need to be check the return value of recv. if it does return an error, the data is basically useless to your program *anyway* - it would probably be a good idea to throw an exception at that point (possibly unpacking errno into some user-friendly message as well). another thing I noticed is that you treating '\n' as your eol. remember that HTTP uses '\r\n' to delineate lines. also, single-transfer connections are typically shutdown after reading/writing the entire message. finally, reading a single byte from a TCP connection is horribly inefficient. I would recommend reading the entire message into a buffer before parsing each line out.

Well the read line should support headers that use "\r\n" and "\n" as it trims the end of the string (removing any "\r"s).
How inefficient is it to read one byte at a time? Would it be better to peek the data, find the end of the line, then receive? I would like to know how other api's handle read line.

Code:

sock.Write("GET / HTTP/1.1\r\n");

(Same for the rest of the newlines... capture some live HTTP traffic, and examine it.)

How inefficient is it to read one byte at a time?

When some poster at another forum noted larger throughput with bigger calls to recv(), and asked why:

Originally Posted by Brian

Why is it faster to drink a liter of water a cupful at a time than to drink it out of an eyedropper?

Read and write as much as you can.

I would like to know how other api's handle read line.

Originally Posted by Sebastiani

I would recommend reading the entire message into a buffer before parsing each line out.

That's how I'd do it.