What kinds of Software do you create in D.

H. S. Teoh hsteoh at quickfur.ath.cx
Tue Nov 2 18:28:36 UTC 2021


On Tue, Nov 02, 2021 at 05:54:09PM +0000, Patrick Schluter via Digitalmars-d wrote:
> On Tuesday, 2 November 2021 at 16:48:21 UTC, H. S. Teoh wrote:
[...]
> > A CGI app listening on a unix socket could potentially be useful in
> > certain sandboxed webserver setups where the webserver talks to the
> > CGI executable running in the background via the unix socket.  I've
> > actually seen similar setups before (an external webserver linked to
> > a localhost-only webserver running in a separate process), though
> > these days this approach is kinda obsolete.  But I could see some
> > niche use case where the CGI program is actually a daemon that's
> > doing other things in the background, and occasionally services a
> > request from the web-facing webserver via CGI.  A unix socket would
> > be just the thing for something like that.  (Though equally common,
> > if not more, these days is to just listen to a TCP socket bound to
> > localhost.)
> > 
> The performance difference between TCP sockets and Unix sockets is far
> from beieng negligeable. On our setup at work a memcached server on
> Unix sockets has twice the thtroughput of a localhost socket (Linux on
> 15 core intel server).

I'm not surprised, since the TCP stack is a non-trivial subsystem in the
kernel that does a LOT of things beyond just passing data from one place
to another.  At the very bare minimum, you need to add TCP headers and
wrap that in an IP packet on the sending end, and on the receiving end
unwrap the IP packet and process the TCP headers.  Whereas a write to a
unix socket could be as simple as a kernel memcpy from source process to
destination process and sending a notification to the destination
process. (Well, OK, IIRC there may be two memcpy's, one to transfer the
data to the kernel buffer, then another from kernel buffer to receiver
address space when the receiver calls read(). But still, that's a lot
less work than traversing the TCP stack.)

But I've seen a lot of "lazy" code that just uses a TCP socket on
localhost, because then they could just reuse existing network-based
code without change except for setting the source/destination IP
addresses to 127.0.0.1.


T

-- 
The best way to destroy a cause is to defend it poorly.


More information about the Digitalmars-d mailing list