# Required overhead for IPC apps

**URL:** <https://mangoh.discourse.group/t/required-overhead-for-ipc-apps/1209>\
**Category:** mangOH Red\
**Created:** [March 1, 2018, 6:39pm UTC](https://mangoh.discourse.group/t/required-overhead-for-ipc-apps/1209 "2018-03-01T18:39:13Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![nick](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/nick/32/1380_2.png) [@nick](https://mangoh.discourse.group/u/nick)\
**Post date:** [March 1, 2018, 6:39pm UTC](https://mangoh.discourse.group/t/required-overhead-for-ipc-apps/1209/1 "2018-03-01T18:39:13Z")

</div>

Hello all,

On a call in December of last year with @dfrey and @dclark75 I recall mention of required cleanup for apps that act as an IPC server. At the time we did not have any IPC apps so I never followed up.

Fast forward to today, we have several apps communicating using Legato’s interface definition language. Overall it’s working quite well but I want to make sure I’m not being naive in terms of required overhead to keep IPC functionality working reliably. Should I be implementing retry mechanisms for connecting the client app and server app? Should I be implementing cleanup sub-routines that respond to a certain signal? I’m just worried that at some point in the field one of the client/server connections will fail resulting in serious system failure. I believe the Legato application framework handles this to a certain extent but wanted to verify the limits.

Another note: we are not directly using any memory pools in our apps.

Thanks in advance!

---

<div class="post-metadata">

**Author:** ![dfrey](https://sea2.discourse-cdn.com/flex016/user_avatar/mangoh.discourse.group/dfrey/32/303_2.png) [@dfrey](https://mangoh.discourse.group/u/dfrey)\
**Post date:** [March 1, 2018, 11:26pm UTC](https://mangoh.discourse.group/t/required-overhead-for-ipc-apps/1209/2 "2018-03-01T23:26:02Z")

</div>

I think the specific case that I was referring to is the one where you have many client apps connecting to one service app. In this type of scenario, there is often a `CreateSession()` function that allocates some session related state variables in the server and then returns an opaque handle to the client. The client then passes this handle back to the service when calling the various functions. eg. `DoSomething(sessionHandle, someParameter)`. It’s also common to have a `DestroySession()` type of function in this scenario that will invalidate the handle and release the resources in the server associated with the session. A potential problem arises if the client calls `CreateSession()`, but then doesn’t call `DestroySession()`. The solution is `le_msg_AddServiceSessionCloseHandler()` which allows you to register a callback in the service so that any time a client disconnects the function is called. This allows the server to clean up after the client (assuming the client didn’t clean up after itself). This comes into play when a client crashes or is killed and thus doesn’t call the `DestroySession()` function.

Another thing to look at is the `faultAction` setting of the processes section of the `.adef` file. This allows you to control what happens when a process crashes in an app. As a concrete example, the `spiService` process in the `spiService` app in Legato has a `faultAction` of restart. If there is a client app connected to `spiService` and I do `kill -s SIGSEGV [pid of spi service]`, then immediately the client app will exit because the service it was bound to has died. So assuming the client app also has a faultAction of restart, it will be restarted by the supervisor. It will get stuck part way through startup though because there’s no `spiService` to bind to anymore. The supervisor also restarts spiService and then the client app continues on since it’s binding is now satisfied.

FYI: spiService uses `AddServiceSessionCloseHandler` if you want to see an example of how to use it.