On Wed, May 5, 2021 at 3:31 PM Bruce Richardson <bruce.richard...@intel.com> wrote: > > On Wed, May 05, 2021 at 03:07:02PM +0530, Jerin Jacob wrote: > > On Wed, May 5, 2021 at 2:13 PM Thomas Monjalon <tho...@monjalon.net> wrote: > > > > > > 05/05/2021 09:49, Harman Kalra: > > > > Hi All, > > > > > > > > We have a use case where we need to gather statistics over network. > > > > Current implementation of telemetry library is based on Unix socket, we > > > > would like to enhance the scope of library to use network sockets. We > > > > understand security challenges with network sockets, to overcome them > > > > can we can think of two steps: > > > > 1. By default library will be using Unix sockets, it will be user > > > > decision to run library with network sockets by passing respective eal > > > > flags. > > > > 2. We can introduce some key/password authentication mechanism to the > > > > library, where only authorized clients can get connected to the server. > > > > Password can be passed by the user as eal flags, something similar to > > > > vf token which is uuid based. > > > > Kindly provide us suggestions/challenges over this enhancements. > > > > > > Not sure it should be part of the telemetry lib. > > > In any case, when implementing network communication, > > > I encourage you to look at ZeroMQ. > > > > ZeroMQ is a good option for Transport to hide the underlying transport > > variants like In-process, Intra-process, TCP. > > Also, it has various different options for security backend like > > http://curvezmq.org/ > > > > Sounds reasonable - I'm in favour of any scheme that means that we don't > need to implement out own authentication or security mechanisms for this. > > > if we pick ZeroMQ for transport then it will translate to > > > > 1) Remove unix file socket from telemetry > > 2) Use ZeroMQ for local and remote messaging > > 3) Needs to make telemetry or dpdk depends on ZeroMQ library(Since > > telemetry is experimental, I hope, we can change this) > > > > Thoughts from others including telemetry maintainers > > > I'd like to keep the existing Unix socket around, as well as any extra > zeromq interface, rather than replacing one with the other. Then rather
I think, the purpose of zeromq is to unify the different transport mechanisms to avoid multiple code path for different transport.IMHO, at some point in time it needs to unify. > than introducing a hard dependency on zeromq, it can be an optional one, > where support is compiled in if available. There may be monitoring > applications such as collectd, which run their own local monitoring process > and for which the local unix interface may be as good. Collectd has zeromq plugin for transport[1]. So, I think, we can meet that use case too with zeromq [1] https://collectd.org/wiki/index.php/Plugin:ZeroMQ > > /Bruce
