[Nfd-dev] [EXT] Multi-Worker NFD (MW-NFD) 0.7.1 Release

Junxiao Shi shijunxiao at email.arizona.edu
Fri Feb 19 15:19:26 PST 2021


Hi Sung

I had a quick look at your codebase, and I found a few strange things.
I'll only mention one below.

In mw-nfd/daemon/mw-nfd/mw-nfd-global.cpp file emitMwNfdcCommand function
contains the following code:
https://github.com/etri/mw-nfd/blob/44fd00a55b1a80595c5e677f74762334a25d9a39/daemon/mw-nfd/mw-nfd-global.cpp#L127
char buf[MW_NFD_CMD_BUF_SIZE]={0,};
mw_nfdc_ptr nfdc = (mw_nfdc_ptr)buf;
struct sockaddr_in worker, their;
auto params = make_shared<ndn::nfd::ControlParameters>(parameters);

for (i = 0; i < g_forwardingWorkers; i++) {
  // omitted code to assign 'worker' address

  nfdc->mgr = mgr;
  nfdc->verb = verb;
  nfdc->ret = MW_NFDC_CMD_OK;
  nfdc->netName = netName;
  nfdc->parameters = params;

  sendto(g_nfdcSocket, buf, sizeof(buf), 0, (struct sockaddr*)&worker,
addr_len);
  setCommandRx(i, true);

  numbytes = recvfrom(g_nfdcSocket, buf, sizeof(buf), 0, (struct
sockaddr*)&their, &addr_len);
  if (numbytes) {
    retval += nfdc->retval;
    ret = nfdc->ret;
  }
  setCommandRx(i, false);
}

The relevant data structure is:
typedef struct mw_nfdc_cmd {
  int32_t mgr;
  int32_t verb;
  int32_t ret;
  size_t retval;
  bool netName;
  std::shared_ptr<ndn::Interest> interest;
  std::shared_ptr<ndn::nfd::ControlParameters> parameters;
} mw_nfdc, *mw_nfdc_ptr;

Effectively, you are sending the memory representation of
std::shared_ptr<ndn::nfd::ControlParameters> instance over a UDP socket. I
think this can cause undefined behavior.
I wonder why you chose to send the management command as a UDP packet to
the worker thread, instead of sending an encoded command via a pair of
message queues?

Also, many unit tests are failing. Please check them.
You should use AddressSanitizer to ensure there's no memory leak and
undefined behavior.

Yours, Junxiao

On Fri, Feb 19, 2021 at 7:03 AM Sung Hyuk Byun via Nfd-dev <
nfd-dev at lists.cs.ucla.edu> wrote:

> Deal all
>
>
>
> We are pleased to announce the Multi-Worker NFD (MW-NFD) 0.7.1 which is an
> high-speed NDN forwarder fully compatible with NFD 0.7.1, and it can be
> downloaded from https://github.com/etri/mw-nfd.
>
>
>
> MW-NFD has parallel forwarding worker who keeps NFD's forwarding
> architecture, and can have multiple input threads dedicated to each
> physical port.
>
> We had demonstrated MW-NFD's forwarding performance in ACM ICN 2020 with
> the paper "MW-NFD (Multi-Worker NFD): An NFD-compatible High-speed NDN
> Forwarder" ( https://dl.acm.org/doi/10.1145/3405656.3420233 )
>
>
>
> MW-NFD support all management features with nfdc command, and all face
> types of NFD, except NDN-LP Reliability option in point-to-point faces,
> which will be supported in future release.
>
>
>
> It also has additional forwarding enhancement features : dual_cs and
> pit-token-hash.
>
> More information can be found at
> https://github.com/etri/mw-nfd/blob/main/MW-NFD-CONFIG.md .
>
>
>
> If you have any questions, comments, or bug reports, please let us know
> through email or this mailing list.
>
>
>
> Regards,
>
> Sung Hyuk Byun
>
> shbyun at etri.re.kr
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20210219/821ebda6/attachment.html>


More information about the Nfd-dev mailing list