There's been some user interest in setting options like TCP_NODELAY on the
client (and maybe someday on the broker).
Exposing a raw FD to the user is not a good idea, as it'll hamstring us when we
want to support other transports in the future.
On the other hand, inventing an abstraction like "minimizeLatency" has two
problems:
- There are other options people might want to set, but creating abstractions
to mirror TCP options creates shallow, brittle abstractions that are likely to
be problematic to apply to other transports.
- If the customer knows they want TCP_NODELAY, it's not obvious that means
"minimizeLatency". As soon as we document the relationship, our "abstraction"
cease to be abstract.
Here's a 3rd option:
class ConnectionPolicy {}; // Abstract base for connection policies.
class TcpConnectionPolicy {
bool TCP_NODELAY;
.. etc whatever we want to expose
}
class Connection {
void applyPolicy(ConnetionPolicy&)
}
TcpConnectionPolicy p;
p.TCP_NODELAY = true;
myConnection.applyPolicy(p);
The semantics here are that IF myConnection is indeed a TCP connection, the
policy will be applied, if not, it will be ignored.
This supports the case where the users _knows_ they are dealing with TCP and
_knows_ the TCP specific options they want. However the code remains portable
and valid if it is someday run on a non TCP connection - the TCP policy is
simply ignored.
We could extend this notion to provide generic policy options on policy base
classes, or even to categorize transports into families with common options. I
don't think we're there yet, but for now it's a good solution to setting TCP
options in a portable way.
