Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options
 
PerlMonks  

Re: Re: Detecting a closed socket

by Flame (Deacon)
on Aug 06, 2003 at 07:07 UTC ( #281285=note: print w/ replies, xml ) Need Help??


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)


Comment on Re: Re: Detecting a closed socket
Re: Re: Re: Detecting a closed socket
by MarkM (Curate) on Aug 06, 2003 at 15:29 UTC

    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

      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)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://281285]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (10)
As of 2014-08-22 12:49 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (156 votes), past polls