[ENHANCEMENT] Persistent TCP from command line

[rlights]

Desktop command line - allow persistent TCP
(Win & macOS & linux)

I use Packet Sender frequently as a simple data-sending widget within scripting platforms & integrated control environments without native socket support.
Occasionally I need to send different chunks of data in one session based on responses, e.g. negotiating PJLink control to remotely operate projectors, or uploading a firmware file after sending a trigger string.

Persistent TCP sessions could possibly be implemented by nature of passing to, or receiving in return, a session identifier token of some kind (as well as timeout parameters etc).

Could sponsor this if it's suitable / possible!

[dannagle]

You got my attention with "sponsor" 😉

Something like this has been requested several times. It would work similar to like you are describing. However, the app cannot exit or the connections would close. It'd need to drop you into some kind of interactive shell environment where you generate persistent sessions to reference to send/receive. You would need to dedicate a terminal tab to use it or use some multiplexing tool like tmux.

Alternatively, this could be a service daemon running in the background that you send commands to on your prompt. Now, you stay in your native shell. However, something like that is painful to set up and work reliably across all platforms, so I try to avoid it.

[rlights]

Hadn't thought of the issue of managing the background process. Could it be made to work with the main process launching a child/ another copy of itself?
Alternatively all (desktop) environments AFAIK have some mechanism to detach a launched process from the shell used to launch it (externally to that app doing it itself), then that background process could be communicated with by the run-once shell calls?

[dannagle]

Yes, nearly all desktop environments support some kind of detached process. However, coding directly to the desktop environments to support that background process becomes unmanageable very quickly once "Linux" is added to the requirements list. I have no idea what flavor of Linux it is being run on. It is already painful just keeping the default Red Hat and Debian based distros within feature parity once I get Mac and Windows working.

I just further convinced myself that keeping everything contained within the app is the way to go. Just open a new terminal tab or a new SSH session in your preferred desktop environment. Simple workaround.