The Unix Heritage Society mailing list
 help / color / Atom feed
* [TUHS] sockets (was Re:  First appearance of named pipes)
@ 2020-03-08 23:09 Norman Wilson
  2020-03-09 17:09 ` Tony Finch
  0 siblings, 1 reply; 21+ messages in thread
From: Norman Wilson @ 2020-03-08 23:09 UTC (permalink / raw)
  To: tuhs

Derek Fawcus:

  Yeah - I always found that a bit weird, having to use socketpair()
  to get a bidirectional "pipe".

In the Research system, pipes became bidirectional when
they became streams.  That happened slightly before my
time, but so far as I know it broke absolutely nothing.

Some time in the late 1980s, the System V people wanted
to allow pipes to be streams, but were worried about the
bidirectionality.  They proposed to have a new system call
to make a bidirectional pipe.

I attended a meeting with the relevant programmers and
program manager to find out why they thought pipes couldn't
just be bi-directional, as they had been without fuss in
the Research system for some years.  They agreed with me
that that was how it ought to be; the trouble was that
System V releases all had to pass an official System V
Verification Suite (reasonable enough), and that suite
checked not only that you could read the one pipe file
descriptor and write the other, but that you couldn't
do it the wrong way.

Wait a minute, I said.  I'm pretty sure that's not how
the official System V Interface Description reads.  Anyone
got a current copy handy?

We found one, and we looked, and sure enough, the official
verification suite was wrong.  The specification said
that data written to fd[1] must be readable from fd[0],
but nothing about the other direction: full-duplex pipes
were not required but neither were they outlawed!

The programming group was delighted: I'd given them the
ammo they needed to do it right (make pipes streams, and
make them full-duplex by default).  I believe that is
how it came out, though the only reference I have is
Solaris 10, where the manual page specifically says
that what pipe(2) makes is full-duplex (and a stream).

I wish POSIX and Linux and the BSDs would catch up; that
was only 30 years ago.

Norman Wilson
Toronto ON

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re:  First appearance of named pipes)
  2020-03-08 23:09 [TUHS] sockets (was Re: First appearance of named pipes) Norman Wilson
@ 2020-03-09 17:09 ` Tony Finch
  0 siblings, 0 replies; 21+ messages in thread
From: Tony Finch @ 2020-03-09 17:09 UTC (permalink / raw)
  To: Norman Wilson; +Cc: tuhs

Norman Wilson <norman@oclsc.org> wrote:
>
> I wish POSIX and Linux and the BSDs would catch up; that
> was only 30 years ago.

After sockets were added to BSD, pipe() was implemented using them. But it
was a slightly different implementation than socketpair().

e.g.
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/sys/uipc_syscalls.c

and the amusing comment at the top of
https://minnie.tuhs.org/cgi-bin/utree.pl?file=4.2BSD/usr/src/sys/sys/uipc_pipe.c

But the socket-backed pipes weren't bidirectional even though they could
have been - see this fix in FreeBSD
https://svnweb.freebsd.org/base/head/sys/kern/uipc_syscalls.c?r1=12843&r2=13146

Which did not last long because socket-backed pipe were soon replaced
with a new (bidirectional) implementation
https://svnweb.freebsd.org/base/head/sys/kern/sys_pipe.c?view=log&log_pagestart=200#rev13675

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Ardnamurchan Point to Cape Wrath: South or southwest 4 or 5, increasing 6 to
gale 8, then veering west later. Rough or very rough, occasionally high in
west. Rain or drizzle, then showers. Moderate or good, occasionally poor at
first.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-28 11:14                             ` Peter Pentchev
@ 2020-03-28 16:03                               ` Steffen Nurpmeso
  0 siblings, 0 replies; 21+ messages in thread
From: Steffen Nurpmeso @ 2020-03-28 16:03 UTC (permalink / raw)
  To: Peter Pentchev; +Cc: The Eunuchs Hysterical Society

