Recent Features
| |||||||||||||
TCP friendsTCP friendsPosted Aug 16, 2012 10:23 UTC (Thu) by Fowl (subscriber, #65667)Parent article: TCP friends
Wow, I'd always just assumed that this is the way that it worked from the beginning.
(Log in to post comments)
TCP friends Posted Aug 16, 2012 11:44 UTC (Thu) by gb (subscriber, #58328) [Link]
Hmmm. One of use cases for local sockets is software testing. In this case everyone expects that local sockets behave exactly as remote, except latency introduced by transferring over network is close to zero. Will this patch change something for this use-case?
TCP friends Posted Aug 16, 2012 12:54 UTC (Thu) by hummassa (subscriber, #307) [Link]
In principle, the only change is that latency is now even closer to zero.
TCP friends Posted Aug 16, 2012 13:45 UTC (Thu) by Kioob (subscriber, #56482) [Link]
And what abouts netfilter ? That code seems also skipped, no ?
For example, you can deny some local users to connect to a local TCP socket.
TCP friends Posted Aug 16, 2012 15:33 UTC (Thu) by paravoid (subscriber, #32869) [Link]
"tcpdump -i lo" too I guess. Which I found quite useful in some cases.
TCP friends Posted Aug 16, 2012 23:12 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
tcpdump hasn't reliably shown 'packets on the wire', even for physical devices, since checksum offload was implemented. The loopback device already skips checksum generation, TCP segmentation and UDP fragmentation.
But you can turn most of these offloads/optimisations off if you want (though you can't force checksum generation for loopback). The same goes for tcp_friends.
TCP friends Posted Aug 18, 2012 0:00 UTC (Sat) by intgr (subscriber, #39733) [Link]
> tcpdump hasn't reliably shown 'packets on the wire', even for physical devices, since checksum offload was implemented
The lack of checksums is a very trivial issue. The lack of segmentation is also irrelevant -- it appears as an interface with an infinitely large MTU. The packets captured on "lo" are still basically valid TCP packets.
Not seeing any packets and being unable to debug network interactions *at all* is a huge deal compared to these.
TCP friends Posted Aug 17, 2012 14:31 UTC (Fri) by Creideiki (subscriber, #38747) [Link]
The fact that Solaris doesn't allow that is a constant source of frustration in my day job.
TCP friends Posted Aug 16, 2012 23:04 UTC (Thu) by BenHutchings (subscriber, #37955) [Link]
Only data transfer on a connected socket bypasses the full receive and transmit path. So you can still block connections. NATting of loopback connections might go horribly wrong though.
TCP friends Posted Aug 18, 2012 5:52 UTC (Sat) by dashesy (subscriber, #74652) [Link]
Interesting, I had exactly the same thought. Maybe short-circuit below the IP in the stack. I guess winsock does that, would be interesting to test a few things and compare the performance (TCP/IP) with this new patch.
TCP friends Posted Aug 26, 2012 17:59 UTC (Sun) by philomath (guest, #84172) [Link]
Exactly. I wonder how many more "low hanging fruit" are out there.
|
|||||||||||||