Re: [DUG] Possible solutions

[Phil Middlemiss]

Title: Message

From what I understood of the problem, maintaining state shouldn't be a problem since a TCP connection is established and should be able to be held onto for the entire length of the transaction.   Phil. ----- Original Message ----- From: Nello Sestini To: [EMAIL PROTECTED] ; NZ Borland Developers Group - Delphi List Sent: Thursday, April 22, 2004 8:18 AM Subject: Re: [DUG] Possible solutions maybe i am missing the issue but this sounds like the same problem that comes up in web apps about maintaining state between page accesses.   you have some kind of "transaction" that spans several messages sent back and forth across the comport link and you want to somehow maintain the "context" of each message.   so can't you solve it the same way the web apps do?   pass some kind of "cookie" (it can just be a 32bit integer) that identifies each "session" and then use that cookie to index into some kind of table/database/whatever-you-need to "remember" the current state of that session.   rgds   -ns http://www.roserox.co.th   ----- Original Message ----- From: Jeremy Coulter To: [EMAIL PROTECTED] Sent: Wednesday, April 21, 2004 3:34 AM Subject: [DUG] Possible solutions 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 _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi

_______________________________________________
Delphi mailing list
[EMAIL PROTECTED]
http://ns3.123.co.nz/mailman/listinfo/delphi