Peter Pentchev wrote in
<20200328111428.GA1431416@straylight.m.ringlet.net>:
 |On Sat, Mar 28, 2020 at 01:12:35PM +0200, Peter Pentchev wrote:
 |> On Thu, Mar 26, 2020 at 01:38:17PM +1100, Dave Horsfall wrote:
 |>> On Wed, 25 Mar 2020, Grant Taylor via TUHS wrote:
 |>> 
 |>>> · netcat's STDOUT to grep's STDIN
 |>>> · grep's STDOUT to netcat's STDIN
 |>> 
 |>> Are you trying to set up a loop of processes or something?  I'm \
 |>> not sure if
 |>> that is even possible, although you can't rule out creative uses \
 |>> of dup2()
 |>> etc...
 |> 
 |> This can't really be done with netcat, but it's quite easy to do with
 |> socat; here's an example with a trivial program that reads lines from
 |> its standard input and writes a single line to its standard output:
 |> 
 |>     [roam@straylight ~]$ socat -v tcp4:nimbus.fccf.net:25 exec:./heysmtp.\
 |>     py
  ...

perl(1) has IPC::Open2 for that:

  use IPC::Open2;
  # We use `csop' for hashing
  my $MAILX = 'LC_ALL=C s-nail -#:/';

  sub hash_em{
     die "hash_em: open: $^E"
        unless my $pid = open2 *RFD, *WFD, $MAILX;
     foreach my $e (@ENTS){
        print WFD "csop hash32 $e->{name}\n";
        my $h = <RFD>;
        chomp $h;
        $e->{hash} = $h
     }
     print WFD "x\n";
     waitpid $pid, 0;
  }

  hash_em()

 |...but, of course, this is still not what Derek was talking about
 |earlier - there is no separation of the file descriptors connected to
 |the socket: closing the stdout one would not result in a FIN being sent
 |along the line.

Just wanted to add earlier in the thread that on some systems
shutdown(2) equals close(2).  At least it was like that on Mac OS
X (by then) Snow Leopard.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-28 11:12                           ` Peter Pentchev
@ 2020-03-28 11:14                             ` Peter Pentchev
  2020-03-28 16:03                               ` Steffen Nurpmeso
  0 siblings, 1 reply; 21+ messages in thread
From: Peter Pentchev @ 2020-03-28 11:14 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1606 bytes --]

On Sat, Mar 28, 2020 at 01:12:35PM +0200, Peter Pentchev wrote:
> On Thu, Mar 26, 2020 at 01:38:17PM +1100, Dave Horsfall wrote:
> > On Wed, 25 Mar 2020, Grant Taylor via TUHS wrote:
> > 
> > > · netcat's STDOUT to grep's STDIN
> > > · grep's STDOUT to netcat's STDIN
> > 
> > Are you trying to set up a loop of processes or something?  I'm not sure if
> > that is even possible, although you can't rule out creative uses of dup2()
> > etc...
> 
> This can't really be done with netcat, but it's quite easy to do with
> socat; here's an example with a trivial program that reads lines from
> its standard input and writes a single line to its standard output:
> 
>     [roam@straylight ~]$ socat -v tcp4:nimbus.fccf.net:25 exec:./heysmtp.py
>     > 2020/03/28 13:09:04.005497  length=48 from=0 to=47
>     220 nimbus.fccf.net ESMTP Postfix (Debian/GNU)\r
>     < 2020/03/28 13:09:04.018931  length=6 from=0 to=5
>     QUIT\r
>     > 2020/03/28 13:09:04.035387  length=15 from=48 to=62
>     221 2.0.0 Bye\r
>     [roam@straylight ~]$
> 
> All the output was actually from socat because of the "-v" option
> specified.

...but, of course, this is still not what Derek was talking about
earlier - there is no separation of the file descriptors connected to
the socket: closing the stdout one would not result in a FIN being sent
along the line.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-26  2:38                         ` Dave Horsfall
  2020-03-26  3:08                           ` Rob Pike
  2020-03-26  4:11                           ` Grant Taylor via TUHS
@ 2020-03-28 11:12                           ` Peter Pentchev
  2020-03-28 11:14                             ` Peter Pentchev
  2 siblings, 1 reply; 21+ messages in thread
From: Peter Pentchev @ 2020-03-28 11:12 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

