On Tue, 2008-04-01 at 18:16 -0400, Alan Conway wrote:
> 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.
But they'll never want TCP_NODELAY just the effect (they think) it
brings, which is minimise the latency of my messages through the AMQP
stack and network. As I pointed out in IRC I think that TCP_NODELAY used
without thought can make the latency worse not better.
Have we ascertained from TSX if they are pursuing TCP_NODELAY for
latency reasons or if they have another thing in mind?
The following is a fine implementation, and would work just as well if we are
talking about the more abstracted properties as well.
> 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.
>
>
