我要做一WEB服务器，它还要跟我的另一应用程序通信（传参数），都在一台机上，如何实现。

我要做一WEB服务器，它还要跟我的另一应用程序通信（传参数），都在一台机上，如何实现。

怎样去实现我的目的？

假设应用程序(A.EXE)是一个播放软件，现在需要WEB SERVER端控制它的播放及播放内容。
也就是说让客户在客户端选择播放内容，然后，在服务端播放，通过 A.exe 播放。所以 WEB服务器必须跟A.exe通信。

现有两种方案可参考：

1 数据库，WEB Sever 写数据库， A.exe 不断读数据库。

2 TCP/IP, A.exe 打开本机的一个端口(8899)侦听数据，WEB Server 给(8899)端口发送数据。

两种方法都可行吗？是否还有更好的？
该如何实现。

36 个解决方案

#1

#2

没经验...

#3

顶

#4

DDE方案：

1)把应用程序(A.EXE)的DDE功能打开用来接收命令行参数(,比如,将启动窗口设置linkmode=1,linktopic= "aaa "....

2)WEB   SERVER端使用WSCRIPT.SHELL:
  dim   objShell
  set   objShell=server.createobject(   "WSCRIPT.SHELL   ")
  objShell.shell   "路径+A.EXE   -参数 "
3)在A.EXE的DDE窗口处理参数:
如果COMMAND不为空,判断APP.PREINSTANCE;如果TRUE,将参数传过去,关闭新窗口;如果FALSE,带命令启动A.EXE.....

这方案是否可行？

有什么情况没考虑到的。

#5

调用可执行文件,通过参数控制.

#6

楼主的DDE方案应该就可以，这个要想知道还会遇到什么问题。那就是在测试的时候再找了

#7

不太有经验，帮顶，

自我感觉3个方案都行，需要根据程序对时效性的需求。

1。数据库，扫描的太勤快，服务器压力大，否则就会有大量延迟。

2。应该没问题，

3。不了解。

#8

既然都在一台机子上保存文件路径然后由WebService返回给发送请求的exe播放程序不就行吗

#9

这种需求建议用同步模式，而不要采用通过数据库中转的异步模式。

楼主可搜索.net进程间通信相关文章，参考：http://www.pcdog.com/edu/engineer/2005/09/n068742.html

#10

"既然都在一台机子上   保存文件路径   然后由WebService返回给发送请求的exe播放程序不就行吗"

如果这样的话，A.EXE就必须时刻的请求WebService

我希望的是 A.EXE 能时刻待命，而不是不断的去询问是否有新的命令。

方案4：
文件方案
A.exe  所在目录的有一子目录 TEMP
A.exe  建一线程，时刻监视 TEMP 目录，是否有变化。

而WebService有新的指令就给TEMP 目录写入一文件1.txt(2.txt...) ，A.exe读取该文件后删除。

到底哪种方案最好。怎样实现。
还有没有更好的。

#11

不知道这个EXE是不是你自己写的？？？

如果是，可以不断的请求一个页面，这个页面输出一个XML

开一个接口，加入一个事件就是onchang当然这个事件也要自己写

只要这个属性改变了，接下你相怎么做就怎么做了

#12

这个EXE是我自己写的

可以不断的请求一个页面。

但这会不会耗资源呢。如果这样的话，A.EXE就必须时刻的请求WebService
我希望的是 A.EXE 能时刻待命，而不是不断的去询问是否有新的命令。

#13