On Thu, Mar 26, 2020 at 01:38:17PM +1100, Dave Horsfall wrote:
> On Wed, 25 Mar 2020, Grant Taylor via TUHS wrote:
> 
> > · netcat's STDOUT to grep's STDIN
> > · grep's STDOUT to netcat's STDIN
> 
> Are you trying to set up a loop of processes or something?  I'm not sure if
> that is even possible, although you can't rule out creative uses of dup2()
> etc...

This can't really be done with netcat, but it's quite easy to do with
socat; here's an example with a trivial program that reads lines from
its standard input and writes a single line to its standard output:

    [roam@straylight ~]$ socat -v tcp4:nimbus.fccf.net:25 exec:./heysmtp.py
    > 2020/03/28 13:09:04.005497  length=48 from=0 to=47
    220 nimbus.fccf.net ESMTP Postfix (Debian/GNU)\r
    < 2020/03/28 13:09:04.018931  length=6 from=0 to=5
    QUIT\r
    > 2020/03/28 13:09:04.035387  length=15 from=48 to=62
    221 2.0.0 Bye\r
    [roam@straylight ~]$

All the output was actually from socat because of the "-v" option
specified.

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-25 23:47                 ` Richard Salz
  2020-03-26  0:11                   ` Grant Taylor via TUHS
@ 2020-03-27 10:51                   ` Derek Fawcus
  1 sibling, 0 replies; 21+ messages in thread
From: Derek Fawcus @ 2020-03-27 10:51 UTC (permalink / raw)
  To: TUHS main list

On Wed, Mar 25, 2020 at 07:47:48PM -0400, Richard Salz wrote:
> > One point being that one could fork/exec a program with those fd's
> > attached to stdin/stdout and it could operate as a normal filter, w/
> 
> Hasn't that pretty much worked ever since BSD wrote inetd?

The socket fd is dup'ed and then applied to stdin & stdout for the child
process.  So if say the child closes stdout, stdin still has the underlying
'file' open in both read and write mode, hence the reader at the far end
will not receive any form of 'close' notification (e.g. EOF on read).

If a socket fd could be split (or partially dup'ed) in to new read-only
and write-only fds, and the original fd then closed, that 'issue' would
go away.  Obviously it hasn't been much of an issue...

DF

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-26  2:38                         ` Dave Horsfall
  2020-03-26  3:08                           ` Rob Pike
@ 2020-03-26  4:11                           ` Grant Taylor via TUHS
  2020-03-28 11:12                           ` Peter Pentchev
  2 siblings, 0 replies; 21+ messages in thread
From: Grant Taylor via TUHS @ 2020-03-26  4:11 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 812 bytes --]

On 3/25/20 8:38 PM, Dave Horsfall wrote:
> Are you trying to set up a loop of processes or something?

Nope.  I'll try another way

           +------------------+   +-------------+
--(TCP)-->+ socket    stdout +---+ stdin       |
           |        nc        |   |        grep |
<--(TCP)--| socket     stdin +---+ stdout      |
           +------------------+   +-------------+

This example is back to the functionality that (x)inetd would provide.

The idea being that grep* would act on the data that came in the TCP 
connection and send the matching lines out the same TCP connection.

*grep is just a hypothetical example here.

> I'm not sure if that is even possible, although you can't rule out 
> creative uses of dup2() etc...

~chuckle~



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-26  3:08                           ` Rob Pike
@ 2020-03-26  3:43                             ` George Michaelson
  0 siblings, 0 replies; 21+ messages in thread
From: George Michaelson @ 2020-03-26  3:43 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

Options negotiation and the URG/PUSH always freaked me out. PAD (the
X.25 equivalent) was a bugger to work with. From memory, the yorkbox
was a forked pair of processes one to read, one to write. it didn't
work very well to be honest. I tended to convert to half-duplex mode
and construct valid lines of input before sending them (which is not
very editor friendly unelss you like Teco, which I didn't since it was
complicated. I stuck to SOS and ed)

Telnet is pretty much just "read and write for networks" except for
the options. Back in the days of the BBN Butterfly, the gethostaddr()
table for de interwebz was a linear list, and UCL was at the back of
the hosts.txt sort and the time it took the daemon to work out who we
were, for a login: prompt, was 1-2 sec close to the 30 second
drop-link-he's-dead-jim timer in getty or whatever it was then. Sad. I
think we made a lot of drama about read and write for networks.
Really, asynchronous communicating processes is a lot of fun. I went
to Milners lectures on the calculus of communicating systems, it was
also too hard, I lost it.

That was also when the real underlying routing (pre BGP) was a
push-down list, which dropped our routes because we were the boring
british side of things and LRU cache said no.  Rebooting the right
fuzzball or BBN box generall brought it back.

X25 was a good fit for PAD. small packets. Enter the ATM cell size
discussion <----here.

On Thu, Mar 26, 2020 at 1:09 PM Rob Pike <robpike@gmail.com> wrote:
>
> I can't find it now, but there's a very short rc script that does a
> modestly realistic telnet client in Plan 9.
>
> But you know, that's not Unix.
>
> -rob
>
> On Thu, Mar 26, 2020 at 1:39 PM Dave Horsfall <dave@horsfall.org> wrote:
> >
> > On Wed, 25 Mar 2020, Grant Taylor via TUHS wrote:
> >
> > > · netcat's STDOUT to grep's STDIN
> > > · grep's STDOUT to netcat's STDIN
> >
> > Are you trying to set up a loop of processes or something?  I'm not sure
> > if that is even possible, although you can't rule out creative uses of
> > dup2() etc...
> >
> > -- Dave

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-26  2:38                         ` Dave Horsfall
@ 2020-03-26  3:08                           ` Rob Pike
  2020-03-26  3:43                             ` George Michaelson
  2020-03-26  4:11                           ` Grant Taylor via TUHS
  2020-03-28 11:12                           ` Peter Pentchev
  2 siblings, 1 reply; 21+ messages in thread
