(re-) design question

Question

Hullo all. I hope the collective intelligence of the community can help guide us here. 
 We have a large-ish program written & running under AcuGT (Extend) for Windows. It has a Windows UI. It is a real-time transaction processing engine with a UI to monitor and control the activity. So it runs in 2+ threads but its a single program. 
 We want to split this into two programs: 
 
 A transaction processing engine that runs as a Windows Service, so it launches on boot and is always running. No UI at all. 
 A UI that interacts with the above program. Ideally we would just take the existing code - the current UI thread - and make minimal changes to it, so it will still be an AcuGT/Extend program. But users could launch/run it using AcuToWeb. 
 
 We want to put minimal effort into this, as it does not extend the functionality of our product, it just solves some security + remote-access issues. 
 It should not be too hard to simply split this one program (currently implemented as two threads) into two programs. But what would be the easiest (and most robust) way to implement (inter-process) communications between them? They will be running on a single server. 
 Note there could be multiple instances of the UI app. We will have to figure that out. We can utilize a design that allows only one at a time. 
 Thank you!

RobertRedekop · Accepted Answer

First, I should note that I am not an expert on C$SOCKET, but I have used it, so I figure my skill level is intermediate. 
 Without blocking? Effectively. Technically, it will block for the timeout value when there is no data waiting to be read, but keep that small and you hardly block at all. When waiting for a connection, keep the timeout small and add a sleep when nothing happens, to avoid wasting time just waiting for connection(s). Please note, this assumes that your server side stuff needs to run while waiting for a connection. You could simplify things if the server side required the client to be running/connected in order to do anything, but I think you would be better off letting the client disconnect/reconnect as needed. 
 With the AGS-READ, you can choose to block for a small timeout, or use the zero-size read trick to check for data, then read only that amount of data. This results is a zero-wait read with a test/read (technically 2 reads, one to test for data, one to get it). Given that this is a replacement for checking for messages, that should work. (Warning: Since the packets could have only part of the message due to network traffic optimization etc, you will also have to test if the message is completely received, or if you have to save what you have so far, treat the message as not received yet, and check for more the next time you check for the message. And handle a dropped connection by resetting the buffer info, and changing your internal flags that mark the connection as on or off. You know, programming stuff.)

Menu

Extend / AcuCOBOL User Discussions

Verified Answers

(re-) design question

Top Replies

Resources