I have faint memories on a communication tool that I think have used
on a DEC VAX under VMS in the 1980's. Unlike the common modern tools
like chat systems or SMS exchange on mobile phones it didn't operate
line-wise or message-wise, but rather (synchronous) character-wise.
And I think it was a tool usable only to connect people on the same
system (but I'm not sure about that). I thought its name would have
been 'talk' but searching the web led me to a document "VMS Phone
Utility Manual"[*] which describes such a tool (it's actually called
'phone') and it seems to be what I still remember about the tool I'm
looking for.

Some characteristics I'd prefer - not all supported by the 'phone'
utility - are that it's
* text-oriented (preferably with Unicode support), fast (no GUI)
* instantly/synchronously exchanging any typed characters
* optionally: switching modes (instant/character-wise, line-wise)
* more than two persons can communicate
* works across distributed [Unix-]systems

Is there such a tool (free of charge and open source) available for
Linux? (Or something that comes close?)

Janis

[*]
http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/vax/vms/5.0/AA-LA08A-TE_VMS_5.0_Phone_Utility_Manual_198804.pdf

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> I have faint memories on a communication tool that I think have used
> on a DEC VAX under VMS in the 1980's. Unlike the common modern tools
> like chat systems or SMS exchange on mobile phones it didn't operate
> line-wise or message-wise, but rather (synchronous) character-wise.
> And I think it was a tool usable only to connect people on the same
> system (but I'm not sure about that). I thought its name would have
> been 'talk' but searching the web led me to a document "VMS Phone
> Utility Manual"[*] which describes such a tool (it's actually called
> 'phone') and it seems to be what I still remember about the tool I'm
> looking for.
>
> Some characteristics I'd prefer - not all supported by the 'phone'
> utility - are that it's
> * text-oriented (preferably with Unicode support), fast (no GUI)
> * instantly/synchronously exchanging any typed characters
> * optionally: switching modes (instant/character-wise, line-wise)
> * more than two persons can communicate
> * works across distributed [Unix-]systems
>
> Is there such a tool (free of charge and open source) available for
> Linux? (Or something that comes close?)

ytalk would fit the requirements, I think, but it’s been abandonware
for the last couple of decades.

--
https://www.greenend.org.uk/rjk/

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
<snip>
>
> Some characteristics I'd prefer - not all supported by the 'phone'
> utility - are that it's
> * text-oriented (preferably with Unicode support), fast (no GUI)
> * instantly/synchronously exchanging any typed characters
> * optionally: switching modes (instant/character-wise, line-wise)
> * more than two persons can communicate
> * works across distributed [Unix-]systems
>
> Is there such a tool (free of charge and open source) available for
> Linux? (Or something that comes close?)
>
Slackware comes with a utility called "talk", it is
disabled by default. It sounds like what you are
looking for. It allows 2 people to 'text' each other.

https://www.slackbook.org/html/basic-network-commands-talk.html

--
[t]csh(1) - "An elegant shell, for a more... civilized age."
- Paraphrasing Star Wars

On Sun, 8 Dec 2024 14:15:48 -0000 (UTC)
John McCue <jmccue@whitedwf.jmcunx.com> wibbled:
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
><snip>
>>
>> Some characteristics I'd prefer - not all supported by the 'phone'
>> utility - are that it's
>> * text-oriented (preferably with Unicode support), fast (no GUI)
>> * instantly/synchronously exchanging any typed characters
>> * optionally: switching modes (instant/character-wise, line-wise)
>> * more than two persons can communicate
>> * works across distributed [Unix-]systems
>>
>> Is there such a tool (free of charge and open source) available for
>> Linux? (Or something that comes close?)
>>
>Slackware comes with a utility called "talk", it is
>disabled by default. It sounds like what you are
>looking for. It allows 2 people to 'text' each other.
>
>https://www.slackbook.org/html/basic-network-commands-talk.html

talk is an age old unix util that allows people on the same machine to chat.
Even MacOS has it installed.