From: Rob Pike @ 2020-03-26  3:08 UTC (permalink / raw)
  To: Dave Horsfall; +Cc: The Eunuchs Hysterical Society

I can't find it now, but there's a very short rc script that does a
modestly realistic telnet client in Plan 9.

But you know, that's not Unix.

-rob

On Thu, Mar 26, 2020 at 1:39 PM Dave Horsfall <dave@horsfall.org> wrote:
>
> On Wed, 25 Mar 2020, Grant Taylor via TUHS wrote:
>
> > · netcat's STDOUT to grep's STDIN
> > · grep's STDOUT to netcat's STDIN
>
> Are you trying to set up a loop of processes or something?  I'm not sure
> if that is even possible, although you can't rule out creative uses of
> dup2() etc...
>
> -- Dave

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-26  1:08                       ` Grant Taylor via TUHS
@ 2020-03-26  2:38                         ` Dave Horsfall
  2020-03-26  3:08                           ` Rob Pike
                                             ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Dave Horsfall @ 2020-03-26  2:38 UTC (permalink / raw)
  To: The Eunuchs Hysterical Society

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

On Wed, 25 Mar 2020, Grant Taylor via TUHS wrote:

> · netcat's STDOUT to grep's STDIN
> · grep's STDOUT to netcat's STDIN

Are you trying to set up a loop of processes or something?  I'm not sure 
if that is even possible, although you can't rule out creative uses of 
dup2() etc...

-- Dave

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-26  0:18                     ` Richard Salz
  2020-03-26  1:08                       ` Grant Taylor via TUHS
@ 2020-03-26  1:20                       ` Tony Finch
  1 sibling, 0 replies; 21+ messages in thread
From: Tony Finch @ 2020-03-26  1:20 UTC (permalink / raw)
  To: Richard Salz; +Cc: TUHS main list, Grant Taylor

So I fooled around making an HTTP request from bash...

	(printf 'HEAD / HTTP/1.0\r\nHost: dotat.at\r\n\r\n'; cat 1>&2) \
		0<>/dev/tcp/dotat.at/http 1>&0

And I wondered if it would work with ksh too. It does, but there is weirdness.

Bash's <> operator follows POSIX, so in my one-liner the 0 is redundant.

https://pubs.opengroup.org/onlinepubs/007908799/xcu/chap2.html#tag_001_007_007

However when I look at a ksh man page I find it says

