Yes ytalk doesn't behave sensibly. ytalk should retry the other services
when it gets ECONNREFUSED not go kerunch.
> In icmp.c, there is an error convert struct that sets icmp message fatality
> levels. The one for ECONNREFUSED (ICMP_PORT_UNREACH) is marked as fatal.
This is because it is fatal. It means 'there is nobody listening to these
messages you are sending me so shut up'.
> udp port/socket to send to BOTH ntalk and otalk services. If you try this
> to a machine running only one kind of talk (otalk), then you get back an
> ICMP_PORT_UNREACH message which the kernel signals the process with the
> ECONNREFUSED and then closes the socket -- it's a fatal error. I fixed this
The kernel does _NOT_ close the socket. TCP will go through its close down
states at the protocol level, but nothing kills the UDP socket.
> on my machine by removing the fatal flag -- 1 -> 0. But I have no idea
> how many RFC's that violates or even if that is a good idea. In practice,
RFC1122.
> it has never caused any problems.
It shouldn't cause too many. Most BSD systems fail to report the error as
is required by RFC1122, which is one reason it shows up.
Ronald on unix sockets:
> I have tested it again but with pipes I can't reproduce it anymore (a
> race condition?) But if I use a socket pair of unix domain sockets the
> problem still occurs. I would write >4095 bytes but only 4095 bytes are
> written without blocking. The next call blocks. Here is a simple program:
Known. The AF_UNIX sockets don't support a lot of semantics in 1.2.x. The
current 1.3.x ones currently support all but fd passing, and Im workingo on
finishing that off.
Alan