UNIX talk protocol docs.   

[ in case anyone cares, this information is freely usable,
  redistributable, modifiable, etc, in the same terms as the
  XFree86 system. (C) Roger Espel Llima, 1999, yadda yadda yadda ]

A lot of people have asked me about information about the Unix talk,
ntalk and ytalk protocols.  I haven't had the time to produce a
structured, RFC-like document yet, so instead I've pieced up bits of my
replies to a few such mails.  This should at least tell you where to
look and what the pitfalls are, if you're planning to write a program
that must be compatible with UNIX talk.

------------------------------------------------------------------------

I got my information about how talkd works mostly from the sources of
talk and talkd (you can ftp the sources to any BSD talkd, from your
local FreeBSD mirror, they'll be in /FreeBSD-current/src/libexec/talkd
or similar.  the C source itself isn't terribly clear, but the header
files alone help alot in understanding what to send over the network.

here are a few things to know:

   . there are 2 different, incompatible talkd versions, that use different
     ports and data formats.  to support both, you need to send a test
     packet to each port on the target machine and see which, if any,
     answers.

   . what talkd does is hold "invitations" for you.  an invitation is a
     piece of data that says "user blah wants to talk to you and is
     listening to port foo on 1.2.3.4".  invitations expire after about
     30 seconds.

   . first you need to check if there's an invitation for you on the
     remote host; if there is, you connect (tcp) to the port it tells
     you, and that's it.  if there isn't, you need to ring the user on
     the remote machine (by sending another packet to the talkd there),
     and then leave an invite on the local talkd, with the port number
     that you're listening on.

   . since invites expire after a bit, you need to keep sending them
     every 30 seconds or so while you're waiting for the guy to answer.

   . if the client has to quit before managing to establish a
     connection, and if you have left an invite, it's good manners to
     send a packet to clear it.

   . one neat trap: in the packets you send, there are a few addresses
     included, in sockaddr_in format... these need to be in network
     order (including the port number).  more importantly, struct
     sockaddr_in isn't defined the same on all OS's!  you need to use
     the BSD4.2 definition, not the BSD4.4 one (the BSD4.2 one starts
     with "u_short sin_family", the BSD4.4 has "char len; char sin_family").
     in doubt, you'll have to hand-translate by defining your own
     structure.

> I know that I can have a look at the source code, but a specification
>  would be better, you know.

for an example of talkd negotiation, i'd recommend looking at the utalk
code..  even though utalk isn't quite finished, the talkd part is.  it's
linked from my webpage, and the relevant files are comm.h and comm.c.  i
found the talkd code in ytalk very hard to read, which is why i rewrote
it for utalk instead of borrowing it.

[ utalk is/was a project to do a talk-like program with the same talkd
  negotiation but a different protocol once the session is established;
  see http://www.eleves.ens.fr:8080/home/espel/utalk/index.html ]

In the standard talk/ntalk/ytalk protocol, once the client figures out
the other side's listening port from the daemon, it'll to a tcp connect
and send 3 chars, which are its chars for delete character, delete line
and delete word; and the other side will do the same too.  So after
completing the tcp connection, read 3 chars, don't display them, keep
them stored, and interpret them as "backspace", "kill word" and "kill
line" respectively.