1) we are talking about engineering a complex (and not necessarily guaranteed, esp at the OS level of the TCP connection) way of sustaining TCP connections when it isn't necessary. The whole point of (LMCE) devices is that they can stop and start, disconnect and reconnect as required. Modularity. Why build this complex extra functionality into DCERouter code, when it is a more elegant and clean/tidy just to close the device connections at suspend, and reconnect on resume. Both require code changes, but the latter is much more bullet proof and tidy.
2) the retain-connections option cannot survive a core reboot, or even a DCERouter reload, so this case would have to be handled anyway... and the simplest way to handle this would be to implement the former option above... which would solve the issue in the first place....
I guess that reconnecting the device would also restart the TCP connection from the core to the MD (because there is two, isn't there? One core->device and one device->Core ?)
If that is the case, I totally agree with this proposal, it keeps it simple
As colin mentions, sending the device process a signal could probably do it. Don't know if a process can provide a suspend/resume hook to the kernel, or if there is a special resume signal, but the SIGHUP signal seems like a good candidate (wikipedia says something like: SIGHUP tells programs to reload configuration and reinitialize).
If the signal approach is used, it could be done from both the resume scripts and from the launch manager. As the LM already knows which devices are present (and possibly which ones need restarting, if some don't), it makes sense to me to let it handle this.
This depends on how the LM works, but at least it should be possible to do some ps | grep and bash scripting to get the process IDs to send signal to, using the device id as a start.