Re: recvfrom() strange operation

kzsolt@xxxxxxxxxx wrote:
"Any other copying as it moves through the layers of the protocol stack
is probably a poor design."
If you think about all of the usefull frameing algorithm you have two
way:
1). "other copying"
2). read data byte by byte...

3) Have the lower level of the stack read the complete message
into a buffer accessible by all layers and then pass on the address
of the data rather than doing a copy. That's the way most protocol
stacks these days work.

"then why would this same code exist within user space"
I devolped a full IP protcol stack including UDP and TCP for our
company. This has no relation to x86 and unix kernel, but I know it
from inside.
To receive UDP or TCP packet you need some buffering of received data.
This mean the packet arrived with n byte user data, and the user can
read it sequecially by segmenets or by octetts. This is a same algo
like you read sequecially from the file (blocks). If this algo used for
buffering of TCP packet I do not undersatnd why not used for UDP
packets.

That's because TCP is a streaming (byte-oriented) protocol while
UDP is a message-oriented protocol. If the kernel did what you
wanted, then I as a programmer could not UDP recv() and know
that what I got was sent as a single message by the remote. I
may need to. It's designed this way on purpose, it just doesn't
suit your purpose.

Reading between the lines, it appears as though you are
moving from kernel space to user space just to be able to
access Linux sockets. This is not necessary. You can
access sockets in the kernel. See tux for example.

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

  • Re: servers address in ntp payload?
    ... > this service for the applications automatically. ... > the requirement, at least for UDP. ... And that's not a kernel defect because ... ... >> that bad design in the past somehow justifies bad design now? ...
    (comp.protocols.time.ntp)
  • Re: jumbograms (& em) & nfs a no go
    ... >> Implies the sending host is not honoring the MTU restriction when ... In more modern UNIX systems, it's a kernel thread, ... Is this maybe UDP? ... make sure that the packet goes through the UDP fragmentation ...
    (freebsd-current)
  • kernel 2.6.18-92.1.6 produces errors when using nfs and nis
    ... kernel 2.6.18-53.1.21.el5, with no change to any conf files when I switch ... The problem is that when the nfs service starts I get the following error ... 100000 2 tcp 111 portmapper ... 100000 2 udp 111 portmapper ...
    (Linux-Kernel)
  • Re: Send-Q on UDP socket growing steadily - why?
    ... Send-Q on a moderately active UDP socket keeps growing steadily until it reaches ~128K at which point socket writes start failing. ... The application in question is standard ntpd from Fedora 7, kernel is the latest available for the distro, that is ... "I don't know how to send these packets" mode forever. ...
    (Linux-Kernel)
  • Identifying Kernel 2.4.x based Linux machines using UDP
    ... Identifying Kernel 2.4.x based Linux machines using UDP ... Linux Kernel 2.4.x has a bug with the UDP implementation which allows ... Combined with another fingerprinting method using ICMP this time ...
    (Bugtraq)