Chinaunix首页 | 论坛 | 博客
  • 博客访问: 819825
  • 博文数量: 756
  • 博客积分: 40000
  • 博客等级: 大将
  • 技术积分: 4980
  • 用 户 组: 普通用户
  • 注册时间: 2008-10-13 14:40
文章分类

全部博文(756)

文章存档

2011年(1)

2008年(755)

我的朋友

分类:

2008-10-13 16:11:39

I think there's a lot of reluctance to roll-your-own when it comes to
protocols.  When I tell people about the problems with CORBA, almost
everyone starts trying to come up with different off the shelf systems
that could replace it.  I'd love to find such a system, but everything
I've looked at falls pretty short.  Here I'll briefly list the various
systems that I've come across, and explain briefly (or not so briefly)
why I think they fall short.


CORBA/ICE:
  CORBA spec:
  ICE spec:
  - Discussed in ReFresco 1.

D-BUS:
  - Generally, designed for multicasting small messages and the like,
    not for full-fledged distributed objects; by itself this doesn't
    mean it will be inappropriate for a more demanding system, but
    makes impedence mismatch more likely.  But some consequences
    follow.
  - Designed for use with well-known object names (UTF-8!), so making
    secure is awkward
  - No way to do pipelining
  - Method returns are forgeable -- identified by 32-bit serial
    number.  (I.e., if I can guess that you're calling a remote
    method, and what serial number you're using, I can send back a
    forged reply that you will think is the real reply.  The constants
    are such that making such a guess is probably doable.)
  - Not clear to me that they've really thought through protocol
    versioning (compare to ICE versioning scheme)
  - Marshalling system has no pointer sharing
  - Leaves us dependent on external software, big projects, etc.  If
    we have something small and simple, we can adapt it to our needs.
   
    For instance, it is not clear what ordering guarantees D-BUS
    provides on message delivery, yet this is absolutely critical to a
    system like Fresco.  Far easier to just make our system handle
    this correctly than to try to fork D-BUS or convince the
    freedesktop.org people that they should change their software for
    us.

Pluribus: The protocol used by E ( ), see
 
  - Very good, deeply designed security and pipelining, gets things
    like ordering right
  - Based around a CORBA-ish object model with many-to-many
    communication; not clear if could support a spoked hub model.
  - Very complicated and tied up in another project; only current
    implementation is in Java, and specification may change.  Too
    complicated to be reimplemented in other languages, especially
    while the specification is changing based around another project's
    needs!

XML-RPC/SOAP:
  - Far, far too heavyweight and clunky.

COM/DCOM/COM+:
  - Mentioned for completeness only.

ASN.1:
  - Only a method for encoding data, not a general communications
    framework
  - Can't represent pointer sharing (I'm pretty sure)
  - Haven't looked at closely

Mbus: ,
  - Haven't looked at in detail; seems oriented towards many-to-many
    communications, with a fairly inefficient protocol (sequence
    numbers represented as ASCII strings?)

--------------------next---------------------

阅读(338) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~