On 08.12.2024 17:25, Muttley@DastardlyHQ.org wrote:
> On Sun, 8 Dec 2024 14:15:48 -0000 (UTC)
> John McCue <jmccue@whitedwf.jmcunx.com> wibbled:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>> <snip>
>>>
>>> Some characteristics I'd prefer - not all supported by the 'phone'
>>> utility - are that it's
>>> * text-oriented (preferably with Unicode support), fast (no GUI)
>>> * instantly/synchronously exchanging any typed characters
>>> * optionally: switching modes (instant/character-wise, line-wise)
>>> * more than two persons can communicate
>>> * works across distributed [Unix-]systems
>>>
>>> Is there such a tool (free of charge and open source) available for
>>> Linux? (Or something that comes close?)
>>>
>> Slackware comes with a utility called "talk", it is
>> disabled by default. It sounds like what you are
>> looking for. It allows 2 people to 'text' each other.
>>
>> https://www.slackbook.org/html/basic-network-commands-talk.html
>
> talk is an age old unix util that allows people on the same machine to chat.
> Even MacOS has it installed.

As said, I think the historic DEC/VAX tool worked (also) only
locally; you had to log into the same VMS-system to communicate.

I'm actually looking for a tool that works across distributed
[Unix-]systems.

I'll look into the tools suggested so far what they provide.

Janis

In article <wwvmsh648qc.fsf@LkoBDZeT.terraraq.uk>,
Richard Kettlewell <invalid@invalid.invalid> wrote:
....
>ytalk would fit the requirements, I think, but it’s been abandonware
>for the last couple of decades.

I used ytalk a lot back in the day; it was very cool.

https://ytalk.ourproject.org
--
When I was growing up we called them "retards", but that's not PC anymore.
Now, we just call them "Trump Voters".

The question is, of course, how much longer it will be until that term is also un-PC.

In article <vj4jmv$3tpsd$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>On 08.12.2024 17:25, Muttley@DastardlyHQ.org wrote:
>> On Sun, 8 Dec 2024 14:15:48 -0000 (UTC)
>> John McCue <jmccue@whitedwf.jmcunx.com> wibbled:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> <snip>
>>>>
>>>> Some characteristics I'd prefer - not all supported by the 'phone'
>>>> utility - are that it's
>>>> * text-oriented (preferably with Unicode support), fast (no GUI)
>>>> * instantly/synchronously exchanging any typed characters
>>>> * optionally: switching modes (instant/character-wise, line-wise)
>>>> * more than two persons can communicate
>>>> * works across distributed [Unix-]systems
>>>>
>>>> Is there such a tool (free of charge and open source) available for
>>>> Linux? (Or something that comes close?)
>>>>
>>> Slackware comes with a utility called "talk", it is
>>> disabled by default. It sounds like what you are
>>> looking for. It allows 2 people to 'text' each other.
>>>
>>> https://www.slackbook.org/html/basic-network-commands-talk.html
>>
>> talk is an age old unix util that allows people on the same machine to chat.
>> Even MacOS has it installed.
>
>As said, I think the historic DEC/VAX tool worked (also) only
>locally; you had to log into the same VMS-system to communicate.
>
>I'm actually looking for a tool that works across distributed
>[Unix-]systems.
>
>I'll look into the tools suggested so far what they provide.

`phone` worked across DECnet, but I don't believe it was ever
extended to work across TCP/IP.

`talk` will work between machines, over TCP/IP, but the way it
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
building a proxy for it, but to my knowledge no one did so.

- Dan C.

On Sun, 8 Dec 2024 18:06:38 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wibbled:
>On 08.12.2024 17:25, Muttley@DastardlyHQ.org wrote:
>> On Sun, 8 Dec 2024 14:15:48 -0000 (UTC)
>> John McCue <jmccue@whitedwf.jmcunx.com> wibbled:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> <snip>
>> talk is an age old unix util that allows people on the same machine to chat.
>> Even MacOS has it installed.
>
>As said, I think the historic DEC/VAX tool worked (also) only
>locally; you had to log into the same VMS-system to communicate.
>
>I'm actually looking for a tool that works across distributed
>[Unix-]systems.

