Re: Re: Detecting a closed socket

[Flame]

in reply to Re: Detecting a closed socket
in thread Detecting a closed socket

I seem to have confused you a little. I'm not all that concerned about the sucess of the transmissions themselves, so I have no checks on any of the writing to the sockets, the only problem I had was a set of dead sockets that my server was holding on to un-necessaraly. True I could add greater destinction between what went wrong in the read set, and I may do that at some point, but as it seems to work now, I see no need. As for the IO::Select thing, it is only being used as a "this socket has something to say" indicator. The expected length is determined by a 4 digit number that prefixes the message.

It's also possible I'm mis-understanding your advice, if so please explain more fully.

---

My code doesn't have bugs, it just develops random features.

Flame ~ Lead Programmer: GMS (DOWN) | GMS (DOWN)

[MarkM]

UPDATE: The poster was using the return of read(), not write(). This still isn't safe under all circumstances, but it should be safe as long as the socket is blocking, and there is no requirement for the server application to switch between multiple clients. In the servers that I normally write, I always have to switch between multiple clients, therefore I always choose to use non-blocking sockets, with all read() and write() operations performed by a buffering layer.

Detecting failure on write() only allows you to clean up 'dead' sockets when you get around to writing to the sockets. This can be sub-optimal if write() is issued infrequently.

Also, write() only guarantees that the bytes make it to a system buffer, it does not guarantee that the socket is still 'open'. If the socket is blocking (the default), write()'s larger than the size of the system buffer will block, holding the entire server process up. If the socket is non-blocking (see IO::Handle::blocking()) write()'s may return with fewer bytes (usually, the room left in the system buffer before it is filled), but this does not mean that the socket is closed. It just means you have to complete the write() at a later time.

Somebody else suggested that you use Net::Server. The reason for this suggestion is that socket manipulation is not always intuitive, and it is frequently more complex than most people want to understand. Server applications implemented using logic like "syswrite(4) must return 4" may work in the present, because 4 is significantly less than the size of a system buffer, but what happens when more bytes are written, and the system buffer gets filled? The server can fail, and the failure can be difficult to reproduce or solve later.

Cheers,
mark

[Flame]

I'm not using write() to determine if it's still open, I'm using sysread().

---




My code doesn't have bugs, it just develops random features.

Flame ~ Lead Programmer: GMS (DOWN) | GMS (DOWN)