https://github.com/att/ast/blob/master/src/cmd/ksh93/sh.1#L3458

    <>word    Open file word for reading and writing as standard output.

I thought POSIX got features like this from ksh so I'm curious that a
weird little incompatibilty like this has crept in.

(The copy of ksh.1 I have from the CSRG archives lacks <> so I guess that
version was ksh88?)

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Sole: Northerly 6 or 7 at first in west, otherwise easterly or northeasterly 5
or 6. Moderate or rough, occasionally very rough in west. Showers in west.
Good.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-26  0:18                     ` Richard Salz
@ 2020-03-26  1:08                       ` Grant Taylor via TUHS
  2020-03-26  2:38                         ` Dave Horsfall
  2020-03-26  1:20                       ` Tony Finch
  1 sibling, 1 reply; 21+ messages in thread
From: Grant Taylor via TUHS @ 2020-03-26  1:08 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 598 bytes --]

On 3/25/20 6:18 PM, Richard Salz wrote:
> netcat ?

Sure.  netcat, et al., do make it possible to initiate outbound connections.

Maybe it's the fog in my brain at the moment, but I don't see how to 
connect netcat's STDIO to another process cleanly.  Maybe I need to 
think more about the following hypothetical example:

  · netcat's STDOUT to grep's STDIN
  · grep's STDOUT to netcat's STDIN

Where netcat listens on a port and grep does some useful work over the 
stream coming through netcat.

Thank you for prodding my brain Richard.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-26  0:11                   ` Grant Taylor via TUHS
@ 2020-03-26  0:18                     ` Richard Salz
  2020-03-26  1:08                       ` Grant Taylor via TUHS
  2020-03-26  1:20                       ` Tony Finch
  0 siblings, 2 replies; 21+ messages in thread
From: Richard Salz @ 2020-03-26  0:18 UTC (permalink / raw)
  To: Grant Taylor; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 191 bytes --]

> (x)inetd does allow for the incoming connections (and outgoing replies).
>   But I'm not aware of (x)inetd altering anything for programs
> initiating new outbound connections.
>

netcat ?

[-- Attachment #2: Type: text/html, Size: 437 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-25 23:47                 ` Richard Salz
@ 2020-03-26  0:11                   ` Grant Taylor via TUHS
  2020-03-26  0:18                     ` Richard Salz
  2020-03-27 10:51                   ` Derek Fawcus
  1 sibling, 1 reply; 21+ messages in thread
From: Grant Taylor via TUHS @ 2020-03-26  0:11 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 323 bytes --]

On 3/25/20 5:47 PM, Richard Salz wrote:
> Hasn't that pretty much worked ever since BSD wrote inetd?

(x)inetd does allow for the incoming connections (and outgoing replies). 
  But I'm not aware of (x)inetd altering anything for programs 
initiating new outbound connections.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-25 23:25               ` Grant Taylor via TUHS
@ 2020-03-25 23:47                 ` Richard Salz
  2020-03-26  0:11                   ` Grant Taylor via TUHS
  2020-03-27 10:51                   ` Derek Fawcus
  0 siblings, 2 replies; 21+ messages in thread
From: Richard Salz @ 2020-03-25 23:47 UTC (permalink / raw)
  To: Grant Taylor; +Cc: TUHS main list

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

> One point being that one could fork/exec a program with those fd's
> attached to stdin/stdout and it could operate as a normal filter, w/

Hasn't that pretty much worked ever since BSD wrote inetd?

[-- Attachment #2: Type: text/html, Size: 288 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-24  9:47             ` Derek Fawcus
@ 2020-03-25 23:25               ` Grant Taylor via TUHS
  2020-03-25 23:47                 ` Richard Salz
  0 siblings, 1 reply; 21+ messages in thread
From: Grant Taylor via TUHS @ 2020-03-25 23:25 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 646 bytes --]

On 3/24/20 3:47 AM, Derek Fawcus wrote:> One point being that one could 
fork/exec a program with those fd's
> attached to stdin/stdout and it could operate as a normal filter, w/o
> having to understand it was using a socket.

Hum.  This is quite intriguing.

