Re: [RFC] comm API re-design

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.

Thank you,

Alex.
Received on Thu Mar 25 2010 - 16:30:19 MDT