lkml.org 
[lkml]   [2008]   [Nov]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Unix sockets via TCP on localhost: is TCP slower?
On Fri, Nov 14, 2008 at 4:09 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Fri, Nov 14, 2008 at 9:56 AM, David Miller <davem@davemloft.net> wrote:
>>> Why would you use windowing, ACKs, flow control and encapsulation on localhost?
>>
>> So that you could firewall, shape, redirect, and make other
>> modifications to the traffic, as well as see it in tcpdumps. That's
>> the power of Linux, and yes people do this stuff and yes people do
>> want these features to work over loopback.
>>
>>> I expected the kernel to copy data directly from user-space of the
>>> sending process to a kernel buffer of the receiving process, much like
>>> UNIX sockets.
>>
>> Then all of the above features and debugging facilities go away.
>
> So instead the recommendation is for all apps to support both TCP and
> Unix sockets?
> If you then use Unix sockets, you still lose all of those facilities
> and as a bonus, your apps are more complex.

Your application will not be much more complex. That's the point of
having generic sockets. You can wrap whatever protocol you want
underneath them. This isn't much harder than being able to read from a
file or switching around to read stdin if the filename the user gives
is "-"

>
> I'd prefer a switch that could be enabled to use such a shortcut for TCP.
> Firewalls should still work mostly (on connect), redirect would still work.
>

I think this is unnecessary, but if you can make a patch and prove
that it speeds up local connections while not slowing down everything
else, have at it.


\
 
 \ /
  Last update: 2008-11-14 14:19    [W:0.149 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site