Path: ...!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail
From: cross@spitfire.i.gajendra.net (Dan Cross)
Newsgroups: comp.unix.programmer
Subject: Re: Text based synchronous communication tool for Linux?
Date: Mon, 9 Dec 2024 12:49:21 -0000 (UTC)
Organization: PANIX Public Access Internet and UNIX, NYC
Message-ID: <vj6p0h$j5l$1@reader2.panix.com>
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>
Injection-Date: Mon, 9 Dec 2024 12:49:21 -0000 (UTC)
Injection-Info: reader2.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80";
	logging-data="19637"; mail-complaints-to="abuse@panix.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: cross@spitfire.i.gajendra.net (Dan Cross)
Bytes: 2772
Lines: 44

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.

	- Dan C.