[
https://issues.apache.org/jira/browse/TS-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877852#action_12877852
]
Alan M. Carroll commented on TS-320:
------------------------------------
I am still waiting on the permissions. I am also working on an updated patch
because there were conflicting changes from the TS-18 merge.
I will also remove the #if 0 code. That's just an artifact of not being able to
check in intermediate states.
The IP_TRANSPARENT issue is not currently a problem, as none of the other code
actually sets that option. At this point I will fix that in the transparency
patch (TS-291) by tweaking autoconfig to check for the header file. That seems
more robust.
Let me think about the cleaner. I am not satisfied that it is sufficiently
general purpose to be moved to a more general header file. I think that should
be left for another distinct patch.
Actually, I added the is_connect and is_bound to correspond to the checks on
the socket file descriptor that existed in the previous code. I think it's
worth keeping that in to detect potential issues if these methods are used
elsewhere (which, IMHO, should be a goal, because there's still a lot of
duplicated code for connecting in various places).
> Do some cleanup on Connection::fast_connect and Connection::bind_connect
> ------------------------------------------------------------------------
>
> Key: TS-320
> URL: https://issues.apache.org/jira/browse/TS-320
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cleanup
> Affects Versions: 2.1.0
> Reporter: Alan M. Carroll
> Assignee: Alan M. Carroll
> Priority: Minor
> Fix For: 2.1.2
>
> Attachments: ts-320-diff-6.txt
>
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Action Plan:
> Unify bind_connect, fast_connect.
> 1. Split out the binding of the target address in to a new method
> Connection::bind_target(target_ip, target_port);
> This simply copies to the target IP address and port to Connection::sa. As
> far as I can tell this is the only thing the calls to bind_connection from
> IPC.cc do. We can then change those calls to direct calls to bind_target.
> Then we should be able to eliminate all the bool flags on bind_connect which
> aren't used elsewhere.
> 2. Remove the my_ip argument from bind_connect. Use spoof_ip in NetVCOptions
> instead. At this point the signatures for fast_connect and bind_connect are
> now identical.
> 3. Add support for the IP_TRANSPARENT sock opt provided by TPROXY in to
> NetVCOptions, either as a separate flag or (better) merged in to
> NetVCOptions::sockopt_flags. This would mean that spoof_ip is treated as a
> local address (i.e., an address already assigned to an interface on the local
> system) if not set, or as an arbitrary address requiring TPROXY support if
> set. If we conditionally define the mask as IP_TRANSPARENT or 0 depending on
> TPROXY availability we should be able to limit conditional compilation to
> that location (as the check will always fail if IP_TRANSPARENT is not
> available).
> 4. Move SO_REUSEADDR to NetVCOptions::sockopt_flags. This is set in
> bind_connect but not fast_connect.
> 5. Put an TCP vs. UDP flag in NetVCOptions. This would follow from the code,
> but as far as I can tell this is never used. It is passed in from the ICP
> logic but, because that also sets the "no bind" flag, it doesn't get invoked.
> It may be that bind_connect should just be implicitly TCP.
> 6. Verify that NetVCOptions default constructed values are such that
> bind_connect with a default constructed NetVCOptions does the same thing that
> fast_connect does.
> 7. Add an option (in the signature or in NetVCOptions) to handle the epoll
> support. AFAICT this is done in all cases where either fast_connect or
> bind_connect is called other than IPC (which we have already removed) so we
> could hard wire it. Comments in the code indicated this is already considered
> a problem.
> After all of this, we can replace all invocations of fast_connect with
> bind_connect with no change in functionality.
> Note: This is in preparation for working on TS-291.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
