Hello, >> I take it that by "the proprietary software" you mean the proprietary >> terminal emulator running on the client PC.
Yes, that's correct. "The proprietary software" refers to the proprietary terminal emulator running on the client PC. >> One thing you might be able to do quickly is establish an SSH tunnel >> between the PC and the server, then route the proprietary terminal >> emulator telnet traffic through the tunnel. That, at least, will get >> you a more secure connection between the PC and the server. We've actually tested that approach before, but it introduced several technical challenges, and even though we managed to resolve some of them, it added complexity to the maintenance process. Additionally, it's important to consider that our end-users are not IT professionals but individuals primarily focused on sales. We need to encapsulate the entire process in a way that's transparent to the user, involving opening a program that initiates an SSH session within a tunnel, followed by launching the proprietary emulator for a Telnet session within that tunnel. We're also revisiting our workstation authentication process to transmit information through it in order to identify different application sessions, as the application on the server appears to be originating from localhost. Furthermore, we're reevaluating the mechanism for checking the number of sessions originating from each workstation based on the assigned roles. We're addressing various technical aspects, but this solution was ultimately rejected by the project team as it was perceived as a workaround, not robust and fragile. It posed risks to the business in a critical part of our operations. >> If I understand things correctly, the server sends all sorts of >> information to the proprietary terminal emulator. Most of that gets >> displayed on the emulator. But, given one VT escape code, the emulator >> sends the subsequent data off to the printer, until it gets the other >> VT escape code. The printer may then return a response. Yes, that's the basic concept, but it's even more intricate. The application continuously monitors what it receives from the terminal with regular interval checks (in milliseconds) and makes decisions based on rules. These decisions include sending commands to the printer, analyzing the responses, taking user actions, and even restricting user input in certain menu or submenu areas of the screen. However, I have a high-level understanding of this process as I'm not part of the application development team to delve into the finer details. >> If that understanding is correct, I suggest you grab an existing open >> source terminal program that supports VT escape codes: >> >> 1) Modify how it handles those two escape codes. >> >> 2) Modify it to listen to the printer for responses, encode those >> appropriately, and ship them to the server. >> >> I haven't worked with VT escape sequences in decades. If I recall >> correctly, some escape sequences cause the terminal to send information >> back to the server. In that case, you may need to synchronize return >> information from the printer with other return information. Thank you for your suggestion. As I mentioned earlier, our development team primarily focuses on the server-side application and is not competent to modify the client-side emulator, which is crucial in our case. They have already examined the PuTTY source code and confirmed that this type of development is beyond their expertise. That's why we are exploring open-source solutions that offer a plug-and-play feature set or potentially an evolution of PuTTY. If we don't find a suitable open-source solution, we will consider commercial emulators that integrate this functionality. As a last resort, we might opt for a proprietary solution and pay for the licenses and maintenance required for the work done in that product. The suggestion you made to adapt an open-source terminal program to support VT escape codes is certainly relevant, but unfortunately, it goes beyond our current expertise and that of our team Regards, Thierry
