home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / mswindo / programm / misc / 3404 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  2.2 KB
  1. Path: sparky!uunet!europa.asd.contel.com!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!agate!usenet.ins.cwru.edu!icd.ab.com!iccgcc.decnet.ab.com!schmidtg
  2. From: schmidtg@iccgcc.decnet.ab.com
  3. Newsgroups: comp.os.ms-windows.programmer.misc
  4. Subject: DDEML application question
  5. Message-ID: <1992Nov11.132435.9315@iccgcc.decnet.ab.com>
  6. Date: 11 Nov 92 13:24:35 EST
  7. Lines: 65
  8.  
  9.  
  10.  
  11. I am trying to develop a communications server using the DDEML.  Several
  12. clients can establish a conversation with the server.  The client sends
  13. a command packet to the server, the server processes it by sending it to
  14. a device and waits for the reply from the device.  When the reply becomes
  15. available, the server returns it to the client.  All packets consist of
  16. binary data.  I want to minimize the overhead in performing this simple
  17. transaction.  The problem that I am having is that the DDEML services do
  18. not fit well in this model.  Although conforming to the DDE standard is
  19. desirable, it may not be a strict requirement as the communication server
  20. is internal to the system.  However, performance is a big requirement.
  21.  
  22. So far I have considered:
  23.  
  24.  
  25. 1)      Client POKES command packet to server.
  26.     Server POKES command packet back to client.
  27.  
  28.     Advantage(s);
  29.         * Does exactly what I want.
  30.     Disadvantage(s);
  31.         * Departs from true client/server model (mutual client
  32.           server relationship).
  33.         * Requires establishing twice as many conversations as
  34.           other alternatives.
  35.  
  36.  
  37. 2)    Client POKES command packet to server.
  38.     Server sends a DATA message back.
  39.  
  40.     Advantage(s);
  41.         * Does exactly what I want.
  42.     Disadvantage(s);
  43.         * Does not conform to DDE standard.
  44.  
  45.  
  46. 3)    Client POKES command packet to server.
  47.     Client sends a request message to server.
  48.     Server sends a DATA message back.
  49.  
  50.     Advantage(s);
  51.         * Conforms to DDE standard.
  52.     Disadvantage(s);
  53.         * Requires an extra transaction.
  54.  
  55.  
  56. 4)    Client enters an ADVISE loop
  57.     Client POKES command packet to server.
  58.     Server returns data to client by an INFORM to the client.
  59.  
  60.     Advantage(s);
  61.         * Conforms to DDE standard.
  62.     Disadvantage(s);
  63.         * An unnatural way of modeling the problem.
  64.  
  65.  
  66. As I have very limited experience with DDE, can someone suggest a reasonable
  67. way to implement this?
  68.  
  69. Thanks in advance,
  70.  
  71. -- Greg Schmidt        schmidtg@iccgcc.decnet.ab.com
  72.  
  73. -- 
  74.