Roeland Moors <roelandmoors / telenet.be> writes:

> On Mon, Dec 27, 2004 at 08:52:01AM +0900, Michael Fuhr wrote:
> >
> > A write fails with EPIPE if the peer has already closed its side
> > of the connection.
>
> It looks more like the connection isn't ready yet. Is this
> possible?

If nobody's listening on the socket then connect() should fail with
ECONNREFUSED.  If the socket's listen queue is full then connect()
should either block or fail with ECONNREFUSED (behavior varies
depending on the OS).  If connect() succeeded, then the connection
should be "ready" enough to use.

I still haven't been able to contrive a situation where writing
immediately fails with EPIPE but writing after a brief sleep works,
so that remains a mystery.  Anybody?  (Please test guesses and show
server and client code that duplicates the behavior.)  That might
be a question for comp.unix.programmer or comp.protocols.tcp-ip,
although AF_UNIX might not be appropriate for the latter.

Does the peer also listen on an AF_INET socket?  If so, have you
tested your client with that?

> Reading works just fine, but that's probably because it has to
> wait for input.

Reading when?  Your example didn't show that.

> > What's on the other end of the connection?
>
> I'm trying to send a command to a device created by lirc:
> http://www.lirc.org/html/technical.html#applications

Have you checked that product's documentation, FAQ, list archives,
and/or source code?  Your problems might be more related to that
product than to Ruby, so you might get more help on their mailing
list.

> > Have you run a process trace on the peer
> > to see what it does after it accepts your connection?
> > 
> Could you explain this a bit more?
> Or point me to some documentation on how to do this?

I don't use Linux much but I think "man strace" should point you
in the right direction.

-- 
Michael Fuhr
http://www.fuhr.org/~mfuhr/