Query, set, unset:

use Socket qw(IPPROTO_TCP TCP_NODELAY);

sub nagle(*;$) {
    my $fh = shift;
    if (!@_) {
        return unpack("I", getsockopt($fh, IPPROTO_TCP, TCP_NODELAY) |
+|
               croak "Could not get Nagle state: $!") ? 0 : 1;
    }
    if (shift) {
        setsockopt($fh, IPPROTO_TCP, TCP_NODELAY, 0) ||
            croak "Couldn't enable Nagle's algorithm: $!";
    } else {
        setsockopt($fh, IPPROTO_TCP, TCP_NODELAY,1) ||
            croak "Couldn't disable Nagle's algorithm: $!";
    }
}
[download]

This functionality should only be used if it makes sense though.

Thanks. How can I make sure that every system the script possibly runs on actually has that constant, though?

--
mowgli

If you have a modern perl, it will always be defined in Socket.pm, whether your system actually has it or not. In case your system does not have it, calling the constant will cause it to croak with a message like "Your vendor has not defined Socket macro TCP_NODELAY". This is often what you want, so you don't have to do anything in that case.

If you want to check at runtime and e.g. only turn nagle off if the constant really is there, you can check with a string eval, e.g:

# untested code
use Socket qw(IPPROTO_TCP)
my $has_nagle = eval "Socket::TCP_NODELAY(); 1";
...
if ($has_nagle) {
    setsockopt($fh, IPPROTO_TCP, 
               Socket::TCP_NODELAY(), 1) ||
            croak "Couldn't disable Nagle's algorithm: $!";
} else {
    warn("Your system doesn't seem to support turning of Nagle's algor
+ithm\n");
}
[download]

(I also didn't try to import it in case you use a Socket.pm that doesn't even have the constant)

You usually turn off Nagle's algorithm with the TCP_NODELAY flag. Net::TCP supports this.

(I might be misunderstanding your question. If I am, feel free to correct me.)

Thanks. Does that work on all platforms, though? The CPAN tests indicate that it fails on win32 due to undeclared identifiers.

--
mowgli

It's like saying "how do I disable all the gears above second gear in my car?"

You seem to think that Nagle's algorithm isn't a tradeoff. It is: it increases bandwidth, but also increases latency. Fairly often, you don't care about bandwidth one way or the other, but want to decrease latency.

It's like saying "automatic is picking the wrong gear for this application, how do I put this car into second?".

---

Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Because the hotel parking attendants drive at 80 mph and you had to sue it to recoup the repair costs. :)

--
$Stalag99{"URL"}="http://stalag99.keenspace.com";

In order to get rid of latency (however small) in a case where bandwidth isn't really a concern. "efficiently" can mean different things, depending on what you want to accomplish. :)

--
mowgli

Randal,

While your question is a valid one to ask, your reply is disappointing, and IMHO, misplaced.

The fact that the OP knows what Nagle's Algorithm is, has sought and found a (less than satisfactory) solution in the Cookbook (which also describes a reason to disable it), makes me think the OP might have some idea as to "Why?".

I'm not trying to pick on you, I'm just pointing out that this is an example of what I'll call the Bunjee Reply, ala Dilbert. Sort of a That's a not-so-brilliant-question see-ya later kind of response. It makes me wonder if someone has posted the corollary to How (Not) To Ask A Question, namely, How (Not) to Answer a Question?

If I'm off base here, someone let me know.

-QM
--
Quantum Mechanics: The dreams stuff is made of