Bugzilla – Bug 2106
Add SetSocket API to applications
Last modified: 2016-12-08 16:16:09 EST
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.
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.
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?
Created attachment 2695 [details] Usage in apps