Passing a structure through Sockets in C

by

This is a very bad idea. Binary data should always be sent in a way that:

Don’t ever write a whole struct in a binary way, not to a file, not to a socket.

Always write each field separately, and read them the same way.

You need to have functions like

unsigned char * serialize_int(unsigned char *buffer, int value)
{
  /* Write big-endian int value into buffer; assumes 32-bit int and 8-bit char. */
  buffer[0] = value >> 24;
  buffer[1] = value >> 16;
  buffer[2] = value >> 8;
  buffer[3] = value;
  return buffer + 4;
}

unsigned char * serialize_char(unsigned char *buffer, char value)
{
  buffer[0] = value;
  return buffer + 1;
}

unsigned char * serialize_temp(unsigned char *buffer, struct temp *value)
{
  buffer = serialize_int(buffer, value->a);
  buffer = serialize_char(buffer, value->b);
  return buffer;
}

unsigned char * deserialize_int(unsigned char *buffer, int *value);

Or the equivalent, there are of course several ways to set this up with regards to buffer management and so on. Then you need to do the higher-level functions that serialize/deserialize entire structs.

This assumes serializing is done to/from buffers, which means the serialization doesn’t need to know if the final destination is a file or a socket. It also means you pay some memory overhead, but it’s generally a good design for performance reasons (you don’t want to do a write() of each value to the socket).

Once you have the above, here’s how you could serialize and transmit a structure instance:

int send_temp(int socket, const struct sockaddr *dest, socklen_t dlen,
              const struct temp *temp)
{
  unsigned char buffer[32], *ptr;

  ptr = serialize_temp(buffer, temp);
  return sendto(socket, buffer, ptr - buffer, 0, dest, dlen) == ptr - buffer;
}

A few points to note about the above:

  • The struct to send is first serialized, field by field, into buffer.
  • The serialization routine returns a pointer to the next free byte in the buffer, which we use to compute how many bytes it serialized to
  • Obviously my example serialization routines don’t protect against buffer overflow.
  • Return value is 1 if the sendto() call succeeded, else it will be 0.

More Related Contents:

  1. How large should my recv buffer be when calling recv in the socket library
  2. Connection refused – tcp socket in linux [closed]
  3. What’s the correct answer about getservbyname?
  4. How do I change a TCP socket to be non-blocking?
  5. Wake up thread blocked on accept() call
  6. Sending file descriptor by Linux socket
  7. What are the use cases of SO_REUSEADDR?
  8. Error: Address already in use while binding socket with address but the port number is shown free by `netstat`
  9. Turn a simple socket into an SSL socket
  10. Linux: is there a read or recv from socket with timeout?
  11. Socket accept – “Too many open files”
  12. Is there a way to flush a POSIX socket?
  13. Using sys/socket.h functions on windows
  14. How to signal select() to return immediately?
  15. Bind failed: Address already in use
  16. socket connect() vs bind()
  17. Socketpair() in C/Unix
  18. Writing to a closed, local TCP socket not failing
  19. Problems with SO_BINDTODEVICE Linux socket option
  20. Is accept() thread-safe?
  21. close() is not closing socket properly
  22. Is it possible to access/update the child thread’s resource from parent thread?
  23. Why is it assumed that send may return with less than requested data transmitted on a blocking socket?
  24. bind socket to network interface
  25. Is it possible (and safe) to make an accepting socket non-blocking?
  26. How to reset a socket back to blocking mode (after I set it to nonblocking mode)?
  27. Strange RAW Socket on Mac OS X
  28. Releasing bound ports on process exit
  29. With C TCP sockets, can ‘send’ return zero?
  30. Why should I use, or not use, MSG_CONFIRM?

Leave a Comment