A mysterious excerpt from UNPv1 by W. R. Stevens

[e1p1s]

My question is simple. I can't understand what he(W.R.Stevens)
says when he mentions TCP instead of the UDP method in Sec.26.6
Examining the UDP Checksum Field. While checking the "UDP"
checksum field of a name server, why does he talk about TCP as
an alternative to UDP? Any help? Thanks.

[William Ahern]

e1p1s <e1p1s777@hotmail.com> wrote:

> My question is simple. I can't understand what he(W.R.Stevens)
> says when he mentions TCP instead of the UDP method in Sec.26.6
> Examining the UDP Checksum Field. While checking the "UDP"
> checksum field of a name server, why does he talk about TCP as
> an alternative to UDP? Any help? Thanks.

UDP has no flow control, and the DNS protocol doesn't provide for flow
control over UDP either. So, if a request cannot be returned in exactly one
UDP packet (the default size being rather small so that it will be able to
make it thru the myriad of routers on the return path w/o being fragmented)
then DNS provides for a fall-back to TCP.

DNS was meant to be fast, thus the use of UDP. However, for things
like zone transfers, the requested data can't fit onto a single
UDP packet, so TCP is used instead. But, IIRC, you could use
TCP instead of UDP for anything in the DNS protocol.

- Bill

[Lew Pitcher]

Without hesitation, e1p1s asserted (on or about 08/02/03 22:05) that:

> My question is simple. I can't understand what he(W.R.Stevens)
> says when he mentions TCP instead of the UDP method in Sec.26.6
> Examining the UDP Checksum Field. While checking the "UDP"
> checksum field of a name server, why does he talk about TCP as
> an alternative to UDP? Any help? Thanks.

AFAICT, he only mentions TCP twice in 26.2

The first time, he points out that the UDP checksum is not made available to
the UDP socket, so you can't manipulate UDP checksums that way. At that
point, he indicates that you can't read UDP or TCP packets through raw
sockets, so you can't manipulate the UDP checksum through a raw socket. If I
read the sentence correctly, the reference to TCP is only for completeness
wrt raw sockets, and has nothing to do with UDP checksums.

The second time he mentions TCP, he again seems only to refer to it for
completenes, indicating that a program to retrieve the TCP checksum cannot
be easily written to mirror the UDP checksum program because the program
uses the libpcap tool, which bypasses the standard TCP stack, and any TCP
packet generated with this tool would cause the TCP stack to have a fit when
it receives the conversation reply. Again, the TCP reference is only for
completeness, and does not apply to the UDP checksum field.


--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 ([url]http://counter.li.org/[/url])
Slackware - Because I know what I'm doing.

[e1p1s]

Thanks, Bill. But, I think your answer is about a general
characteristic of UDP and TCP. I need to describe my question
more concretely. I present some excerpts from the book (without
Stevens's permission) with my detailed questions.

>We also note that it is harder to write a test program of this
>form that uses TCP, even though we are easily able to write
>out our own TCP segments, because any reply to the TCP segments
>that we generate will normally cause our TCP to respond with
>an RST to whomever we sent the segment.

Can the replies (from the name server) to the TCP segments
(made in the test program) be "UDP"?

If not (i.e. if the replies are TCP), how can they contain the
UDP checksum field without any UDP things?

Or, the imaginary TCP test program does NOT test the UDP checksum,
but only tests similar objects and has the same form as the UDP
checksum program?

[e1p1s]

Lew Pitcher wrote:

> AFAICT, he only mentions TCP twice in 26.2

"26.2" would be "26.6." :)

Thanks for your helpful remarks.

[e1p1s]

e1p1s wrote:

> Or, the imaginary TCP test program does NOT test the UDP checksum,
> but only tests similar objects and has the same form as the UDP
> checksum program?
>

This would answer my question.