Query about accessing SendEmptyPacket method

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Query about accessing SendEmptyPacket method

Shravya Ks
Hello everyone,

While going through the DCTCP Linux code, I realised that DCTCP class in
ns-3 will have to make a call to SendEmptyPacket() method of TcpSocketBase.

Can someone suggest a feasible approach to achieve this?

Thanks for your time and help.

Regards,
Shravya
Reply | Threaded
Open this post in threaded view
|

Re: Query about accessing SendEmptyPacket method

Natale Patriciello
2017-05-30 6:13 GMT+02:00 Shravya Ks <[hidden email]>:
> Hello everyone,
>
> While going through the DCTCP Linux code, I realised that DCTCP class in
> ns-3 will have to make a call to SendEmptyPacket() method of TcpSocketBase.
>
> Can someone suggest a feasible approach to achieve this?


Hello,

I miss a bit of information; the DCTCP class derives from
TcpSocketBase, or it is another class? I suppose the second option;
so, I think the best option would be to create a subset of the
SendEmptyPacket (let's call it CreateEmptyPacket for simplicity) and
put it as a static function of TcpSocketBase class, and then
re-utilize this code in both SendEmptyPacket of TcpSocketBase and your
version of SendEmptyPacket. Of course, the set should be big enough to
allow to share pieces of code between the classes, but not bigger than
that (for instance, I suppose the part of actually sending the packet
is something out from the shared functionality since TcpSocketBase
uses TcpL4Protocol and your class will use another muxer/demuxer).

This approach could help if you need other pieces of code from
TcpSocketBase, and makes the code more testable (you can test the
output of the static methods more easily). In the end, a re-usable TCP
class consists of a series of static functions and methods which
utilize them.

HTH,
Nat
Reply | Threaded
Open this post in threaded view
|

Re: Query about accessing SendEmptyPacket method

Shravya Ks
Hello Natale,

Thanks for your reply.

Following the linux implementation, DCTCP will be deriving CongestionOps.
DCTCP needs to send early acks at times when delayed ack is enabled, so it
needs the socket specific values which are set in SendEmptyPacket. I don't
think a static function will serve this need. DCTCP will need to call
SendEmptyPacket of the SocketBase object which is interacting with the
DCTCP interface.



Regards,
Shravya

On Tue, May 30, 2017 at 12:31 PM, Natale Patriciello <
[hidden email]> wrote:

> 2017-05-30 6:13 GMT+02:00 Shravya Ks <[hidden email]>:
> > Hello everyone,
> >
> > While going through the DCTCP Linux code, I realised that DCTCP class in
> > ns-3 will have to make a call to SendEmptyPacket() method of
> TcpSocketBase.
> >
> > Can someone suggest a feasible approach to achieve this?
>
>
> Hello,
>
> I miss a bit of information; the DCTCP class derives from
> TcpSocketBase, or it is another class? I suppose the second option;
> so, I think the best option would be to create a subset of the
> SendEmptyPacket (let's call it CreateEmptyPacket for simplicity) and
> put it as a static function of TcpSocketBase class, and then
> re-utilize this code in both SendEmptyPacket of TcpSocketBase and your
> version of SendEmptyPacket. Of course, the set should be big enough to
> allow to share pieces of code between the classes, but not bigger than
> that (for instance, I suppose the part of actually sending the packet
> is something out from the shared functionality since TcpSocketBase
> uses TcpL4Protocol and your class will use another muxer/demuxer).
>
> This approach could help if you need other pieces of code from
> TcpSocketBase, and makes the code more testable (you can test the
> output of the static methods more easily). In the end, a re-usable TCP
> class consists of a series of static functions and methods which
> utilize them.
>
> HTH,
> Nat
>
Reply | Threaded
Open this post in threaded view
|

Re: Query about accessing SendEmptyPacket method

Natale Patriciello
2017-05-30 19:09 GMT+02:00 Shravya Ks <[hidden email]>:

> Hello Natale,
>
> Thanks for your reply.
>
> Following the linux implementation, DCTCP will be deriving CongestionOps.
> DCTCP needs to send early acks at times when delayed ack is enabled, so it
> needs the socket specific values which are set in SendEmptyPacket. I don't
> think a static function will serve this need. DCTCP will need to call
> SendEmptyPacket of the SocketBase object which is interacting with the DCTCP
> interface.

I got it by looking at the Linux source code. Aaaah, C developers..
they tend to make a beautiful interface, but then completely ignore
it.
My view on it is to pass a pointer to the TCP socket base in the
Congestion Ops constructor, as the last parameter, and defaulting it
to a nullptr. Then, add to the TCP socket base interface the line
"friend class DCTCP" in the protected area, explicitly saying that
DCTCP can access protected methods from it, and then use
SendEmptyPacket from the DCTCP class.


In this way, we have in the TcpSocketBase class the information on
who's accessing its protected members, without touching existing
congestion algorithms.


Of course, if you come up with a more clear solution, it will be considered :)
Nat
Reply | Threaded
Open this post in threaded view
|

Re: Query about accessing SendEmptyPacket method

Natale Patriciello
On 05/06/17 at 01:38pm, Shravya Ks wrote:
> Thank you Nat. I was thinking of doing it via callbacks. But your solution
> is better.
>
>
> Regards,
> Shravya


I though about it, but there is no control on who sets the callback. I
mean, I could write an application which then sets the callback to send
empty packets...

I must say that is very difficult to design the classes to have the
keywords 'public, protected, private' to mean exactly that; often,
public methods should be accessed by some subset of classes, and not by
others. In this way, exposing the internals by using callbacks could
make sense.

How to realize this? (I'm writing this just to have a reference for the
future). There should be a class, let's call it Socket, which implements
the behaviour for the applications through public methods. Then, these
public methods should call an internal (abstract) pointer, which
implement these public methods (let's call it L4). The L4 class uses
primitives from another class (let's call it L3) through another
(abstract) pointer, and so on...

This way, one can write very small L4, L3 classes, which intensively
uses callbacks; an user can extend the behaviour by setting callbacks in
appropriate points. Yes, and then fight with the spaghetti-callback
flow... but this is another question :-)


Well, about the original problem, if you are comfortable with my
previous mail, go for it; in any case, if we discover problems in one
approach or the other, we can fix it along the way.

Have a nice day!

Nat