IPC options on Windows
in [TCL]
|
From: Mark Roseman on 3 Jun 2010 16:15 I've got a traditional server process, and also a GUI process which can keep an eye on and control the server process. Either one can run without the other, and either one might be started or stopped independently of the other. I'd been using DDE to communicate between them, which is great because it doesn't involve separately maintaining connections between them, and the namespace to find the other (TclEval/XYZServer and TclEval/XYZMonitor) is pretty unpolluted. :-) Unfortunately, if I try to get the server process to run as a Windows service I get problems on newer versions of Windows. DDE won't work between services and user processes (they're placed into separate 'sessions' for security reasons). Since messages would be initiated both by the GUI and the server I'm not sure if sockets are the right way to go: the server won't necessarily be on a known port (for GUI->server connections) and there'd be similar issues for picking an available listening port for the GUI. I can make it work, but it's going to be a bit more fragile. Or should I just write the listening port numbers to the registry? Any other Windows IPC methods that would be a good fit for this situation, and readily available to use in Tcl? Thanks Mark
From: Bruce on 3 Jun 2010 17:22 Mark Roseman wrote: > I've got a traditional server process, and also a GUI process which can > keep an eye on and control the server process. Either one can run > without the other, and either one might be started or stopped > independently of the other. > > I'd been using DDE to communicate between them, which is great because > it doesn't involve separately maintaining connections between them, and > the namespace to find the other (TclEval/XYZServer and > TclEval/XYZMonitor) is pretty unpolluted. :-) > > Unfortunately, if I try to get the server process to run as a Windows > service I get problems on newer versions of Windows. DDE won't work > between services and user processes (they're placed into separate > 'sessions' for security reasons). > > Since messages would be initiated both by the GUI and the server I'm not > sure if sockets are the right way to go: the server won't necessarily be > on a known port (for GUI->server connections) and there'd be similar > issues for picking an available listening port for the GUI. I can make > it work, but it's going to be a bit more fragile. Or should I just > write the listening port numbers to the registry? > > Any other Windows IPC methods that would be a good fit for this > situation, and readily available to use in Tcl? > you might look into tcom - it uses windows COM interfaces which is "newer" that DDE, but I don't know if there are similar issues with COM across user processes and services or not if you need/want to go teh socket route check out the comm package (http://wiki.tcl.tk/2507) which wraps and simplifies the messaging interface Bruce
From: Alexandre Ferrieux on 3 Jun 2010 18:00 On Jun 3, 10:15 pm, Mark Roseman <m...(a)markroseman.com> wrote: > I've got a traditional server process, and also a GUI process which can > keep an eye on and control the server process. Either one can run > without the other, and either one might be started or stopped > independently of the other. > > I'd been using DDE to communicate between them, which is great because > it doesn't involve separately maintaining connections between them, and > the namespace to find the other (TclEval/XYZServer and > TclEval/XYZMonitor) is pretty unpolluted. :-) > > Unfortunately, if I try to get the server process to run as a Windows > service I get problems on newer versions of Windows. DDE won't work > between services and user processes (they're placed into separate > 'sessions' for security reasons). > > Since messages would be initiated both by the GUI and the server I'm not > sure if sockets are the right way to go: the server won't necessarily be > on a known port (for GUI->server connections) and there'd be similar > issues for picking an available listening port for the GUI. I can make > it work, but it's going to be a bit more fragile. Why is it not possible to decide that each one has a well-known port ? > Or should I just write the listening port numbers to the registry? Hm, are files too old fashioned ? Or maybe the session boundary makes it hard to find a directory simultaneously reachable by both ? -Alex
From: Spam on 3 Jun 2010 22:40 On Thu, 3 Jun 2010, Mark Roseman wrote: > Date: Thu, 03 Jun 2010 14:15:19 -0600 > From: Mark Roseman <mark(a)markroseman.com> > Newsgroups: comp.lang.tcl > Subject: IPC options on Windows > > I've got a traditional server process, and also a GUI process which can > keep an eye on and control the server process. Either one can run > without the other, and either one might be started or stopped > independently of the other. > > I'd been using DDE to communicate between them, which is great because > it doesn't involve separately maintaining connections between them, and > the namespace to find the other (TclEval/XYZServer and > TclEval/XYZMonitor) is pretty unpolluted. :-) > > Unfortunately, if I try to get the server process to run as a Windows > service I get problems on newer versions of Windows. DDE won't work > between services and user processes (they're placed into separate > 'sessions' for security reasons). > > Since messages would be initiated both by the GUI and the server I'm not > sure if sockets are the right way to go: the server won't necessarily be > on a known port (for GUI->server connections) and there'd be similar > issues for picking an available listening port for the GUI. I can make > it work, but it's going to be a bit more fragile. Or should I just > write the listening port numbers to the registry? > > Any other Windows IPC methods that would be a good fit for this > situation, and readily available to use in Tcl? > > Thanks > Mark > named pipes? I believe these might be available on Windows.
From: bobicanprogram on 7 Jun 2010 08:09 On Jun 3, 4:15 pm, Mark Roseman <m...(a)markroseman.com> wrote: > I've got a traditional server process, and also a GUI process which can > keep an eye on and control the server process. Either one can run > without the other, and either one might be started or stopped > independently of the other. > > I'd been using DDE to communicate between them, which is great because > it doesn't involve separately maintaining connections between them, and > the namespace to find the other (TclEval/XYZServer and > TclEval/XYZMonitor) is pretty unpolluted. :-) > > Unfortunately, if I try to get the server process to run as a Windows > service I get problems on newer versions of Windows. DDE won't work > between services and user processes (they're placed into separate > 'sessions' for security reasons). > > Since messages would be initiated both by the GUI and the server I'm not > sure if sockets are the right way to go: the server won't necessarily be > on a known port (for GUI->server connections) and there'd be similar > issues for picking an available listening port for the GUI. I can make > it work, but it's going to be a bit more fragile. Or should I just > write the listening port numbers to the registry? > > Any other Windows IPC methods that would be a good fit for this > situation, and readily available to use in Tcl? > > Thanks > Mark If you can tolerate a heterogeneous network with at least one Linux node then the SIMPL toolkit might have some answers for you: http://www.icanprogram.com/simpl http://www.icanprogram.com/lulu.html http://www.icanprogram.com/simpl/tclSurrogate.html The most common useage for the SIMPL tclSurrogate (TCP/IP socket based) protocol is for Windows -> Linux communications. However, there is nothing stopping one from just using the Linux server aa the namespace gateway and thereby enabling Windows -> Windows communications via that gateway. That Linux server need not be complex or expensive. For example the SIMPL toolkit has been ported to run on the Plug Computer (http://www.plugcomputer.org). bob PS. The tclSurrogate protocol is very straightward. There have been point to point implementations of this protocol in straight Tcl/Tk: http://www.icanprogram.com/ioanywhere/windowsHowTo.html If someone wants to gain some Tcl socket programming experience the SIMPL project would love to see these concepts generalized into a full Tcl/Tk based tclSurrogate daemon.
|
Pages: 1 Prev: What is the status of tdbc? Next: ttk::combobox in "clam" theme |