Project

General

Profile

Actions

Task #2371

open

Port TcpFace and UdpFace to the new code base

Added by Alex Afanasyev over 9 years ago. Updated about 8 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
model
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Actions #1

Updated by Alex Afanasyev about 9 years ago

  • Status changed from New to In Progress

(Assigned to Steven Collison)

Actions #2

Updated by Alex Afanasyev about 9 years ago

  • Assignee set to Steven Collison
Actions #3

Updated by Steven Collison about 9 years ago

  • I plan on trying to port ndn-udp-face first since it's simpler
  • I'll use ndn-net-device-face as a baseline

Questions:

Actions #4

Updated by Spyros Mastorakis about 9 years ago

Hello Steven,

1) To my understanding, the answer is yes, you will need to use the ns3 socket class, but you will have to replace the existing Face class with the Face class of NFD and, in general, overload the methods of the nfd::Face class. For example, the RegisterProtocolHandlers and UnRegisterProtocolHandlers methods do not exist anymore.
2) To my understanding again by looking at the source code, Alex has made some tricks (or "magic" as he likes to call it :)) and actually sends two NS3 packets. The first one contains the segment length at its header and the second one is the actual TCP segment:

https://github.com/NDN-Routing/ndnSIM/blob/master-v1/plugins/ip-faces/ndn-tcp-face.cc#L172-L177

I guess that he did that to make the sending the receiving process easier.

@Alex: feel free to correct me, if I have said something wrong. Actually, I have not worked enough with these TCP, IP and UDP faces in order to be 100% sure that the things I have said are fully correct.

Actions #5

Updated by Alex Afanasyev about 9 years ago

  • To receive data, should I be registering a receive callback with the underlying transport mechanism(ns3 socket?)
    Yes, though I don't really understand this question. With TCP face, you need to communicate through tcp tunnel, not raw network interface like in NetDeviceFace.

  • What is the point of TcpBoundaryHeader in ndn-tcp-face? Is it used for debugging or do we actually need to add an extra header ?
    (https://github.com/NDN-Routing/ndnSIM/blob/master-v1/plugins/ip-faces/ndn-tcp-face.cc)
    This could be my question for you in cs118 :) This additional header was useful with old packet format (as there was no indication about message length in the packet format itself). With new packet format, it is no longer needed.

Actions #6

Updated by Steven Collison about 9 years ago

I noticed NetDeviceFace increments a FwHopCountTag before sending a packet. Should the Udp/Tcp Faces also increment the hop count? https://github.com/NDN-Routing/ndnSIM/blob/master/model/ndn-net-device-face.cpp#L84-L87

Actions #7

Updated by Alex Afanasyev about 9 years ago

Yes. FwHopCount needs to be increased.

Actions #8

Updated by Steven Collison about 9 years ago

  • File ndn-udp-face.cc added
  • File ndn-udp-face.hpp added
  • % Done changed from 0 to 20

Here's a starting implementation for UdpFace

Actions #9

Updated by Alex Afanasyev about 9 years ago

Don't upload code to redmine. Upload to our gerrit (gerrit.named-data.net)

Actions #10

Updated by Steven Collison about 9 years ago

  • File deleted (ndn-udp-face.cc)
Actions #11

Updated by Steven Collison about 9 years ago

  • File deleted (ndn-udp-face.hpp)
Actions #12

Updated by Spyros Mastorakis almost 9 years ago

  • Assignee changed from Steven Collison to Yuanzhi Gao
Actions #13

Updated by Alex Afanasyev about 8 years ago

  • Assignee deleted (Yuanzhi Gao)
Actions #14

Updated by Alex Afanasyev about 8 years ago

  • Status changed from In Progress to New
  • % Done changed from 20 to 0
Actions #15

Updated by Alex Afanasyev about 8 years ago

  • Target version deleted (2.1)

To follow up on this issue. There is no immediate plan to implement this feature. Effects of overlay simulations (such as varying overlay link bandwidths, cross traffic, etc.) is better simulated directly using Loss and Delay models on p2p or mcast links.

Actions

Also available in: Atom PDF