qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: C++: exposing options like TCP_NODELAY
Date Wed, 02 Apr 2008 12:41:23 GMT
Andrew Stitcher wrote:
>>   - 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.

Agreed, but customers that know TCP will be inclined to want to try these 
things. Unless/until we have comprehensive transport-independent policies that 
cover everything you might do with TCP options, allowing people to set TCP 
options in a portable way seems like a good compromise that will

  a) allow customers (and ourselves) to experiment, which may turn up useful info.

  b) keep customers who want to experiment happy, giving us time to develop 
genuinely abstract transport-independent policies that are not just knee-jerk 
reactions to persistent requests for specific TCP options.

> The following is a fine implementation, and would work just as well if we are talking
about the more abstracted properties as well.

Agreed - that was my thinking. Totally generic policies that we believe will 
apply to any transport could go on ConnectionPolicy as virtual functions that 
get overridden by specific policies. We could also define transport "families" 
with similar characteristics as intermediate base classes, e.g. 
StreamConnectionPolicy or PacketConnectionPolicy.

However I think the first step is to define leaf policies for TCP, with SSL and 
infiniband following closely. That gets us off the hook in the short term with 
users who want to experiment with TCP options but leaves it open to us to build 
abstractions above that as we get a better understanding of the kind of policies 
that apply across transports. Indeed being able to easily tweak 
transport-specific policies will probably help us in our performance experiments 
as well.

If we go this route we should also define broker configuration for policies, 
some consistent naming scheme generated from the policy classes, e.g.
--policy-tcp-nodelay



>> 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