[
https://issues.apache.org/jira/browse/MINIFICPP-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16842023#comment-16842023
]
Daniel Bakai commented on MINIFICPP-851:
----------------------------------------
I completely agree. It is hard enough to write good socket code once, so
consolidating multiple implementations into one is the way to go.
One more thing that would be worth doing (and this is the perfect groundwork
for it) is looking at select/poll codes where we asynchronously manage multiple
sockets and move that to a common implementation as well.
> Restructure both client and server socket codes in Nanofi and MiNiFi
> --------------------------------------------------------------------
>
> Key: MINIFICPP-851
> URL: https://issues.apache.org/jira/browse/MINIFICPP-851
> Project: Apache NiFi MiNiFi C++
> Issue Type: Epic
> Affects Versions: 0.6.0
> Reporter: Arpad Boda
> Priority: Major
> Labels: network
>
> Current issues:
> * MiNiFi Clientsocket and Nanofi cpeer codes have a lot in common.
> * Clientsocket's implementation contain a lot of serversocket-related code.
> * LystenSysLog processor has a built-in socket handling instead of using
> ServerSocket.
> Goals:
> * MiNiFi ClientSocket should only be a wrapper around client socket
> implementation in Nanofi. As Nanofi impl. is platform-independent, this could
> make the current duplication go away, too.
> * Listen related codes (bind, accept, etc) should be moved to ServerSocket.
> * Both client- and server side API should provide interface to set some
> socket properties (TCP/UDP, network interface, listen ip).
> * ListenSysLog should depend on ServerSocket instead of having a socket
> implementation in the processor.
> * ListenSysLog should have properties to bind only a specific interface/IP,
> opening syslog port on all available interfaces may raise security concerns.
>
> [~bakaid] [~phrocker] please feel free to extend with your remarks.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)