constantly reading and writing to a tcp server

continually sending commands and writing commands to a tcp server.
is the following code faulty:

after connection was successful:

Code:

---

        while(1) {

                ret = write(sock, CMD, sizeof(CMD));
                printf("sent: %d: %s\n", ret, CMD);

                ret = read(sock, buff, sizeof(buff));
                if (ret > 0) {
                        fprintf(stdout, "recv: %d: %s\n", ret, buff);
                }

                [ ... do something with buff ... ]

                memset(buff, 0, MAXBUFFER-1);

                sleep(1);

        }

---

what seems to happen is that the server receives the first CMD fine but after
the first time it seems not to receive it or it gets corrupted somehow.
I've made sure with tcpdump that the packet arrives and the CMD also arrives
at the server so I'm not sure what could be wrong.

in anyway, if this is not the way to continually process returned values based on
commands sent to the server, I'd be happy if you can correct me on that.

thanks.

You should probably make sure you received the entire response. A single read() might only read a partial response.

Is this the server or client code?

You seem to be making some assumptions about the things being read being
a) complete lines
b) that they always end with a \0
c) that send() always sends the whole message in a single call (it doesn't)

For me, I would
- write strlen(CMD) bytes to the stream.
- read sizeof(buff)-1 bytes, and use the return result to append a \0 in the correct place.

You also need to take care of message fragmentation, which means
- use the return result of write to check the whole message was sent, and if not, then call write again with the remainder of the buffer.
- use the return result of read to create a proper C string of the message. You then need to parse the message to determine just how many commands (or command fragments) exist within the received data.

Think of how you would deal with a text file (where you would normally use fgets()), where the only interface you had was an fread() call which randomly filled the buffer up to the amount you specified.
That's how it is with TCP.

Yes, it's all very predictable when you run one command at a time, but when you bump up the data rates, all sorts of internal network optimisations kick in, and you have to be prepared for that eventuality.

That was the client code.
The server is basically a netcat tcp server which spawns a bash script:

Code:

---

#!/bin/bash
while read cmd
do
  echo $cmd
done

---

again, what happens is that at the first attempt the c client sends the command,
and is receiving it back fine but after that it receives nothing, as if it didn't send
the command or it got messed up but with a sniffer I can see that it doesn't.

to rule out possibilities I started netcat in plain mode tcp server and connected
to it with the c client and that resulted in a normal "telnet" session where both
server/client read and write just fine.

that seems to mean that the problem is with the bash script but if I use netcat
as a client to connect to netcat as the tcp server spawning the bash script it
also works fine.

I'm assuming the problem lies with my piece of code which is as you said assuming
a whole lot of things but I would guess that for the simplest tasks it would just
"work".

I figured out this wasn't actually an issue with the code.
The bash script which echo'ed back the string also included the \n char
which made some mess on the read buffer.

Anyway, thanks for your input.