i'm having trouble with talk too, and i think it's because of the
outdated (IMO) way user software has to figure out its own IP address.

from the experimenting i've done, the talk daemons take an address in
the talk command data as the client UDP socket, not the address from
recvfrom.  so the client has to figure out an address the remote daemon
can use to answer the commands.  the usual way this is done is a call
to gethostname and then gethostbyname.  this basically assumes the
machine has a single IP.

isn't it possible for a machine to have several network interfaces,
all with different IP for it?  what if i were on a LAN with IP number A,
and dialled up a SLIP from my provider that gave me IP number B.
if i wanted to fill in this address data, wouldn't i have to give A
to machines on my LAN, 127.0.0.1 to myself, and B to the rest of the
world?

even if the talk daemons smartened up and used the recvfrom address
(anyone know why they don't?), they'd still have to make up an address
for the TCP service talk uses.  and isn't this also a problem for things
like IRC DCCs?  if i offer a DCC to someone else, won't i have to tell
him the address to use?

i assume something on my machine can answer these questions, since
pretty well all the rest of my network-using software works, and return
addresses have to be written into IP headers.  i know i can successfully
hit echo and time services without ever binding my UDP socket, so something
in the kernel (i guess) can figure it out.  shouldn't there be a standard
call to that stuff to handle the needs of user-level software?

is my question making any sense?  or am i upside-down on the whole thing?

--
Hume Smith   <hclsmith@isisnet.com>