You should define, at least in well written comments, the protocol between client and server (which messages are sent, how they are delimited) It is usally easier to debug a textual message protocol. So you might consider sending lines each terminated by a newline character (or have some more complex messages structured with a header and a body, the header giving the size of the message body. Look into HTTP or SMTP for inspiration).
You might for instance decide that each message holds a JSON encoded data and is newline terminated. Beware of endianness issues (the server and client are often different machines). See byteorder(3) (hence, sending a number as text is simpler).
Transmission time is much longer than CPU time for encoding in text format.
As I commented, you should buffer manually socket I/O. So call read
(or recv
) and write
(or send
) on large (e.g. 16 kilobytes) chunk, and have your code separate the chunks into meaningful messages. Don't expect that a send
(or write
) on one side corresponds to a single recv
(or read
) on the other side. TCP/IP sockets are just streams of bytes (without message boundaries). You should use the result of read
(or recv
) or write
(or send
) and implement buffering accordingly.
Avoid send
-ing (or write
-ing) short messages (e.g. one or a few bytes each). This is generally very inefficient.
Read wikipage on TCP and read(2), recv(2), write(2), send(2), socket(7), ip(7), tcp(7) etc... man pages.