Set up an IRC server or there's plenty of telnet based talker programs.

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. 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.

On 09.12.2024 09:23, Muttley@DastardlyHQ.org wrote:
> On Sun, 8 Dec 2024 18:06:38 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wibbled:
>> On 08.12.2024 17:25, Muttley@DastardlyHQ.org wrote:
>>> On Sun, 8 Dec 2024 14:15:48 -0000 (UTC)
>>> John McCue <jmccue@whitedwf.jmcunx.com> wibbled:
>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>> <snip>
>>> talk is an age old unix util that allows people on the same machine to chat.
>>> Even MacOS has it installed.
>>
>> As said, I think the historic DEC/VAX tool worked (also) only
>> locally; you had to log into the same VMS-system to communicate.
>>
>> I'm actually looking for a tool that works across distributed
>> [Unix-]systems.
>
> Set up an IRC server or there's plenty of telnet based talker programs.

WRT IRC you may have missed the requirements in my OP; one was:
* instantly/synchronously exchanging any typed characters

I haven't heard of "telnet based talker programs"; care to be
more concrete?

Janis

On Mon, 9 Dec 2024 09:37:54 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wibbled:
>On 09.12.2024 09:23, Muttley@DastardlyHQ.org wrote:
>> On Sun, 8 Dec 2024 18:06:38 +0100
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wibbled:
>>> On 08.12.2024 17:25, Muttley@DastardlyHQ.org wrote:
>>>> On Sun, 8 Dec 2024 14:15:48 -0000 (UTC)
>>>> John McCue <jmccue@whitedwf.jmcunx.com> wibbled:
>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>>>> <snip>
>>>> talk is an age old unix util that allows people on the same machine to
>chat.
>>>> Even MacOS has it installed.
>>>
>>> As said, I think the historic DEC/VAX tool worked (also) only
>>> locally; you had to log into the same VMS-system to communicate.
>>>
>>> I'm actually looking for a tool that works across distributed
>>> [Unix-]systems.
>>
>> Set up an IRC server or there's plenty of telnet based talker programs.
>
>WRT IRC you may have missed the requirements in my OP; one was:
> * instantly/synchronously exchanging any typed characters

I suggest you consult harry potter for that then. In the real world server
software is required whether its IRC, Teams, Slack etc.

>I haven't heard of "telnet based talker programs"; care to be
>more concrete?

Talk servers that allow you to telnet to them to chat to other people.
Clearly you have done zero research on this.

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.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 08.12.2024 17:25, Muttley@DastardlyHQ.org wrote:
>> On Sun, 8 Dec 2024 14:15:48 -0000 (UTC)
>> John McCue <jmccue@whitedwf.jmcunx.com> wibbled:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>> <snip>
>>>>
>>>> Some characteristics I'd prefer - not all supported by the 'phone'
>>>> utility - are that it's
>>>> * text-oriented (preferably with Unicode support), fast (no GUI)
>>>> * instantly/synchronously exchanging any typed characters
>>>> * optionally: switching modes (instant/character-wise, line-wise)
>>>> * more than two persons can communicate
>>>> * works across distributed [Unix-]systems
>>>>
>>>> Is there such a tool (free of charge and open source) available for
>>>> Linux? (Or something that comes close?)
>>>>
>>> Slackware comes with a utility called "talk", it is
>>> disabled by default. It sounds like what you are
>>> looking for. It allows 2 people to 'text' each other.
>>>
>>> https://www.slackbook.org/html/basic-network-commands-talk.html
>>
>> talk is an age old unix util that allows people on the same machine to chat.
>> Even MacOS has it installed.
>
>As said, I think the historic DEC/VAX tool worked (also) only
>locally; you had to log into the same VMS-system to communicate.

TSS/8 (for the PDP-8) had a talk command, as did the HP-3000. I used
both extensively in the 1970s to communicate with students at
other area high schools.

Muttley wrote:

> talk is an age old unix util that allows people on the same machine to chat.
> Even MacOS has it installed.

