0

This error is most likely a more general C error than it is related to the use of sockets, but here's what I have

I have code for a server and code for a client that I have been working on. The client essentially sends messages to the server and the server terminal prints whatever was being sent. For this situation, I'm not going to include the client.c file unless requested, because it is not where the issue is located.

From server.c:

while(1)
{
    if ((newsockfd=accept(sockfd, (struct sockaddr*)&cli_addr, &clilen)) < 0)
    {
        perror("accept");
        exit(0);
    }

    usleep(2000);

    printf("Server received: ");

    while (read(newsockfd, &buffer, 256) > 0)
        printf("%s", buffer);

    printf("\nServer: Message end. Waiting for next connection.\n");
}

The output I'm getting when receiving input looks like the following:

Server received: *first message from client*
*weird gibberish* *second message from client*
*weird gibberish* *third message from client*

...

Server: Message end. Waiting for next connection.

The weird gibberish varies depending on the specific server instance that is being run, but until that process ends, the gibberish is identical in each appearance.

sampleton
  • 55
  • 7
  • 4
    The data received from the socket is not NUL-terminated, `printf` expects it to be... – Kninnug Nov 16 '15 at 01:31
  • Ah I see. So what is the proper workaround for this specific situation? – sampleton Nov 16 '15 at 01:37
  • Store the result of `read` (call it `len` or somesuch) and set `buffer[len] = 0;` (provided `len < 256`). – Kninnug Nov 16 '15 at 01:41
  • Another solution would be in the client, I'm assuming you're sending a string with `strlen` as the length, if you do `strlen + 1` it should also include the null terminator in the write. – Qwerty01 Nov 16 '15 at 01:42
  • @Kninnug so do you mean something like `int len = read(newsockfd, &buffer, 256) > 0)` ? – sampleton Nov 16 '15 at 01:53
  • `int len; while((len = read(newsockfd, &buffer, 256)) > 0) {buffer[len]='\0'; printf("%s", buffer);}` For a full example see http://stackoverflow.com/questions/22077802/simple-c-example-of-doing-an-http-post-and-consuming-the-response – Jerry Jeremiah Nov 16 '15 at 02:02
  • 1
    What *precisely* do you mean by "messages"? Are they length-preceded? Delimited? Did you design the protocol you are using on top of TCP yourself or is it an established one? If you designed it yourself, could you describe it to us? (If you're just pretending you have a message protocol even though you neither designed nor implemented one, well, see my answer.) – David Schwartz Nov 16 '15 at 02:12

1 Answers1

-1

The client essentially sends messages to the server and the server terminal prints whatever was being sent.

That means somewhere in the server, there must be code to receive a message. It also means that your protocol specification must somewhere define what a "message" is, otherwise it's not possible to write code to receive one.

while (read(newsockfd, &buffer, 256) > 0)
    printf("%s", buffer);

You called the TCP read function, which reads some bytes from the TCP byte stream. Then you threw away the length of the data, so you have no idea how much data you read. Then you passed it to a function that expects a C-style string. Where's the code to receive a message?

TCP is a byte-stream protocol. It sends and receives a stream of bytes. If you want to make a message protocol on top of it, so that you can send and receive messages, you can. But you have to three things:

1) Define what a "message" is. (For example, "a sequence of zero or more bytes not including a newline, return, or zero byte, delimited by a newline".)

2) Write code to send a message.

3) Write code to receive a message.

We can't tell if you did steps 1 or 2, but you definitely didn't do 3. So this code can only work by luck or magic.

It would probably be very helpful for you to read some specifications for protocols layered on top of TCP such as HTTP, IRC, or SMTP. Then, before you write any code that uses TCP and doesn't use an established protocol, spend the time to write up a protocol specification for the protocol you're planning to implement. This will help you avoid missing essential steps.

David Schwartz
  • 179,497
  • 17
  • 214
  • 278