Re: recvfrom() strange operation

So gentlemans first thank you for all of the answers!

"Any reason not go always supply a buffer at least as big as your
datagram?"
Our application is a reliable protocol running in separated threads and
theoretically working over TCP and UDP too. If I have no chance to
retrive packet content by bytes then the only way is implement
additional buffering. But this buffering is triple buffering in our
stack instead of double buffering. This cost mouch CPU and time too.
And of course I write the same algorithm already in the kernel...

No matter the data arrived over TCP or UDP, arrived in packet (more
than one octett units). In case of TCP implement buffering and I can
retrive packet data as byte, but in case of UDP not. I think the
buffering calls missing from the UDP path.

steve_schefter@xxxxxxxxxxx írta:
kzsolt@xxxxxxxxxx wrote:
Linux SU9.3 I586 K: 2.6.11.4-21.11 / GCC 3.3.5

I send one packet trough SOCK_DGRAM socket (UDP) like this
sendto(sockfd,"abcdefghijklmnop",16,0,xxx,nnn);

On a receiver sied in case of:
recvfrom(sockfd,p,16,0,xxx,nnn);
the p contain "abcdefghijklmnop"
but in case of:
recvfrom(sockfd,p,1,0,xxx,nnn);
recvfrom(sockfd,q,15,0,xxx,nnn);
the p contain "a"
the q is empty (insted of "bcdefghijklmnop")
If I use SOCK_STREAM (TCP) ths same code working fine.


From the recvfrom() man page:
If a message is too long to fit in the supplied buffer,
excess bytes may be discarded depending on the type of
socket the message is received from (see socket(2))

and from the socket man page:
SOCK_SEQPACKET sockets employ the same system calls as
SOCK_STREAM sockets. The only difference is that read(2) calls
will return only the amount of data requested, and any remaining in
the arriving packet will be discarded. Also all message boundaries
in incoming datagrams are preserved.

No specific mention of SOCK_DGRAM discarding excess data, but
you emperical evidence would suggest that it does. You'd have to
look at the kernel source to see for sure, but it looks like you can't
control this. Any reason not go always supply a buffer at least
as big as your datagram?

Regards,
Steve
------------------------------------------------------------------------
Steve Schefter phone: +1 705 725 9999 x26
The Software Group Limited fax: +1 705 725 9666
642 Welham Road,
Barrie, Ontario CANADA L4N 9A1 Web: www.wanware.com

.

Relevant Pages

  • Lost data on socket - Can we start over politely?
    ... input at the server. ... I've switched to using only buffered reads and writes on the socket fd's, ... It's not buffering ... sub get_packet { ...
    (comp.lang.perl.misc)
  • Re: Lost data on socket - Can we start over politely?
    ... I also implemented strict and warnings. ... > buffering issue. ... > I've switched to using only buffered reads and writes on the socket fd's, ... Instead please try this server (some quickly reduced code from a bigger ...
    (comp.lang.perl.misc)
  • Re: IO::Select::select() says no readable data even if there are
    ... However, buffering problems I have: ... When I write two lines from server to socket and do ... As you said, you have buffering problems. ... Detect EOF by waiting for sysread to return 0. ...
    (comp.lang.perl.misc)
  • Re: fdopen, sockets, stdio
    ... > Do you guys use the stdio to write to and read from sockets? ... and I've been writing sockets-based software professionally ... Using two separate FILE* objects won't prevent buffering issues. ... socket and has full buffering enabled, and the peer sends less data ...
    (comp.unix.programmer)
  • Buffering client data in a Server application
    ... problems implementing a buffering system for holding client data until ... recvq right after data is availiable for the socket and write buffered ... cli = getclient; ...
    (comp.lang.c)