CODEWITHSUNDEEP
csocketsnetwork-programming
scaletos
scaletos

Reputation: 113

Getting two messages from receive when only one is sent

I wrote a server that should wait for messages from a client after opening a connection to it:

while(1){
  if(recv(mySocket, buffer, 1000, 0) < 1){
     continue;
  }   
  printf("Message received: %s", buffer);
}

I checked with wireshark which packets were sent to this server, but for every packet sent there were 2 printf outputs.

My question is now where did I get this additional message from.

(The additional message are some random bytes. But every time the same.)

Upvotes: 0

Views: 1058

Answers (2)

chqrlie
chqrlie

Reputation: 144989

John Bollinger's answer is accurate and provides insight into what you should do to create a reliable client / server application.

Regarding your question, There is another problem that explains the actual output you see. the packet is most probably sent and received in a single chunk, as you observe with wireshark. The bug is in your server: You receive the data in a char array and print it directly as a string with printf. I suspect the packet does not contain the terminating '\0' to make the buffer a proper string for "%s". printf will output the packet contents plus whatever buffer contents is there until it reaches a '\0' byte, possibly invoking undefined behaviour. If the packet is split in several chunks, you may see the same contents several times, and random characters too.

Here is how you should fix your code:

char buffer[2000];
...
for (;;) {
    ssize_t count = recv(mySocket, buffer, 1999, 0);

    if (count >= 1) {
        buffer[count] = '\0';
        printf("Message received: |%s|", buffer);
    }
}

Note that the buffer must be at least 1 byte longer than the maximum packet size, and this tracing method cannot handle embedded '\0' bytes in the packets.

Of course the packets can be sliced and diced on the way between the client and the server, so you must deal with this appropriately to implement a proper protocol.

Upvotes: 0

John Bollinger
John Bollinger

Reputation: 181149

Your apparent expectations for the behavior of recv() are not justified. As @KarolyHorvath observed in comments, stream sockets (among which TCP-based sockets fall) have no sense whatever of "messages". In particular, network packets do not correspond to messages on a stream socket. POSIX has this to say about the behavior of recv(), in fact:

For stream-based sockets, [...] message boundaries shall be ignored.

Although that's more likely to have the effect of combining multiple "messages", it can also mean that a single message (as dispatched by a single send() call) is split over multiple recv() calls. It certainly will mean that if the buffer length you specify to recv() is less than the number of bytes actually received on the socket, but there are other circumstances in which that result could be obtained, too.

On success, recv() returns the number of bytes copied into the receive buffer. If you are genuinely trying to implement some sort of "message" exchange, then you can use that to help you split incoming data on message boundaries. Do recognize, however, that that constitutes implementing a message-passing protocol on top of a stream, so sender and receiver need to cooperate, at least implicitly, for it to work.

Upvotes: 2

Related Questions