> that packets are delivered at all, or that the sender > is notified if they aren't. No automatic retries. No guarantee that packets > are > delivered in order, or aren't duplicated.
True - but these are arguments against UDP, not against sendfile on UDP sockets. On the other hand UDP behaviour is exactly what one expects when transmitting video. And, well, it is what DVB-IPI and RFC 3550 say and what every IPTV operator does anyway! > Further, the point of sendfile() is speed (as well as ease of use, reducing > the > number of system calls needed, etc). If it's faster, it's likelier to > overrun the > receiver, causing it to silently drop even more packets. The point of sendfile() is (also) lower processor usage - avoiding over/underruns is a different, well known problem (see ISO/IEC 13818 T-STD ). > Last but not least, the man page for sendfile(3ext) > says: (...) > > A UDP socket is not SOCK_STREAM, so according to the Again, I have read the man page - what I am asking is *why* SOCK_DGRAM is not supported. > I am curious as to whether anyone has compared the > present cat(1) tricks > for speed (like last I looked ages ago, using mmap() > on one end sometimes) That's the next approach -- mmap()ed source chunks. This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
