qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject C++: exposing options like TCP_NODELAY
Date Tue, 01 Apr 2008 22:16:08 GMT
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.



Mime
View raw message