client-server

James LewisMoss jimdres@mindspring.com
27 Dec 2000 11:55:11 -0500


>>>>> On Fri, 22 Dec 2000 19:25:03 +0000 (GMT), "Al B. Snell" <alaric@alaric-snell.com> said:

 Al> On Fri, 22 Dec 2000 linas@linas.org wrote:
 >> > You're missing the point - HTTP is slow! It doesn't load the
 >> > server, it's just slow!
 >>
 >> Its not slower than rpc, corba, ftp, nfs or sendmail.

 Al> Is so.

 Al> HTTP:

 Al> 1) TCP 3 way handshake
 Al> 2) Send request packet
 Al> 3) Receive request ack
 Al> 4) Receive reply packet(s) and send ACKs
 Al> 5) TCP teardown, or return to step 2 for persistent connections

 Al> RPC over UDP:

 Al> 1) Optionally send portmap request and wait for reply
 Al> 2) Send request and wait for reply
 Al> 3) Return to step 2 for further requests

 Al> (one or two round trip times)

 Al> RPC over TCP:

 Al> 1) Optionally send portmap request and wait for reply
 Al> 2) 3 way TCP handshake
 Al> 3) Send request packet
 Al> 4) Receive request ACK
 Al> 5) Receive reply packets and send ACKs
 Al> 6) Return to step 3

 Al> Now, RPC over TCP has similar packet-latency as HTTP so long as
 Al> HTTP is using persistent connections; but that doesn't increase
 Al> much if you use secure RPC which is much more lightweight than
 Al> SSL.

 Al> I would suggest making good use of RPC over UDP - the connection
 Al> should start off with UDP, and only make TCP connections when
 Al> "transactions" are being performed. UDP will be fine for reading
 Al> data, since if a packet gets lost, a retransmit will have no
 Al> idempotency problems... TCP will implement the retransmit in a
 Al> much bulkier way. RPC over UDP is as fast as an Internet protocol
 Al> can *ever* get.

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.

Jim

-- 
@James LewisMoss <dres@debian.org>      |  Blessed Be!
@    http://jimdres.home.mindspring.com |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach