Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number

RE: Reading from more than one socket at once

by splinky (Hermit)
on Jul 05, 2000 at 01:09 UTC ( #21058=note: print w/replies, xml ) Need Help??

in reply to Reading from more than one socket at once

Overall, good stuff. But I think you better doublecheck that "Perl will read a few bytes ahead to improve performance" claim. I don't recall coming across that anywhere else before. In particular, I've used print and <> with sockets before with no problems. The key is to not mix them with sysread and syswrite.

Also, I think IO::Socket and IO::Select deserve more space. After becoming comfortable with them, I far prefer them over the raw Perl stuff, which looks more like C than Perl. There's a good example of both IO::Socket and IO::Select at the end of perldoc IO::Select. Of course, it should be noted that the major limitation of IO::Select is that it doesn't allow you to wait for reading, writing, and exceptions simultaneously. You have to pick one. But, for the example you show, that's not a limitation.

Finally, one minor thing: "get all the data it wants before continue" should be "...continuing".

But, overall, pretty good stuff. Have a Scooby snack on me.


Replies are listed 'Best First'.
RE: RE: Reading from more than one socket at once
by ahunter (Monk) on Jul 05, 2000 at 01:59 UTC
    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.


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2021-01-18 07:45 GMT
Find Nodes?
    Voting Booth?