Re: Problem with unix sockets: SOCK_DGRAM ignores MSG_TRUNC

On Monday 05 February 2007 01:52, David Miller wrote:
Thus I used recv() with flags MSG_TRUNC|MSG_PEEK in order to detect
message truncation due to insufficient buffer size.

What part of "Only valid for packet sockets" from the manual page
escapes you? :-))
It's a feature which only was meant to be valid for AF_PACKET sockets.

Thanks for pointing that out. I thought, "packet sockets" means
"datagram-oriented socket". Obviously it means PF_PACKET instead. It's
hard to learn programming IPC by only reading man pages :-)

What UDP is doing is different, it's returning the full packet length
when the packet is larger then the given buffer size, but it does this
irregardless of whether you set MSG_TRUNC in the recvmsg() passed-in
flags. UDP itself sets the MSG_TRUNC flag when it detects this
situation.

Please correct me gently if I am wrong: According to the kernel source
code, this behaviour was introduced with patch-2.6.8:

http://www.kernel.org/diff/diffview.cgi?file=/pub/linux/kernel/v2.6/patch-2.6.8.gz;z=4325

linux/net/ipv4/udp.c
+
err = copied;
+ if (flags & MSG_TRUNC)
+ err = skb->len - sizeof(struct udphdr);

I think local sockets (PF_UNIX) implement a different semantics: According
to unix_dgram_recvmsg() in linux/net/unix/af_unix.c, in case of
truncation the buffer size is returned and not the full packet length.

In my opinion this implementation of local sockets (PF_UNIX) is not
following the wording of the man page man 2 recv: "These calls return
the number of bytes received". Am I getting something wrong here?

Why not improve consistency and make unix_dgram_recvmsg() return the full
packet length? So it would behave as UDP does. What do you think about
adding the following code to linux/net/unix/af_unix.c:
err = size;
+ if (flags & MSG_TRUNC)
+ err = skb->len;


Cheers
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Sockets. Limit on message length.
    ... With non blocking - and therefore asynchronous - sockets there is a ... OnReceive handler) that the data you get is not going to start on a ... going to contain a packet worth of bytes. ... So you *need*, in your OnReceive, to buffer the recieved data and then call ...
    (microsoft.public.win32.programmer.networks)
  • Re: Sockets and Buffer size
    ... Let's say your buffer is 2048 bytes, but the size of your packet is 230. ... Conversation: Sockets and Buffer size ... server, so i guess i need to use asynchronous sockets. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Interesting TCP behaviour with large sends/small buffers
    ... My current workaround is simply setting the send buffer to a larger ... The server, upon connection, sends a configurable number of bytes to ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: Interesting TCP behaviour with large sends/small buffers
    ... The server, upon connection, sends a configurable number of bytes to ... I set the client's receive buffer size to 1MBps, ... packet before sending the next packet. ... ACK, according to the delayed ACK algorithm - 50KB bytes means 34 MSS- ...
    (microsoft.public.win32.programmer.networks)
  • Re: Fundamentals question, is this how it works?
    ... You maintain a buffer for the last incomplete packet. ... receiving that many bytes i then break and wait for the next set of data ... With a tcp stream socket what happens when it is reading say 4000bytes ...
    (microsoft.public.win32.programmer.networks)