0

I'm taking a class in the college that require me to create a server-client application, i came up with this code but apparently it has some strange error when I remove the "\n" at the end of the printf(). I already checked with my teacher and it was him who found out that this is was causing my server to freeze and display latter when we send the message, so he put \n in the end of each print(in the beggining there wasn't). We spend a couple of hours trying to find a reason but we didn't find anything to explain, so i'm reaching for you guys(so as my teacher who is curious about), i don't know if we let something pass by.

To create the error that i'm talking about, simply remove \n from each printf and run the code, he'll run but not work properly (even though the port seems to be listen in the telnet command) the lines who was supposed to appear will not show.

#include <strings.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <stdio.h>
#include <arpa/inet.h>

int main()
{
    //criar socket -> bind -> listen -> connection
    int socket_name = 0, new_conn = 0;
    struct sockaddr_in serv_addr;
    char msg_recv[20];

    char sendBuff[1025];

    socket_name = socket(AF_INET, SOCK_STREAM, 0);
    if(socket_name < 0)
    {
        printf("%s","Failed to create socket, exiting\n");
    }else{

        printf("%s", "Success\n");

    }

    bzero(&serv_addr, sizeof(serv_addr));
    serv_addr.sin_family = AF_INET;
    serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
    serv_addr.sin_port = htons(5000);
    bind(socket_name, (struct sockaddr*)&serv_addr, sizeof(serv_addr));

    listen(socket_name, 10);

    while (1)
    {   
        new_conn = accept(socket_name, (struct sockaddr*)NULL, NULL);
        read(new_conn, &msg_recv, sizeof(msg_recv));
        printf("New: %s\n", msg_recv);
        close(new_conn);
     }   

    return 0;
}

I am testing with nc command, sending a message there, without a client implementation.

Gabriel Domene
  • 63
  • 8
  • 1
    Except for the call to `socket` you don't check for errors. You need to do that for all calls that can fail (like e.g. `bind`, `accept` and `read`). Furthermore, do the client send the string terminator character? Perhaps you need to add it? – Some programmer dude Sep 18 '18 at 12:48
  • 1
    On an unrelated note, the `read` function expects the second argument to be a pointer to the first element of the array, not a pointer to the actual array. Either use `&msg_recv[0]`, or plain `msg_recv` as it will decay to `&msg_recv[0]`. And while both `&msg_recv` and `&msg_recv[0]` points to the same location (lucky you!) they are semantically different as they are of different type. `&msg_recv` is of type `char (*)[20]` while `&msg_recv[0]` is of type `char *`. – Some programmer dude Sep 18 '18 at 12:54
  • @Someprogrammerdude thanks for the clarification in the other calls and the pointer i'll fix that! And no, the client just send the message without the terminator character. @ John3136 well, it seems to be the answer, i might run some test later, sorry if it was a duplicate (english is not my main language, so find synonyms is not that easy), and we're all passive of errors, thanks! – Gabriel Domene Sep 18 '18 at 13:14
  • The usual three suspects: failure to correctly and completely handle the results from system calls like read(). Failure to correctly manage the octet/byte streaming nature of TCP. Failure to ensure that char arrays passed to library calls that require a NUL terminator are guaranteed NUL-terminated. – Martin James Sep 18 '18 at 15:59

1 Answers1

1

I'm pretty sure you guys aren't experiencing any errors, the adding of \n does nothing more than flush your printing buffer and make it, in fact, a visible indication within your stdout or a terminal for this matter.

DrPrItay
  • 726
  • 5
  • 18
  • Thanks for the tip, reading along with the link provided before, i think this might be the answer, currently i'm not in PC so later i'll test and if it's right, i'll leave as the right one, thanks! – Gabriel Domene Sep 18 '18 at 13:17