Re: recvfrom() strange operation
- From: kzsolt@xxxxxxxxxx
- Date: 8 Sep 2006 10:10:45 -0700
"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...
"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. The result is the recv and the recvfrom working fully
different way in case of TCP and UDP. This is like if the fread()
working different if you read file with extension .abc than you read
file with extension .bcd
steve_schefter@xxxxxxxxxxx írta:
kzsolt@xxxxxxxxxx wrote:
"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.
Not sure what you mean by buffering, but since you indicate that
it has a CPU overhead, I'd guess you mean copying the data
rather than just queueing. If that's the case, you might want to
take a careful look at the design. The one copy from kernel to
user space (in the case of incoming data) would normally be the
only copy you need to do. Any other copying as it moves
through the layers of the protocol stack is probably a poor
design.
And of course I write the same algorithm already in the kernel...
I don't quite follow this part either. If some code exists within
the kernel and implements a portion of your protocol stack
(analyzing some bytes of the message), then why would this
same code exist within user space? And you you are
accessing TCP/UDP using recvfrom(), what do you have in
the kernel?
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
.
- Follow-Ups:
- Re: recvfrom() strange operation
- From: steve_schefter
- Re: recvfrom() strange operation
- References:
- recvfrom() strange operation
- From: kzsolt
- Re: recvfrom() strange operation
- From: steve_schefter
- Re: recvfrom() strange operation
- From: kzsolt
- Re: recvfrom() strange operation
- From: steve_schefter
- recvfrom() strange operation
- Prev by Date: Re: malloc more than physical memory
- Next by Date: Re: recvfrom() strange operation
- Previous by thread: Re: recvfrom() strange operation
- Next by thread: Re: recvfrom() strange operation
- Index(es):