"Even" MacOS? It's required for UNIX® conformance - if MacOS didn't
have talk, it wouldn't be able to be certified as UNIX.

--
Geoff Clare <netnews@gclare.org.uk>

In article <at8j2l-elf.ln1@ID-313840.user.individual.net>,
Geoff Clare <netnews@gclare.org.uk> wrote:
>Muttley wrote:
>
>> talk is an age old unix util that allows people on the same machine to chat.
>> Even MacOS has it installed.
>
>"Even" MacOS? It's required for UNIX® conformance - if MacOS didn't
>have talk, it wouldn't be able to be certified as UNIX.

What a meaningless comment.

--
In American politics, there are two things you just don't f*ck with:

1) Goldman Sachs
2) The military/industrial complex

In article <vj6c8m$be0i$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
....
>talk is an age old unix util that allows people on the same machine to chat.
>Even MacOS has it installed.

You may (and I stress the word "may") be confusing "talk" with "write".

"write" is old, old Unix and only works on the same machine.
"talk" is multi-machine (via the network).

--
I'll give him credit for one thing: He is (& will be) the most quotable President
ever. Books have been written about (GW) Bushisms, but Dubya's got nothing on Trump.

Tremendously wet - from the standpoint of water.

Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
> Muttley wrote:
>
>> talk is an age old unix util that allows people on the same machine to chat.
>> Even MacOS has it installed.
>
> "Even" MacOS? It's required for UNIX® conformance - if MacOS didn't
> have talk, it wouldn't be able to be certified as UNIX.

I was surprised by that. Do you happen to know what motivated its
inclusion? While this thread does show that there’s some demand for the
application, it seems a surprising thing to include in a OS specification.

--
https://www.greenend.org.uk/rjk/

Richard Kettlewell wrote:

> Geoff Clare <geoff@clare.See-My-Signature.invalid> writes:
>> Muttley wrote:
>>
>>> talk is an age old unix util that allows people on the same machine to chat.
>>> Even MacOS has it installed.
>>
>> "Even" MacOS? It's required for UNIX® conformance - if MacOS didn't
>> have talk, it wouldn't be able to be certified as UNIX.
>
> I was surprised by that. Do you happen to know what motivated its
> inclusion?

The original decision to include talk goes back to POSIX.2-1992, where
the rationale begins with this paragraph:

The write utility was included in POSIX.2 since it can be
implemented on all terminal types. The talk utility, which cannot
be implemented on certain terminals, was considered to be a
‘‘better’’ communications interface. Both of these programs are
in widespread use on historical implementations. Therefore, both
utilities have been specified.

> While this thread does show that there’s some demand for the
> application, it seems a surprising thing to include in a OS specification.

It's part of the "User Portability Utilities" option (which includes
things like ex and vi), so it's optional for POSIX conformance but
that option is mandated for UNIX conformance.

--
Geoff Clare <netnews@gclare.org.uk>

On 09.12.2024 10:11, Muttley@DastardlyHQ.org wrote:
> On Mon, 9 Dec 2024 09:37:54 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wibbled:
>> On 09.12.2024 09:23, Muttley@DastardlyHQ.org wrote:
>>> On Sun, 8 Dec 2024 18:06:38 +0100
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wibbled:
>>>>
>>>> I'm actually looking for a tool that works across distributed
>>>> [Unix-]systems.
>>>
>>> Set up an IRC server or there's plenty of telnet based talker programs.
>>
>> WRT IRC you may have missed the requirements in my OP; one was:
>> * instantly/synchronously exchanging any typed characters
>
> I suggest you consult harry potter for that then.

(I suppose here you just want play the troll.) But how does that
comment address in any way my question? - I don't know anything
about "Harry Potter", BTW; if you want to discuss that better
open an own post in an appropriate newsgroup.

> In the real world server
> software is required whether its IRC, Teams, Slack etc.

(I think this statement is not true in a [software-]world where
peer-to-peer software designs are not uncommon. Just aside.)

But I'm not objecting to any solution that involves a server; as
far as my requirements (see above) are fulfilled.

