I was figuring on using a database as the point of synchronisation, buffering and communication between a pair of programs. One that talked to the Com port, sending and receiving messages from a controler. The other program was the brains of the operation. Queues of messages would be database tables. Havn't written it yet so can't say how quick it will work.
Steven > -----Original Message----- > From: Steve Aish [mailto:[EMAIL PROTECTED] > Sent: 21 April 2004 9:04 am > To: [EMAIL PROTECTED] > Subject: Re: [DUG] Possible solutions > > > This idea may be way off base but here goes. It's called going low > tech... > > Use files. the "client" writes a file to a designated folder > with info > it wants to send to the "server". The "server" checks this > folder every > half second or so to see if there is info to send to the comport. If > there is do its thing and put the result in the same or another > designated folder for the "client" to pick up again. > > IF there is an error the "server" will pop out a short error > file. You > can keep things synchronised by setting the filenames by date/time or > sequence number so the client knows which file it is waiting > for. Then > delete (or move) the files after they have been read. > > The only problem you may have is if the server crashes or something - > make a time out so if the client has sent something and hasn't got a > result after 5 seconds then assume error and send again. > > Steve > > >>> "Jeremy Coulter" <[EMAIL PROTECTED]> 21/04/2004 8:34:48 a.m. >>> > Hi all. > I think I have worked myself into a corner and I am missing an obvious > answer here that I cant see because I am thinking about it too > much...if > you know what I mean. > Heres the senario :- > > I have an application that is connected to a comport. (the server) > I then have another application that needs to output the data to a > comport...the same comport (the client). > > This situation has come about after the intial design of the "server" > app....its not really a server but the analogy fits. > The "client" needs to pass some info to the "server" because its > connected to the comport, and 2 apps. cant share the same comport. > > So, I have tired using TCP/IP with INDY controls to pass data to the > "server", and that works fine, BUT then the server needs to pass back > data to the client, i.e. the data back form the comport is parsed and > a > result generated, which is then passed back to the client. > The problem here is, this might take a few seconds, and in that time, > maybe another request has been sent to the server to do something > else, > and because INDY uses threads you loose the reference to the first > thread that data was received on, so you cant pass data back on that > thread...etc. > > So, I used MailSlots, and I did have to deal with a message being sent > to every installed network protocal, but thats ok, it sometimes was a > wee bit unreliable, or would hand the server app. when it tried to > close....for what ever reason. > > This app. would be installed on win98 machines and up, and both client > and server are on the same machine. > > So, why not make teh client and server ONE app? because the server is > pretty much only got a very simple interface and is really only > designed > for logging some data, and I was trying to keep the 2 apps. seperate. > > So, I hope this is enough info for someone to either say...hey persist > with "this" line of development, or hey, try "this" line of > development. > > Like I say, I think I have got to that point where i cant think about > it > clearly anymore because I am getting a bit too anxious about it. > > Any help appreciated. > > Cheers, > > Jeremy Coulter > > > -------------------------------------------------------------- > ---------- > All email scanned with Nortons Antivirus 2003 > -------------------------------------------------------------- > ---------- > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > Visit us online at http://www.ecan.govt.nz ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. The contents of this email and any attachments are not formal policy of Environment Canterbury, unless otherwise stated. ********************************************************************** _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
