I said that it was fairly unusual to have a protocol that always sends end-of-line on the end of each packet. You managed to list only two. However, you have a very good point that text-only (or at least mostly text) protocols have become common (I'm more used to network protocols that don't assume all computers use ASCII -- but I'm just old). (:

I wanted to state the case against <SOCK> a bit strongly because I've been seeing a lot of code using it when it shouldn't.

Also note that using alarm() makes your code less portable. Having an alarm() actually trigger can leave Perl "confused". So that isn't a technique that I can highly recommend. Unfortunately, the alternatives are usually even more complicated and have their own faults so building very robust network servers in Perl gets messier than is often expected when programming Perl. ):

Note that in the node that I was replying to, the author wrote both sides of the "protocol" and perhaps even meant to send "\n" on the end of each packet. Using read would have probably been enough for the person to figure out the mistake and would have been much simpler than trying to write a robust server and client that tries to handle lots of more unusual failure modes gracefully.

Having something "hang" is one of the more difficult cases to debug and so I stand by my assertion that, in Perl, it is best to not use <> to read from sockets even when you expect that there will be a "\n" on the end of the next packet.

        - tye (but my friends call me "Tye")