Bug 2106 - Add SetSocket API to applications
Add SetSocket API to applications
Product: ns-3
Classification: Unclassified
Component: applications
PC Linux
: P5 enhancement
Assigned To: natale.patriciello
Depends on:
Blocks: 2423
  Show dependency treegraph
Reported: 2015-04-29 04:04 EDT by natale.patriciello
Modified: 2016-12-08 16:16 EST (History)
3 users (show)

See Also:

Application patch for introducing SetSocket (9.70 KB, patch)
2015-04-29 04:04 EDT, natale.patriciello
Details | Diff
API for socket creation callback (1.87 KB, patch)
2016-12-08 16:15 EST, natale.patriciello
Details | Diff
Usage in apps (4.58 KB, patch)
2016-12-08 16:16 EST, natale.patriciello
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description natale.patriciello 2015-04-29 04:04:57 EDT
Created attachment 2030 [details]
Application patch for introducing SetSocket

In current applications, sockets are created inside the method StartApplication, which is called at the specified start time.

What if the user want to edit some parameter (e.g. Socket attributes) ? He/she should schedule a callback right after the socket creation (i.e. the application starting). Usual config does not work (since the Socket isn't existing before the app start).

My proposal is to add a SetSocket API (paired with GetSocket) which allows the user to manually create a socket (with a factory for example), setting its attributes, and then use it inside the application.

Patch attached for BulkSend, OnOff and PacketSink.
Comment 1 Tommaso Pecorella 2016-05-29 16:11:12 EDT
I don't mind the idea, but I do mind the execution.

In the 3 apps you changed, m_socket is used both as a flag and as a socket.
If the socket has been already created, StartApplication will do nothing.

Even if StartApplication is private and shouldn't be called twice, I like to be extra careful. After all, there's a long-standing discussion about adding a start/stop functionality.

In your code, if one calls StartApplication twice, the socket will act erratically (e.g., Bind twice).
You could add a check, but that wouldn't eliminate the problem. As a matter of fact, who's preventing the user to create a socket, bind it to an address, even put it in a listening state and then feed it to the application ?

Summarizing: make the code more resilient, please.
Comment 2 natale.patriciello 2016-12-08 16:15:47 EST
Created attachment 2694 [details]
API for socket creation callback

I have changed completely the approach. Since the final need is to have a pointer to the application socket (in order to connect it to different traces), with this approach the applications can signal the creation of the socket. 

It is in the base class in order to provide a consistent naming across the applications.

What do you think?
Comment 3 natale.patriciello 2016-12-08 16:16:09 EST
Created attachment 2695 [details]
Usage in apps