CODEWITHSUNDEEP
clinuxwebtcp
wick
wick

Reputation: 2234

reading from tcp socket in c, and chucking data without being copied to user space

There is a peek option when I can read socket buffer without actual reading it (to learn number of bytes available for consequent reading). There is such alternative with fcntl call.

I would like to find out if there is a way to actually reading from socket buffer without copying the data from the socket to application buffer? So to puzzle the kernel if you like: the aim is not to lose time on copying actual data when designing something like a tool of load creation on a web server: we need tcp communication to rightly happen, but we don't need the data received. Any advise, please?

Upvotes: 1

Views: 1351

Answers (3)

Daniel
Daniel

Reputation: 3416

man tcp is your friend on a Linux system:

Since version 2.4, Linux supports the use of MSG_TRUNC in the flags argument of recv(2) (and recvmsg(2)). This flag causes the received bytes of data to be discarded, rather than passed back in a caller-supplied buffer.

Hence you can do (on a TCP socket) for instance,

   int n = recv(sock_fd, buf, buf_size, MSG_TRUNC);

This will consume up to buf_size bytes from the socket descriptor sock_fd without actually copying them to the buffer.

Upvotes: 3

yeyo
yeyo

Reputation: 3009

This answer was meant to be a comment but it's just to large for a comment IMHO.

Yes using splice(2) performance will be increased (if this is your bottle neck of course) (are you sure this is your bottle neck?). Although splice(2) is a Linux specific system call, and should not be used in portable programs. So let see few of your options:

  1. splice(2) very efficient yet not portable.
  2. The sendfile(2) system call is portabler yet the prototype varies across UNIX systems.
  3. Make a wrapper function for several operative system.
  4. Use libevent.

IMO you should use libevent, it provides a nice interface portable across several platform.

Upvotes: 1

wick
wick

Reputation: 2234

Skimming through the hint proposed by Kira gave me idea of the splice() call with /dev/null destination. Should do for now :-)

Upvotes: 0

Related Questions