Now I'm wondering what sort of mistchif I could get up to doing things 
with Bash (et al.) supporting /dev/tcp pseudo files.

> (i.e. closing stdout [hence triggering a FIN], while still reading
> from stdin)

I like it.

> Plus various other games achievable by replumbing fd's.

Ya.  There's quite a bit to think about here.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-23  8:49           ` Peter Pentchev
@ 2020-03-24  9:47             ` Derek Fawcus
  2020-03-25 23:25               ` Grant Taylor via TUHS
  0 siblings, 1 reply; 21+ messages in thread
From: Derek Fawcus @ 2020-03-24  9:47 UTC (permalink / raw)
  To: tuhs

On Mon, Mar 23, 2020 at 10:49:43AM +0200, Peter Pentchev wrote:
> On Mon, Mar 09, 2020 at 05:22:57PM -0600, Grant Taylor via TUHS wrote:
> > On 3/8/20 9:13 AM, Derek Fawcus wrote:
> > > Now what would have been useful is a way to have distinct fd's for the
> > > local read and write end of (e.g.) a TCP socket - such that one
> > > direction could be closed w/o closing the other.
> > 
> > I believe that this can be done, now.  At least I've read that it's possible
> > for one end to close (FIN) a TCP connection without the other end also
> > closing.  Thus you end up with the one-way data flow that is still ACKed the
> > way that TCP does.
> 
> Yep, in the next sentence Derek mentioned "dispense with shutdown",
> meaning the shutdown(2) syscall that does exactly that. What he meant
> was, wouldn't it be nice to be able to do that with close(2) instead?

Quite.

One point being that one could fork/exec a program with those fd's attached
to stdin/stdout and it could operate as a normal filter, w/o having to
understand it was using a socket.

(i.e. closing stdout [hence triggering a FIN], while still reading from stdin)

Plus various other games achievable by replumbing fd's.

DF

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-09 23:22         ` Grant Taylor via TUHS
  2020-03-09 23:44           ` Larry McVoy
@ 2020-03-23  8:49           ` Peter Pentchev
  2020-03-24  9:47             ` Derek Fawcus
  1 sibling, 1 reply; 21+ messages in thread
From: Peter Pentchev @ 2020-03-23  8:49 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 1016 bytes --]

On Mon, Mar 09, 2020 at 05:22:57PM -0600, Grant Taylor via TUHS wrote:
> On 3/8/20 9:13 AM, Derek Fawcus wrote:
> > Now what would have been useful is a way to have distinct fd's for the
> > local read and write end of (e.g.) a TCP socket - such that one
> > direction could be closed w/o closing the other.
> 
> I believe that this can be done, now.  At least I've read that it's possible
> for one end to close (FIN) a TCP connection without the other end also
> closing.  Thus you end up with the one-way data flow that is still ACKed the
> way that TCP does.

Yep, in the next sentence Derek mentioned "dispense with shutdown",
meaning the shutdown(2) syscall that does exactly that. What he meant
was, wouldn't it be nice to be able to do that with close(2) instead?

G'luck,
Peter

-- 
Peter Pentchev  roam@{ringlet.net,debian.org,FreeBSD.org} pp@storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-09 23:22         ` Grant Taylor via TUHS
@ 2020-03-09 23:44           ` Larry McVoy
  2020-03-23  8:49           ` Peter Pentchev
  1 sibling, 0 replies; 21+ messages in thread
From: Larry McVoy @ 2020-03-09 23:44 UTC (permalink / raw)
  To: Grant Taylor; +Cc: tuhs

On Mon, Mar 09, 2020 at 05:22:57PM -0600, Grant Taylor via TUHS wrote:
> On 3/8/20 9:13 AM, Derek Fawcus wrote:
> >Now what would have been useful is a way to have distinct fd's for the
> >local read and write end of (e.g.) a TCP socket - such that one direction
> >could be closed w/o closing the other.
> 
> I believe that this can be done, now.  At least I've read that it's possible
> for one end to close (FIN) a TCP connection without the other end also
> closing.  Thus you end up with the one-way data flow that is still ACKed the
> way that TCP does.

Yes, it can be tricky to do it portably but I have.

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [TUHS] sockets (was Re: First appearance of named pipes)
  2020-03-08 15:13       ` [TUHS] sockets (was Re: First appearance of named pipes) Derek Fawcus
