DB design document

[Al Snell]

On Fri, 22 Dec 2000 linas@linas.org wrote:

> > Then, unfortunately, you're tempted to be wrong.  RPC (I'm going to
> > presume RPC == SunRPC == ONC RPC from now on) tries to bite off a much
> > smaller problem space than CORBA does, so the required solution space
> > is also much smaller.  

> uhh, I am not an expert, but: what about the deamons rpciod, lockd, 
> rpc.statd, portmap?  Last I understood, these had a variety of ways 
> to be hijacked, via replay attacks, bogus udp packets, etc.  I also 
> thought they introduced considerable latency: viz, having to look up a
> service on one port number, (using udp, no less), and then another,
> and then yet another lookup, just to find the service.   This was 
> supposed to be fixed by WebNFS, but since WebNFS never happened ...  

Those are NFS daemons. RPC needs only portmap. Portmap accepts a UDP
request to ask what port the RPC server is bound to, which is a single
transaction performed at connection setup and never again.

> Never mind that ssl-izing these deamons is not obviously 'easy'.

No need to ssl-ize portmap! It's just a naming service!

> Here are a few more notes, to let you know where I'm coming from:
> 1) I'm pro-corba to the extent that it becomes a consistent
>    part of gnome, and to the extent that gnucash really can provide 
>    a good set of base fincial functions.  Corba has momentum.

Yes

> 2) I'm anti-corba for reasons described in
>    http://www.vbxml.com/xml/articles/dotnetintro/default.asp
>    Basically, its the fast-setting concrete issue: if the cleint
>    and the server aren't exactly the same version number, they have
>    trouble communicating. (same remark for rpc). 

Not true - ONC RPC has a versioning mechanism built in. CORBA lacks one.

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software