Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Muttley@DastardlyHQ.org
Newsgroups: comp.unix.programmer
Subject: Re: Text based synchronous communication tool for Linux?
Date: Mon, 9 Dec 2024 17:06:49 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <vj7839$g95f$1@dont-email.me>
References: <vj44hq$3q2ag$1@dont-email.me> <vj4jmv$3tpsd$1@dont-email.me> <vj4ovj$jv8$1@reader2.panix.com> <vj69hi$asvu$1@dont-email.me> <vj6p0h$j5l$1@reader2.panix.com>
Injection-Date: Mon, 09 Dec 2024 18:06:49 +0100 (CET)
Injection-Info: dont-email.me; posting-host="ee2dde97c7379603ae193d5541e2f96c";
	logging-data="533679"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19DFbziyjx/8V3P53YyVp7r"
Cancel-Lock: sha1:W87i19Zo54lDxnMBDSsVId+0mfk=
Bytes: 2993

On Mon, 9 Dec 2024 12:49:21 -0000 (UTC)
cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>In article <vj69hi$asvu$1@dont-email.me>,  <Muttley@DastardlyHQ.org> wrote:
>>On Sun, 8 Dec 2024 18:36:35 -0000 (UTC)
>>cross@spitfire.i.gajendra.net (Dan Cross) wibbled:
>>>works is brittle and doesn't work well over the modern Internet.
>>>In particular, it is de-facto limited to IPv4 and doesn't
>>>play well with firewalls: it involves sending the contents of a
>>>`sockaddr_in` across the network, and using that to set up a
>>>(direct) TCP connection between processes.  One could imagine
>>
>>Huh? I don't get how that works.
>
>Yes.
>
>>You need a connection in the first place to
>>send anything unless you use a broadcast UDP address. You can't just 
>>automagically set up a connection without the OS network layer playing its 
>>part.
>
>A `sockaddr_in` is just a data structure that names a socket
>address.  For the Internet family, it's just got a few things in
>it: an address, a port number, a family type, and length.
>That's basically it.
>
>The walk `talk` works, the client sets up a TCP listening
>socket, and then sends the address for that to the `talk` daemon
>both locally and at the distant end; the talk daemon at the
>distant end then alerts the destired user that someone wants to
>talk to them.
>
>Assuming that person wants to respond, _they_ invoke their
>talk client, which talks to the local talk daemon, sees the
>pending request, retrieves the socket address structure, and
>uses it to connect to the originating user's talk client's
>TCP listening socket.
>
>The connection to the talk daemon isn't connection oriented
>at all; it's done via a UDP packet.  That is, the talk client
>creates a listening TCP socket, takes the (binary) address
>of the listening socket, embeds that address in a UDP packet,
>sends that over the network, and on the distant end that
>informatio is used to create a (TCP) connection back to the
>origin.

What an idiotically complicated way to set up a simple TCP connection.