Re: IO::Socket::INET, quake, and me...

A bit late, but I'll offer whatever little help I can...

I had a somewhat similar problem and it ended up being my client not sending a \n at the end of each message. I was able to send my messages, but the server didnt get them until I killed my client program.

It seems that the newline is what IO::Socket::INET takes as the default input record separator (unless specified otherwise by changing $/...right?).

Best of luck!

Heatseeker Cannibal

Comment on Re: IO::Socket::INET, quake, and me...

Replies are listed 'Best First'.
Re^2: IO::Socket::INET, quake, and me... ($/) by tye (Sage) on Dec 07, 2007 at 19:26 UTC
No, that has nothing to do with IO::Socket::INET. It has to do with `<$sock>` also known as `$sock->readline();` which won't return until either $/ is read or end-of-file. Killing the client closes the socket which sends end-of-file (as would using shutdown). This is part of the reason one should normally not use `<$sock>` but instead should use sysread (or similar). Even if your protocol adds newlines on the end of each "packet", using `<$sock>` makes it hard to debug what broke when things go wrong. - tye	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^2: IO::Socket::INET, quake, and me... ($/)
by tye (Sage) on Dec 07, 2007 at 19:26 UTC

No, that has nothing to do with IO::Socket::INET. It has to do with <$sock> also known as $sock->readline(); which won't return until either $/ is read or end-of-file. Killing the client closes the socket which sends end-of-file (as would using shutdown).

This is part of the reason one should normally not use <$sock> but instead should use sysread (or similar). Even if your protocol adds newlines on the end of each "packet", using <$sock> makes it hard to debug what broke when things go wrong.

- tye

[reply]
[d/l]
[select]