From: David Stevens <[EMAIL PROTECTED]>
Date: Tue, 12 Jul 2005 14:16:30 -0700
> In its RFC incantation, it allows for out-of-order delivery of an
> arbitrary (but limited) amount of data. The BSD implementation
> made it largely unusable by widely distributing something that
> didn't compute the o
How is this different than plain old TCP urgent data? Except that
the receiver has to know where the special data is.
In its RFC incantation, it allows for out-of-order delivery of an
arbitrary (but limited) amount of data. The BSD implementation
made it largely unusable by widely distributing som
From: Harald Welte <[EMAIL PROTECTED]>
Date: Tue, 12 Jul 2005 13:31:23 +0200
> On Mon, Jul 11, 2005 at 01:21:03PM -0700, David S. Miller wrote:
> > I still see no real use for this feature. Either the data is
> > stored inside of kernel buffers, or user application buffers.
> > And if the data se
On Mon, Jul 11, 2005 at 01:21:03PM -0700, David S. Miller wrote:
> I still see no real use for this feature. Either the data is
> stored inside of kernel buffers, or user application buffers.
> And if the data sent is not useful to the receiver, fix the
> sender to not send the unwanted data.
Wel
David S. Miller wrote:
>From: Chase Douglas <[EMAIL PROTECTED]>
>Date: Mon, 11 Jul 2005 12:33:46 -0500
>
>
>
>>I'm sorry, I made a careless mistake in choice of context. What this would
>>be useful for is applications where we want to seek ahead in one stream from
>>one connection. This is not m
From: Chase Douglas <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 15:14:44 -0500
> This may not mean much for normal use, but there are academic instances,
> especially in cluster computing, where saving many extra user-user
> copies can really add up.
So, basically, the useful situation is that the
From: Chase Douglas <[EMAIL PROTECTED]>
Date: Mon, 11 Jul 2005 12:33:46 -0500
> I'm sorry, I made a careless mistake in choice of context. What this would
> be useful for is applications where we want to seek ahead in one stream from
> one connection. This is not meant for seeking somehow between
On 7/8/05 4:46 PM, "David S. Miller" <[EMAIL PROTECTED]> wrote:
> From: Chase Douglas <[EMAIL PROTECTED]>
> Date: Fri, 08 Jul 2005 16:12:12 -0500
>
>> This can be useful for programs such as mpi. In mpi, a server receives
>> results of computations from clients. However, the server cannot control
From: Chase Douglas <[EMAIL PROTECTED]>
Date: Fri, 08 Jul 2005 16:12:12 -0500
> This can be useful for programs such as mpi. In mpi, a server receives
> results of computations from clients. However, the server cannot control who
> sends data when. If the server needs data from client A to know ho
I've been working on the implementation for seekable sockets in tcp. A patch
of my work so far is attached. I believe that it works correctly excepting a
bug in tcp_collapse_seekable, which has been disabled in tcp_prune_queue to
prevent it from arising at the moment.
What this patch creates
10 matches
Mail list logo
