Unix Networking Programming - Client and Server. List Function That wait for input after 40 lines

I am currently in the process of making a Client and Server in the Unix/Windows environment but right now I am just working on the Unix side of it. One of the function we have to create for the program is similar to the list function in Unix 开发者_运维技巧which shows all files within a dir but we also have to show more information about the file such as its owner and creation date. Right now I am able to get all this information and print it to the client however we have to also add that once the program has printing 40 lines it waits for the client to push any key before it continues to print.

I have gotta the program to sort of do this but it will cause my client and server to become out of sync or at least the std out to become out of sync. This means that if i enter the command 'asdad' it should print invalid command but it won't print that message until i enter another command. I have added my list functions code below. I am open to suggestions how how to complete this requirement as the method I have chosen does not seem to be working out.

Thank-you in advance.

Server - Fork Function: This is called when the list command is enter. eg

fork_request(newsockfd, "list", buf);

int fork_request(int fd, char req[], char buf[])
{

#ifndef WIN

int pid = fork();
if (pid ==-1) 
{
    printf("Failed To Fork...\n");
    return-1;
}
if (pid !=0)
{
    wait(NULL);
    return 10;
}
dup2(fd,1); //redirect standard output to the clients std output.
close(fd); //close the socket
execl(req, req, buf, NULL); //run the program
exit(1);

#else
#endif

}

Here is the function used to get all the info about a file in a dir

void longOutput(char str[])
{
    char cwd[1024];
    DIR *dip;
    struct dirent *dit;
    int total;
    char temp[100];
    struct stat FileAttrib;
    struct tm *pTm;
    int fileSize;
    int lineTotal;


if(strcmp(str, "") == 0)
{
    getcwd(cwd, sizeof(cwd));
}
else
{
    strcpy (cwd, str);
}

if (cwd != NULL)
{
    printf("\n Using Dir: %s\n", cwd);
    dip = opendir(cwd);

    if(dip != NULL)
    {
        while ((dit = readdir(dip)) != NULL)
        {
            printf("\n%s",dit->d_name);
            stat(dit->d_name, &FileAttrib);
            pTm = gmtime(&FileAttrib.st_ctime);
            fileSize = FileAttrib.st_size;
            printf("\nFile Size: %d Bytes", fileSize);
            printf("\nFile created on: %.2i/%.2i/%.2i at %.2i:%.2i:%.2i GMT \n", (pTm->tm_mon + 1), pTm->tm_mday,(pTm->tm_year % 100),pTm->tm_hour,pTm->tm_min, pTm->tm_sec);;
            lineTotal = lineTotal + 4;

            if(lineTotal == 40)
            {
                printf("40 Lines: Waiting For Input!");
                fflush(stdout);
                gets(&temp);
            }


        }
        printf("\n %d \n", lineTotal);
    }
    else
    {
        perror ("");
    }
}
}

At here is the section of the client where i check that a ! was not found in the returned message. If there is it means that there were more lines to print.

if(strchr(command,'!') != NULL)
{
    char temp[1000];
    gets(&temp);

}

Sorry for the long post but if you need anything please just ask.

---

Although, I didn't see any TCP/IP code, I once had a similar problem when I wrote a server-client chat program in C++. In my case, the problem was that I didn't clearly define how messages were structured in my application. Once, I defined how my protocol was suppose to work--it was a lot easier to debug communication problems.

Maybe you should check how your program determines if a message is complete. In TCP, packets are guaranteed to arrive in order with no data loss, etc. Much like a conversation over a telephone. The only thing you have to be careful of is that it's possible to receive a message partially when you read the buffer for the socket. The only way you know to stop reading is when you determine a message is complete. This could be as simple as two '\n' characters or "\n\r".

If you are using UDP, then that is a completely different beast all together (i.e. messages can arrive out of order and can be lost in transit, et cetera).

Also, it looks like you are sending across strings and no binary data. If this is the case, then you don't have to worry about endianess.