On Wed, 21 Sep 2005, Sten Daniel Sørsdal wrote:
Robert Watson wrote:
So if someone could generate some application pseudo-code that suggests
what specifically is necessary from the socket layer in order for the
application to function, we can talk about socket service extensions
that might support the application. For example, a way to query
detailed error information rather than just the SO_ERROR socket option.
Or a longer haul PMTU data gathering mechanism for UDP sockets. Or ways
for UDP applications to more usefully query the kernel for the TCP PMTU
data already being recorded.
It sounds like for the bandwidth tester, IP raw sockets already provide
what you need, since you want to be able to do fairly irregular UDP
things (i.e., receive UDP packets with bad checksums, and see
fragments).
IP raw sockets? Sure, Everything can be solved the complicated way :o)
Some userland applications could benefit from having the option of DF
flag set/unset.
UDP sockets are defined as being a way to send and receive valid UDP
datagrams. Your list of things to receive included fragments and invalid
datagrams. While I agree with your comments below about things UDP
applications want to do, I don't agree that we should teach UDP sockets to
receive UDP datagram fragments or packets with bad checksums.
Applications looking for non-accepted IP packets and complete ICMP
messages should be using the raw socket interface. Applications looking
for post-processed abstracted interfaces to a datagram service should be
using UDP sockets. See below for discussion of enhancing UDP sockets.
What about applications that wants to have a way of optimizing UDP
transfers in their network path?
Some networks filter icmp and fragments irresponsibly (imho) and
sometimes the combination of two or more networks that would cause
problems for multicast/video/voip applications.
Sometimes in one network udp packets need fragmenting and in the next
network fragments need to get reassembled to pass a firewall which in
turn runs out of reassembling resources. ( It is more common to block
icmp messages about reassembly problems than DF problems IF a message is
generated in the first place. )
Sure, all of this could be fixed the complicated way but what if one
already has an application that runs in unprivileged userland. How many
lines of code would a simple socket option plus the "tuning" code
require?
You're still not answering my question about application pseudo-code,
however. Adding an IP_DF option to UDP sockets is easy, and can be done in
ten lines of code or less. Adding a way to provide detailed feedback on
error conditions associated with UDP packets sent at arbitrary points in
the path is not something that falls naturally out of the socket API, and
will require non-trivial amounts of work. Hence my asking about the
structure and event model of your application: what exactly do you want to
know about UDP packet delivery?
Specifically, what information do you as a developer need in order to
handle asynchronous error delivery from UDP packet send, and how will it
affect your application's interaction with the network stack? We can
already deliver an synchronous EMSGSIZE when you try to send a UDP packet
out of an interface with an MTU that is lower than the packet size, given
a socket option to force IP_DF. However, if the packet hits a potential
fragmentation problem out in the wide area network, that notification is
completely asynchronous from packet transmission, and we will need a way
to feed more detailed ICMP information to the application. Right now
asynchronous error delivery on a UDP socket is already fairly messy due to
the fact that generally applications can only pick up the error when doing
further I/O, confusing the issue of which operation actually generated the
error.
Robert N M Watson
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