WEB Server 向msmq(消息队列）里写数据，你写的服务器读msmq(消息队列）里的相应信息

#14

没有做过，
但通过WebService 实时调用A.EXE，这个方案可行，
而且不存在平凡扫描数据库所带来的负面影响，
实现起来也较容易些。

#15

#16

"WEB Server 向msmq(消息队列）里写数据，你写的服务器读msmq(消息队列）里的相应信息"
是怎样实现的？

（DDE方案）通过WebService实时调用A.EXE，这个方案的确可行，我会优先考虑它。

但对于在.NET中使用命名管道完成进程间通信，我颇感兴趣，希望研究一下。大家对此有什么看法？

#17

对于这种情况,你可以采用端口能迅的方式,直接用WEB跟播放器通迅,比如你可以用socketJS(flash控件).

#18

#19

"对于这种情况,你可以采用端口能迅的方式,直接用WEB跟播放器通迅,比如你可以用socketJS(flash控件)."

你的意思是采用第二种方案 TCP/P 通信。(Socket)

#20

Y的，你不会做一个文件依赖呀？
A.exe有变动，就把要点播的文件写到一个文本文件中去，服务器端直接监视文本文件，一有变动就响应就成了。搞么子数据库那么复杂干么。

我看你是想搞KTV点播吧

#21

你猜错了，我不是在搞KTV点播，不过有点相似。
由于是初学ASP.net,应该说从来没接触过，只是看来几天书，领导给了我一个月时间让我设计，我还是没设计出来。

sxlfybb兄，你说的方案我想过了，就是建一线程监视文件吧。可行，但不好。

#22

LZ,有了好的方案,别忘了用站短知会兄弟俺一声;我今天给你的建议是我DS播放器里的一部分;和WEB交互倒是很有点味道,呵呵
可惜实在没时间写...

#23

直言,不知道楼主是不是觉得webservices时髦啊?
webservice解决的是跨平台,跨应用..
如一个windows应用程序,一个b/s应用程序,他们都可以共享webservice提供的数据
还有播放文件本就存在本地硬盘上,为什么要搞到tcp通讯呢?

直接io访问不是更好吗?

#24

没有明白你需要做什么...

#25

是这样的，我的需求是：
做这样一个系统，让用户在如何地方，如何时间，都可以通过网络来控制一个大显示屏的播放内容及该显示屏的一些参数配置。
显示屏是与一台桂在网上的主机相连，通过采集该主机上的显示的内容来播放，即该主机桌面播放什么，该显示屏就显示什么。
该主机就是作为一台服务器。

采用B/S结构是想用户通过WEB浏览器(IE等)就可以访问得到，而不需安装什么软件。

而负责播放的是一个应用程序(A.EXE),我必须跟它交互，才能让它播放我指定的内容。

各位大侠，有何高见。

#26

用WindowsMediaServer做一个播放列表

在客户端的html中,写一个windowsmediaplayer的控件,其中地址为该windowsmeidaserver的播放列表文件的url

即可.全球同步.

#27

明白了，也就是说A.EXE随时处于待命状态。等待外部通过B/S程序传入指令。
--------------------------------
楼上已经很多方案了
1、使用数据库，两个程序共享一个数据库
2、使用WebService,B/S上面提供WebService服务，客户端可以修改服务的内容，供A.EXE调用
3、使用异步手段，比如 MSMQ, B/S 中将服务指令存入到MSMQ中，A.EXE探测MSMQ中Message的变化。根据Message来确定显示。

   上述第1种实现最简单。但是直接对另一个程序开放数据库是个不好的用法，一旦数据出了故障不易调试。
   第3种比较适合这种情况，不过服务器上需要安装MQ队列组件。建议采用第3种
   具体消息队列的示例可以参考petshop4.0中源代码，写的很详细。

#28

端口侦听, 如果 A.EXE 长期运行的话.

如远程控件软件就是使用侦听端口, 接收指令再作出操作,
发送指令可以TCP,UDP.

使用端口侦听能即时作出反映...

#29

使用消息队列是个比较好的办法。
要使用system.Messageing类

#30

消息队列比web service更成熟些，它内置支持验证，消息优先，确保消息送达。
MessageQueue.Create() '创建消息
MessageQueue.GetpublicQueues() ‘检索队列
MessageQueue.send() ’发送消息

#31

webservice吧

#32

由于是初学ASP.net,应该说从来没接触过，只是看来几天书，领导给了我一个月时间让我设计，我还是没设计出来。

看天书?强....;

#33

webservice就可以实现传递参数了，何必搞那么复杂呢？

#34

webserver 可能好点

#35

TCP/P 通信。(Socket)

#36

既然是一台机器，消息队列比较好，安全可靠

#1

#2