>
>> I haven't heard of "telnet based talker programs"; care to be
>> more concrete?
>
> Talk servers that allow you to telnet to them to chat to other people.

I asked for more concrete hints. - But never mind; you anyway seem
to just prefer trolling instead of providing useful information.

> Clearly you have done zero research on this.

Not true. The search term "telnet based talker programs" that you
emitted did not not provide sensible information to my requirements.

If you know something concrete on my topic - which I now doubt - or
are just not interested to help with your purportedly "knowledge"
it's best if you don't misuse my thread and use another place for
your trolling. - Thanks.

Janis

Geoff Clare , dans le message
<at8j2l-elf.ln1@ID-313840.user.individual.net>, a écrit :
> "Even" MacOS? It's required for UNIX® conformance - if MacOS didn't
> have talk, it wouldn't be able to be certified as UNIX.

Or they would have paid a little more money and that requirement would have
been discarded. Whichever is the least expensive: implement a stub command
or get rid of the requirement.

On 08.12.2024 14:14, Richard Kettlewell wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> I have faint memories on a communication tool that I think have used
>> on a DEC VAX under VMS in the 1980's. Unlike the common modern tools
>> like chat systems or SMS exchange on mobile phones it didn't operate
>> line-wise or message-wise, but rather (synchronous) character-wise.
>> And I think it was a tool usable only to connect people on the same
>> system (but I'm not sure about that). I thought its name would have
>> been 'talk' but searching the web led me to a document "VMS Phone
>> Utility Manual"[*] which describes such a tool (it's actually called
>> 'phone') and it seems to be what I still remember about the tool I'm
>> looking for.
>>
>> Some characteristics I'd prefer - not all supported by the 'phone'
>> utility - are that it's
>> * text-oriented (preferably with Unicode support), fast (no GUI)
>> * instantly/synchronously exchanging any typed characters
>> * optionally: switching modes (instant/character-wise, line-wise)
>> * more than two persons can communicate
>> * works across distributed [Unix-]systems
>>
>> Is there such a tool (free of charge and open source) available for
>> Linux? (Or something that comes close?)
>
> ytalk would fit the requirements, I think, but it’s been abandonware
> for the last couple of decades.

I generally don't mind using "abandonware"; if it's a stable version
that has the well thought through features implemented without errors,
and that is focusing on its main task that it's designed for - that's
perfect. - The opposite sort of tools, tools that suffer from feature
creep, have their own principal issues.

From elsewhere I was pointed to 'utalk' (labeled 1.0.1.beta-7); which
also doesn't look like a "fresh" software. But anyway; I'll try that.

Janis

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.

In article <vj7839$g95f$1@dont-email.me>, <Muttley@DastardlyHQ.org> wrote:
>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.

It wasn't the best protocol, but the complexity of setting up
the connection was not why.

- Dan C.

On Mon, 9 Dec 2024 16:21:11 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wibbled:
>On 09.12.2024 10:11, Muttley@DastardlyHQ.org wrote:
>comment address in any way my question? - I don't know anything
>about "Harry Potter", BTW; if you want to discuss that better
>open an own post in an appropriate newsgroup.

It was sarcasm ffs.

>> In the real world server
>> software is required whether its IRC, Teams, Slack etc.
>
>(I think this statement is not true in a [software-]world where
>peer-to-peer software designs are not uncommon. Just aside.)

Even peer to peer requires some program listening out for connections - ie
acting as a server.

>> Clearly you have done zero research on this.
>
>Not true. The search term "telnet based talker programs" that you
>emitted did not not provide sensible information to my requirements.

https://en.wikipedia.org/wiki/Talker

>If you know something concrete on my topic - which I now doubt - or

Doubt away. I wrote a talk server, they're not complicated to implement.

Muttley@DastardlyHQ.org, dans le message <vj7839$g95f$1@dont-email.me>,
a écrit :
> What an idiotically complicated way to set up a simple TCP connection.

What an obnoxious way to say that you did not understand the problem this
protocol is trying to solve.