@ 2020-03-09 23:22         ` Grant Taylor via TUHS
  2020-03-09 23:44           ` Larry McVoy
  2020-03-23  8:49           ` Peter Pentchev
  0 siblings, 2 replies; 21+ messages in thread
From: Grant Taylor via TUHS @ 2020-03-09 23:22 UTC (permalink / raw)
  To: tuhs

[-- Attachment #1: Type: text/plain, Size: 528 bytes --]

On 3/8/20 9:13 AM, Derek Fawcus wrote:
> Now what would have been useful is a way to have distinct fd's for 
> the local read and write end of (e.g.) a TCP socket - such that 
> one direction could be closed w/o closing the other.

I believe that this can be done, now.  At least I've read that it's 
possible for one end to close (FIN) a TCP connection without the other 
end also closing.  Thus you end up with the one-way data flow that is 
still ACKed the way that TCP does.



-- 
Grant. . . .
unix || die


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4013 bytes --]

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [TUHS] sockets (was Re:  First appearance of named pipes)
  2020-03-08  2:36     ` Rob Pike
@ 2020-03-08 15:13       ` Derek Fawcus
  2020-03-09 23:22         ` Grant Taylor via TUHS
  0 siblings, 1 reply; 21+ messages in thread
From: Derek Fawcus @ 2020-03-08 15:13 UTC (permalink / raw)
  To: TUHS main list

On Sun, Mar 08, 2020 at 01:36:14PM +1100, Rob Pike wrote:
> Always bemused me that to get a named local I/O connection one ended
> up with "Unix domain (what does that even mean?) sockets" rather than
> named pipes,

Yeah - I always found that a bit weird, having to use socketpair()
to get a bidirectional "pipe".

> I've been told, but haven't confirmed, that
> early sockets didn't even support read and write. They still don't
> support open and close, and never will.

Err - granted on the open; but if my memory serves, close() has been
supported on them ever since I started using them ('87).  Otherwise
the normal fork/dup/close/exec pattern for child processes would not
work.

Now what would have been useful is a way to have distinct fd's for
the local read and write end of (e.g.) a TCP socket - such that one
direction could be closed w/o closing the other.  Or maybe some
fcntl() to dup the bidirectional fd in to a pair of unidirectional
fds.  That way one could dispense with shutdown for closing one
direction, making children and fd passed programs socket agnostic.

DF

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, back to index

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-08 23:09 [TUHS] sockets (was Re: First appearance of named pipes) Norman Wilson
2020-03-09 17:09 ` Tony Finch
  -- strict thread matches above, loose matches on Subject: below --
2020-03-06 22:44 [TUHS] First appearance of named pipes Noel Chiappa
2020-03-07 12:17 ` Paul Ruizendaal
2020-03-07 16:39   ` Derek Fawcus
2020-03-08  2:36     ` Rob Pike
2020-03-08 15:13       ` [TUHS] sockets (was Re: First appearance of named pipes) Derek Fawcus
2020-03-09 23:22         ` Grant Taylor via TUHS
2020-03-09 23:44           ` Larry McVoy
2020-03-23  8:49           ` Peter Pentchev
2020-03-24  9:47             ` Derek Fawcus
2020-03-25 23:25               ` Grant Taylor via TUHS
2020-03-25 23:47                 ` Richard Salz
2020-03-26  0:11                   ` Grant Taylor via TUHS
2020-03-26  0:18                     ` Richard Salz
2020-03-26  1:08                       ` Grant Taylor via TUHS
2020-03-26  2:38                         ` Dave Horsfall
2020-03-26  3:08                           ` Rob Pike
2020-03-26  3:43                             ` George Michaelson
2020-03-26  4:11                           ` Grant Taylor via TUHS
2020-03-28 11:12                           ` Peter Pentchev
2020-03-28 11:14                             ` Peter Pentchev
2020-03-28 16:03                               ` Steffen Nurpmeso
2020-03-26  1:20                       ` Tony Finch
2020-03-27 10:51                   ` Derek Fawcus

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git