client-server

[Derek Atkins]

Tyson Dowd <trd@cs.mu.OZ.AU> writes:

> > Actually, I was looking at RPC/Corba/etc. over TCP, not over UDP.  The
> 
> I got the impression that you were advocating RPC over UDP.

Well, you can certainly use RPC over UDP, however you don't get a
reliable transport, and encryption data becomes much more challenging
(you need to encrypt per-packet rather than just encrypt a stream).
This implies you need to be much more careful with replay attacks as
well as constantly changing initialization vectors.

Keep in mind that with any RPC (TCP or UDP) you first open the
connection and then make as many RPC calls as you wish.

> SOAP/XML provides this too, using HTTP as the transport and XML to
> define the call site and pass data.

SOAP/XML (sic) is still a very young solution.  It's actually two
pieces, SOAP and XML-RPC, however both are still very young.  Indeed,
XML-RPC and SOAP we BOFs at the IETF, but never even made it beyond
that.  Or, at least, I can't find any current Working Groups that
seem to have SOAP as a working item.

Keep in mind that age-old, tested technologies have their benefits.
RPC has been around for 20 years, CORBA has been around at least 6.
The other problem is that I do not believe that you can effectively
compress a SOAP or XML-RPC request.  And XML is absolutely HUGE.  I
was assured that once the XML portion was stabilized we would turn on
compression; that mostly satisfies my on-disk local storage concerns.
However I don't believe you can compress a SOAP request (or response).

> The CGI could either be long-running, or it might just be a simple
> handler whose job is to keep the TCP connection open, it and forks of
> a "real" CGI to do the work. 

Define CGI however you wish..  The CGI is the CGI is the CGI... The
CGI is the program (or programs) that sit behind the web server and
process the requests and return the reponses.  You can define this
however you wish, but even if you split the functionality you still
have one CGI.

I would also warn you that if you split the CGI, you then completely
lose the benefits of any security, unless you pass the security
metadata across from one program to the other.

> HTTP does not require desiging your own IDL, you can use XML for that.

You're doing exactly what I warned, trying to push the problem off to
somewhere else and claiming it isn't a problem.  You STILL need to
define an IDL..  You just need to define it in terms of XML.

> Isn't this just a database + encryption?

No, it's a database + encryption + access control + cache-consistency
(plus some other things which I'm sure that I'm missing).

> There is no right way.  There are only tradeoffs.  It's certainly not
> something you can expect to be even moderately sure of with until you
> have a working prototype or better still a full implementation.

True.  Except we can learn by example; looking at other systems that
have used existing technologies and see how they behave.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available