Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S262771AbTEAXQA (ORCPT ); Thu, 1 May 2003 19:16:00 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262776AbTEAXP7 (ORCPT ); Thu, 1 May 2003 19:15:59 -0400 Received: from [217.144.230.27] ([217.144.230.27]:56283 "HELO lexx.infeline.org") by vger.kernel.org with SMTP id S262771AbTEAXP6 convert rfc822-to-8bit (ORCPT ); Thu, 1 May 2003 19:15:58 -0400 Date: Fri, 2 May 2003 01:32:03 +0200 (CEST) From: Ketil Froyn X-X-Sender: ketil@ketil.hb.local To: Chris Friesen cc: =?ISO-8859-1?Q?P=E5l?= Halvorsen , Mark Mielke , bert hubert , Subject: Re: sendfile In-Reply-To: <3EB1A029.7080708@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 920 Lines: 25 On Thu, 1 May 2003, Chris Friesen wrote: > P?l Halvorsen wrote: > > > OK, but I understand that my streaming scenario is not the target > > application for sendfile. > > What stops you from using sendfile (with TCP) to each destination > separately, with the client only reading from the pipe as needed > (presumably with a number of frames worth of buffer on the client > side)? I don't think TCP is suitable for streaming multimedia stuff to clients. For instance, if a packet does not arrive on the client, it's better to handle this in the client and skip a frame or show one of worse quality than to have the video stop while waiting for the server to resend. Ketil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/