client-server

[Tyson Dowd]

On 27-Dec-2000, Derek Atkins <warlord@MIT.EDU> wrote:
> David Merrill <dmerrill@lupercalia.net> writes:
> 
> > > OK.  So the question I have is "So what?"  HTTP is slower than a UDP
> > > protocol because it's TCP (that's the basic gist of this right?).  So
> > > what?  Is it too slow for our uses?  No one knows because it hasn't
> > > been tested.  My bet: nope not anywhere near too slow.
> > > 
> > > Now.  What's simpler?  What is more easily understandable?  What's
> > > more universal?  Those are the questions that seem more important to
> > > me.
> > 
> > I think James is right here. While there may be a slight difference in
> > speed, it is unlikely to be very significant. Robustness and
> > simplicity seem more important than raw speed to me.
> > 
> > Of course, I know little of what you are talking about, so I can't
> > debate the fine points of one approach over another as you are. It
> > just seems you are so focused on the speed issue you aren't
> > considering other factors.
> 
> 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.

> benefits of using RPC or Corba over, e.g. HTTP is multi-fold:
> 	1) programatic interfaces..  Using RPC or Corba you can define
>            an IDL that defines the data structures and function calls
>            (methods) that are being called across the network.  You
>            are, in essence, building your own protocol based upon the
>            programatic needs of your system.  You use a pre-defined
>            transport mechanism and infrastructure that is well used
>            and tested, so you only need to worry about your own IDL
>            and handler functions.

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

> 
> 	2) HTTP was designed for document transfers, not RPCs.  What
>            we really want to do is more closely related to RPCs than
>            document requests.  HTTP was also designed with single
>            request-response per session.  Granted, HTTP/1.1 allows
>            extended connections (multiple requests/responses), however
>            it is unclear how a CGI would interface with that.  I
>            certainly have never writter a long-lived CGI.  Also, HTTP
>            was not designed with arbitrary function calls; you not
>            only have to design your own "IDL" (not that HTTP supports
>            IDLs) but you also have to design your own transport and
>            marshalling system as well (for both requests and
>            responses).

If you send 
	Connection: keep-alive
requests and responses in the headers of SOAP messages, you leave the
TCP connection open.

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. 

HTTP does not require desiging your own IDL, you can use XML for that.
If you really need the descriptive abilities of IDL, you can use web
services -- but this is only really going to come into play when you 
are working with "unknown" interfaces.  But this is only really
necessary in situations where you would be using DII or DSI in CORBA.

> Just to play devil's advocate let me throw another log on the fire:
> what we really want here is a distributed file system.  We want data
> locking and access control semantics to allow multiple clients to
> access the data store.  Why not just split the data store into
> multiple "files" and require a network file system that allows us to
> lock the files (and directories) when we need to modify data.  If the
> File System can encrypt data across the network, doesn't that solve
> our problem, too?

Isn't this just a database + encryption?

> Seriously, I think there are multiple approaches to do what we want to
> do.  Many of them are "valid", and each approach certainly has its
> advantages and disadvantages.  I'm not at all convinced that we can
> objectively choose any one approach over any other approach, and quite
> honestly I don't know what the "right" way is.

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.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd@cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #