On 9 Jun 2003, Krzysztof Halasa wrote:
> "David Schwartz" <email@example.com> writes:
> > It really doesn't matter. UDP applications have to control the transmit
> > pacing at application level. There is absolutely no way for the kernel to
> > know whether the path to the recipient is congested or not.
> Because what? The kernel knows everything it has to know - i.e. complete
> state of socket queue in question.
yes it does when you call select
take a probgram thats sharing the same cosket between 2 processes
or a multithreaded program sharing any socket from the time
that select is called and read / write is called the data
or buffer form the socket could have been completly filled or completly
> But if select() on sockets is illegal, should we make it return -Esth
> instead of success. Certainly, we should get rid of invalid kernel code,
nobody said it was illegla but in certin situations it
might as well count as a nop;
> > The kernel can't tell you when to send because that depends upon
> > factors
> > that are remote.
> Such as?
if you are on a udp socket say you have host a host b and host c
host a and host b are on the same network host c is on another networked
connected by 512kbit link (faster / slower) and you are calling select on
host a. host b blast a silly amount of data to host c
host a does the same. What happen ? who wins ?
> > Yes, it would be nice of the kernel helped more. But the application
> > has to
> > deal with remote packet loss as well.
> Could you please show me a place in the kernel which could cause such
> a loss on local datagram sockets?
Same as a multithreaded program select could say its ok to write when you
write data it could be a completly different story
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jun 15 2003 - 22:00:22 EST