Re: [RFC] comm API re-design

Alex Rousskov wrote:
> On 03/20/2010 01:04 AM, Amos Jeffries wrote:
>> As you know I've already broken off the comm API for listening sockets.
>>
>> What remains is the comm API for creating connections. I'm going to
>> start it sometime soon. Please speak up if you disagree, or have
>> alternative suggestions.
>>
>> What I have it in mind is to extend the ConnectionDetails class (CD for
>> brevity from here) to make it a bit more generic and hold data about
>> remote-end and squid-end of the connection, with some comm-level flags
>> about the content.
>
> You can drop the Details part and call the class Connection, I guess.
>
>> This would allow us to do a few useful things:
>> * comm listening API fills it out and hands it to upper layers (as now
>> but with more data and longer lifetime).
>> * TLS/SSL operations could be done in the comm layer and the info
>> embeded in the CD object. Instead of within each TLS-enabled
>> component.
>> * NAT and EUI lookups can be done in comm where they belong.
>> * CD objects could be kept as-is and attached to running state instead
>> of copied.
>> * CD objects easily give up data about both ends of a link.
>> * callers needing to create a connection need only fill one out like an
>> application form and hand it to comm.
>>
>> This last shows it's real benefit with forwarding:
>>
>> * peer selection and outgoing-addr selection can generate a list of CD.
>> * connect logic can walk the list attempting to get a success.
>> * retries can be a true "retry each possible link N times" measure
>> without multiple/single IP DNS results fuzzing some cases.
>> * can begin to do true controlled 'resume' on alternate routes.
>> * peer and route selection only ever gets done once per request.
>> * failover for peers by name can be combined with tcp_outgoing_address
>> selection.
>> * tcp_outgoing_address can easily become async "slow" category.
>> * sslbump can generate a CD for direct TLS connect and one for CONNECT
>> re-wrap fixing the sslbump failover bug.
>
> Looks good to me. Let's try to limit this to a _single_ connection. It
> may be tempting to add fields like "other IPs to try", but that should
> probably be handled in other classes.

Aye. Thats the goal.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE8 or 3.0.STABLE25
   Current Beta Squid 3.1.0.18