RE: RE: Reading from more than one socket at once

[ahunter]

The 'read a few bytes ahead' stuff is true. I think it's actually done by stdio rather than perl, and you definately see odd effects because of it. It's not usually consistent, so it tends to show up as a heisenbug...

You won't have a problem if the socket is closed after the client writes its data, because perl (or stdio ;-) will see the EOF and stop reading, but if there's a delay between sending data, a few bytes that were sent before you stopped might only appear at the server after you've restarted (or the socket closes). It's not usually a problem, but I once had some code that failed about 1 in 25 times due to occasionally stopping at the wrong point. stdio does this because reading many bytes can be much faster than reading one at a time, and then future reads can be from memory.

As to IO::Socket and IO::Select, I agree - I might add a section when I get some time. I went off IO::Socket a while back after (yet more) blocking problems that never got diagnosed. Oddly, *that* only happened when a perl process was communicating with another perl process. Telnet was fine... That code was a mess, though, so it's probably that I messed up somewhere.

I'll get the typo fixed, too (doh)

Update: No, I was wrong - the problem is more often caused by write buffers. As these tend to be small, and are often not a factor (optimised out?) when you're communicating between processes on the same machine, people don't notice them, and think that autoflush is all you need to get things working properly. I've seen it fail on Solaris, usually when you get a script to talk to another script (rather than a telnet connection, but not always), and usually just after the connection is established (but not always...). I've never seen the problem on a Linux box, but I haven't played that much with networked ones. Still can't produce code that reliably demonstrates it, though, but the problem usually manifests as one or both scripts blocking indefinately when they should be sending/receiving data.

Andrew