荔园在线

荔园之美,在春之萌芽,在夏之绽放,在秋之收获,在冬之沉淀

[回到开始] [上一篇][下一篇]


发信人: playboy (冷冷的太阳), 信区: Program
标  题:  Win32 行程通讯的观念与技术(7)
发信站: BBS 荔园晨风站 (Mon Mar 20 15:52:09 2000), 转信

其他的IPC技术
    EXE通常呼叫DLL的输出函数(exports function),某些情况下
DLL也会使用EXE 事先预备的回呼(Callback)函数。函数呼叫这个
观念与想法如果移植到行程通讯中会发生什麽事呢? 我的意思是说
,让一个行程呼叫另一个行程的函数。Ya! 这就是所谓的 RPC,行
程之间属於函数呼叫层级的合作。可以想见的,由於行程各有其定
址空间,如同OLE,要达到 RPC确实需要额外标准的介面加以定义。
    有关IPC的技术与观念我们已经介绍得不少了,不论是讯息交
换,剪贴簿,Shared memory,DDE,MailSlot,Pipe等等,几乎都
是资料的交换或者Client与Server「要求-回应」,叁与通讯的行
讯必须对於交换的资料有一定程度的了解与处理能力。换句话说,
在我们以DDE向试算表软体要求传回资料後,这份资料到底代表什
麽得自己解释;同样的,如果要传入资料到试算表软体,即使透过
现成元件的帮忙,仍然必须对试算表软体有基本的认识。
    话说回来了,只有试算表自己最清楚资料代表什麽,不是吗
?那麽,由它来处理资料应该才是适当的人选,强以外部程式去
操作总有外行人指导内行人的遗憾。利用OLE技术将应用程式整合
在一起工作确实是比较合理的作法,如果COM物件可以像电子IC一
样安插进我们的程式与我们的程式一同工作,那这种我们称之为
OLE Control(ActiveX),距离拉大到网路上,DCOM这个名词你一
定听说过.
    想想看,终於我们可以用甲公司的统计图表元件,然後用乙
公司的元件将图表传真出去,这样窗景真是美好。窗子确实只提
供局部的风景,但是加装了望远镜的窗子可是一个天文台,加了
风铃的窗子所提供的就不只是风景了,还有悦耳的声音。
    不论是RPC或OLE,? 日後我们会在本专栏继续以专
文介绍RPC等主题。关於以Winsock作为IPC通讯机制这部分,本专
栏的前一篇文章「走! 让我们上BBS聊天去」才刚说明过,在此就
不再重覆了。

应用IPC到你的程式中
    各项IPC的技术往往以各种方式组合在一起。例如本文提供的
DemoSMem范例程式就同时用了ShareMem交换资料,同步机制则采
用Mutex与Event。情况并不如想像中的复杂:既是行程通讯,那
必然是两个以上行程之间的事,既是分开的,中间一定有介面存
在,定义这个介面的具体内容就是所谓的协定,留意资料交换的
位置与方式,需要协调避让的采用合适的同步控制加以处理。
这些重点把握住了,应该心 就已经有数了。
    面对各式各样的技术时,如果你正考虑应用IPC到你的程式中
,首先得正视自己的需求,不妨提出类似以下的问题问问自己,
最好将之写下来

是否真的需要跨行程处理,成效何在?
技术实作的难易程度与所需付出的成本
资料的流向是单向或双向,需不需反馈(feedback)的控制查核
这些工作只在单机完成,或者需要连上网路,范围只在公司内
部区域网路或者是广域网路
叁与通讯的行程最多与平均的数量是多少?

只在一种作业环境,或者可能同时要满足不同的作业平台
执行效能( performance)是不是关键需求.
应用程式使用 GUI 介面或者 console mode
   接下来开始比较各项IPC的特性,哪些是与你列出的需求相符
合的,有没有哪些限制是你必须要排除而避免使用的,各项IPC
经过与先前写下的需求交叉评比的结果,积分高的自然是脱颖而
出。最後,事情如果能简单解决是最好,开发时程缩短成本自然
降低,而且日後维护容易。

结语
     技术是不断推陈出新的,当各式各样的IPC机制提出回
顾行程之所以开始通讯合作的初衷是有必要的,唯有回到最初原
始的简单需求,才能看出技术演进过程的缘由与其修正的价值,
不断的变易之中我们可以粹化出一些不变的原则与观念,而这些原则
应该是与最初的需求互相吻合的

--
※ 来源:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.1.90]


[回到开始] [上一篇][下一篇]

荔园在线首页 友情链接:深圳大学 深大招生 荔园晨风BBS S-Term软件 网络书店