I've been using recv, haven't tried read yet. I actually tend to stray away from <SOCKET> and print SOCKET because I've read that they block. using send/recv and setting the length to 1 didn't work, because recv "expands or contracts the length of $var to the length actually read from the handle" which for some reason even with an autoflush on the socket is everything up to the newline character. read and sysread do the same thing.. do I need to use vectors and the 4 arg select to accomplish this?
-brad.. this sounds SO simple, so WHY ISN'T IT!? ;) | [reply]
[d/l]
[select] |
Yes, they do indeed block, but it sounds like blocking semantics are what you are looking for. Writing non-blocking code is a non-trivial task (especially if you want cross-platform compatibility).
If you did indeed fcntl the socket to O_NONBLOCK, then yes, it would be good form to use select (or IO::Select), in order to determine whether or not data is present for recv, though this is not technically required, as a recv call will return EAGAIN on a non-blocking socket, if there is no data present to be received.
You also seem to be confusing buffered/unbuffered with blocking/non-blocking. Using send and recv (as well as sysread and syswrite, but not read and print) means that you are using unbuffered IO. Changing the value of autoflush has no effect on recv and send.
Regarding the resizing of your scalar, it should only be resized up to the maximum size specified in your recv call. Why don't you post your code so we can get a better idea of what's happening?
| [reply] |